| To: | Christoph Hellwig <hch@xxxxxxxxxxxxx> |
|---|---|
| Subject: | Re: buffered writeback torture program |
| From: | Andreas Dilger <adilger@xxxxxxxxx> |
| Date: | Thu, 21 Apr 2011 11:59:37 -0600 |
| Cc: | Chris Mason <chris.mason@xxxxxxxxxx>, linux-fsdevel <linux-fsdevel@xxxxxxxxxxxxxxx>, linux-ext4 <linux-ext4@xxxxxxxxxxxxxxx>, xfs <xfs@xxxxxxxxxxx>, jack <jack@xxxxxxx>, axboe <axboe@xxxxxxxxx>, dchinner <dchinner@xxxxxxxxxx> |
| In-reply-to: | <20110421174120.GA7267@xxxxxxxxxxxxx> |
| References: | <1303322378-sup-1722@think> <20110421083258.GA26784@xxxxxxxxxxxxx> <1303407205-sup-6141@think> <20110421174120.GA7267@xxxxxxxxxxxxx> |
On 2011-04-21, at 11:41 AM, Christoph Hellwig wrote: > On Thu, Apr 21, 2011 at 01:34:44PM -0400, Chris Mason wrote: >> Sorry, this doesn't do it. I think that given what a strange special >> case this is, we're best off waiting for the IO-less throttling, and >> maybe changing the code in xfs/ext4 to be a little more seek aware. Or >> maybe not, it has to get written eventually either way. > > I'm not sure what you mean with seek aware. XFS only clusters > additional pages that are in the same extent, and in fact only does > so for asynchrononous writeback. Not sure how this should be more > seek aware. But doesn't XFS have potentially very large extents, especially in the case of files that were fallocate()'d or linearly written? If there is a single 8GB extent, and then random writes within that extent (seems very database like) grouping the all of the writes in the extent doesn't seem so great. Cheers, Andreas |
| Previous by Date: | Re: buffered writeback torture program, Christoph Hellwig |
|---|---|
| Next by Date: | Re: buffered writeback torture program, Christoph Hellwig |
| Previous by Thread: | Re: buffered writeback torture program, Christoph Hellwig |
| Next by Thread: | Re: buffered writeback torture program, Christoph Hellwig |
| Indexes: | [Date] [Thread] [Top] [All Lists] |