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? -Eric _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
