On Mon, 18 Mar 2013, Eric Sandeen wrote: > Date: Mon, 18 Mar 2013 21:28:22 -0500 > From: Eric Sandeen <sandeen@xxxxxxxxxxx> > To: Theodore Ts'o <tytso@xxxxxxx> > Cc: Dave Chinner <david@xxxxxxxxxxxxx>, Eric Whitney <enwlinux@xxxxxxxxx>, > Eric Sandeen <sandeen@xxxxxxxxxx>, Ben Myers <bpm@xxxxxxx>, > linux-ext4@xxxxxxxxxxxxxxx, xfs-oss <xfs@xxxxxxxxxxx> > Subject: Re: possible dev branch regression - xfstest 285/1k > > 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? I am actually in favour of 42. 42 is "The answer" here :) -Lukas > > -Eric > > -- > To unsubscribe from this list: send the line "unsubscribe linux-ext4" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
