Re: ext3 fsync being starved for a long time by cp and cronjob

On Saturday 26 August 2006 06:14, Theodore Tso wrote:

> >Background load is a large cp from the same fs to a tmpfs and a cron job
> >doing random cron job stuff. All on a single sata disk with a 28G partition.
> 
> That doesn't sound like you are doing anything that would result in a
> lot of ext3 journal activity (unless there's something strange running
> out of your cron scripts).

(looking through the process list again)

kmail was doing some write IO, not sure how much.

So yes.

> So if you're focused on allocating blame :-), 

I would be mostly interested in a solution.

(sorry "assigning blame" is a SUSE tongue-in-cheek and just means the 
first step in debugging when you try to figure out which subsystem
to look at. It wasn't meant as in to blame some person of 
wrong-doing.) 

> it's probably both ext3 
> and the elevator code equally at fault.  I suspect what we need is a
> way of informing the elevator that when ext3 is writing commit records
> or other writes that block filesystem I/O, that these synchronous
> writes should be prioritized about other (asynchronous) write traffic.
> This hint would have to be passed through the buffer cache layer,
> since the jbd layer is still using buffer heads.

Hmm, I thought CFQ currently only looked at processes for priority,
but maybe it's possible to add temporary boosts. Jens? 

Or maybe just run kjournald always with a high io priority? I assume
it mostly does journal IO and not much else, right?

-Andi

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642