[Top] [All Lists]

Re: possible dev branch regression - xfstest 285/1k

To: Theodore Ts'o <tytso@xxxxxxx>
Subject: Re: possible dev branch regression - xfstest 285/1k
From: Eric Sandeen <sandeen@xxxxxxxxxxx>
Date: Mon, 18 Mar 2013 21:28:22 -0500
Cc: Dave Chinner <david@xxxxxxxxxxxxx>, Eric Whitney <enwlinux@xxxxxxxxx>, Eric Sandeen <sandeen@xxxxxxxxxx>, Ben Myers <bpm@xxxxxxx>, linux-ext4@xxxxxxxxxxxxxxx, xfs-oss <xfs@xxxxxxxxxxx>
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <20130319020056.GC4660@xxxxxxxxx>
References: <20130315222818.GA16100@wallace> <20130316150923.GA18589@xxxxxxxxx> <20130317030648.GA14225@xxxxxxxxx> <51473C8B.5070509@xxxxxxxxxx> <20130318170927.GA5639@xxxxxxxxx> <51475043.4010505@xxxxxxxxxx> <20130318204133.GE22182@xxxxxxx> <20130318231233.GQ6369@dastard> <20130319014718.GV6369@dastard> <20130319020056.GC4660@xxxxxxxxx>
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130216 Thunderbird/17.0.3
On 3/18/13 9:00 PM, Theodore Ts'o wrote:
> On Tue, Mar 19, 2013 at 12:47:18PM +1100, Dave Chinner wrote:
>> Sorry about this - I've mixed up my threads about ext4 having
>> problems with zero-out being re-enabled. I thought this was a
>> cross-post of the 218 issue....
>> However, the same reasoning can be applied to 285 - the file sizes,
>> the size of the holes and the size of the data is all completely
>> arbitrary. If we make the holes in the files larger, then the
>> zero-out problem simply goes away.
> Right.  That was my observation.  We can either make the holes larger,
> by changing:
>    pwrite(fd, buf, bufsize, bufsize*10);
> to
>    pwrite(fd, buf, bufsize, bufsize*42);
> ... and then changing the expected values returned by
> SEEK_HOLE/SEEK_DATA.  (By the way; this only matters when we are
> testing 1k blocks; if we are using a 4k block size in ext4, the test
> currently passes.)
> Or we could set some ext4-specific tuning parameters into the #218

285! :)

> shell script, if the file system in question was ext4.
> I had assumed that folks would prefer making the holes larger, but
> Eric seemed to prefer the second choice as a better one.

Ok, after the discussion I'm convinced too.  Stretching out the allocation
to avoid fill-in probably makes sense.  But maybe not "42" -
how about something much larger, so that any "reasonable" filesystem
wouldn't even consider zeroing the range in between?


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