Search String: Display: Description: Sort:

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*\[PATCH\]\s+xfs\:\s+Do\s+background\s+CIL\s+flushes\s+via\s+a\s+workqueue\s*$/: 10 ]

Total 10 documents matching your query.

1. [PATCH] xfs: Do background CIL flushes via a workqueue (score: 1)
Author: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Tue, 27 Mar 2012 20:46:45 +1100
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
/archives/xfs/2012-03/msg00519.html (19,806 bytes)

2. Re: [PATCH] xfs: Do background CIL flushes via a workqueue (score: 1)
Author: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Date: Tue, 27 Mar 2012 10:31:27 -0400
Vivek, does CFQ still need any hints for this sort of handoff? --end quoted text--
/archives/xfs/2012-03/msg00525.html (26,417 bytes)

3. Re: [PATCH] xfs: Do background CIL flushes via a workqueue (score: 1)
Author: Vivek Goyal <vgoyal@xxxxxxxxxx>
Date: Tue, 27 Mar 2012 11:57:59 -0400
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
/archives/xfs/2012-03/msg00533.html (9,812 bytes)

4. Re: [PATCH] xfs: Do background CIL flushes via a workqueue (score: 1)
Author: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Date: Tue, 27 Mar 2012 12:03:00 -0400
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
/archives/xfs/2012-03/msg00534.html (9,531 bytes)

5. Re: [PATCH] xfs: Do background CIL flushes via a workqueue (score: 1)
Author: Vivek Goyal <vgoyal@xxxxxxxxxx>
Date: Tue, 27 Mar 2012 12:19:41 -0400
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
/archives/xfs/2012-03/msg00547.html (11,267 bytes)

6. Re: [PATCH] xfs: Do background CIL flushes via a workqueue (score: 1)
Author: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Date: Tue, 27 Mar 2012 13:03:09 -0400
All XFS log I/O is marked SYNC and (FUA and/or FLUSH).
/archives/xfs/2012-03/msg00549.html (9,143 bytes)

7. Re: [PATCH] xfs: Do background CIL flushes via a workqueue (score: 1)
Author: Vivek Goyal <vgoyal@xxxxxxxxxx>
Date: Tue, 27 Mar 2012 13:23:57 -0400
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_
/archives/xfs/2012-03/msg00550.html (9,474 bytes)

8. Re: [PATCH] xfs: Do background CIL flushes via a workqueue (score: 1)
Author: Vivek Goyal <vgoyal@xxxxxxxxxx>
Date: Tue, 27 Mar 2012 13:18:45 -0400
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
/archives/xfs/2012-03/msg00551.html (9,723 bytes)

9. Re: [PATCH] xfs: Do background CIL flushes via a workqueue (score: 1)
Author: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Thu, 29 Mar 2012 19:51:12 +1100
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
/archives/xfs/2012-03/msg00597.html (13,238 bytes)

10. Re: [PATCH] xfs: Do background CIL flushes via a workqueue (score: 1)
Author: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Thu, 29 Mar 2012 19:52:26 +1100
Not if the filesystem is mounted nobarrier, as is recommended for filesystems on hardware RAID with BBWCs.... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx
/archives/xfs/2012-03/msg00598.html (9,864 bytes)


This search system is powered by Namazu