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);
> 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
> 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?