[Top] [All Lists]

Re: buffered writeback torture program

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

<Prev in Thread] Current Thread [Next in Thread>