Doing background CIL flushes adds significant latency to whatever async transaction that triggers it. To avoid blocking async transactions on things like waiting for log buffer IO to complete, move t
Christoph, I don't understand the issue enough to comment on it. Had a quick look at the patch. Looks like some action (writing log), has been moved to a worker thread. And in some cases (log force t
Yes. This is to workaround the old problem of cfq getting utterly confused if cooperating I/O beeing submitted from different threads. The case in the previous version of this patch was: - thread doi
Ok, then I think that fundamental issue still remains with CFQ. And there is no general solution to recognizing dependency between processes. But a specific workaround for ext3/ext4 fsync problem was
Well, if all the requests are marked with FUA/FLUSH, then I think these requests will not even be given to IO scheduler. And we should not have the issue of idling. if (bio->bi_rw & (REQ_FLUSH | REQ_
In that case I am not sure if XFS should still face the idling issue. If it does, then we need to debug it further and see why the fix is not working. Dave, any chance of 10 seconds of blktrace data
Oh, that hack. Have a look at the patch Jan Kara just posted to the ext4 list (jbd: Refine commit writeout logic, http://comments.gmane.org/gmane.comp.file-systems.ext4/31704) where he removes that W
Not if the filesystem is mounted nobarrier, as is recommended for filesystems on hardware RAID with BBWCs.... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx