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

Theodore Tso <[email protected]> Sat, 26 Aug 2006 00:14:22 -0400
Newsgroups gmane.comp.file-systems.ext2.devel,gmane.linux.kernel.mm
Message-ID <[email protected]>
On Fri, Aug 25, 2006 at 02:30:56PM +0200, Andi Kleen wrote:
> So you think it's the elevator? I was about to blame JBD.

Earlier in the thread, you said:

>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).

As such, it's hard to see how this would be an JBD issue.  Ext3 might
have been in the middle of doing a synchronous write of a commit
block, which might have been getting starved by an elevator which
prioritizes read traffic ahead of write traffic, but it doesn't sound
like it's due to the excessive journal traffic.

So if you're focused on allocating blame :-), 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.

Regards,

						- Ted

-------------------------------------------------------------------------
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