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 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. Hmm.... Another possibility is to define a directory structure where each test would look for the existence of some file such as fscust/<fs>/<test>, and so if fscust/ext4/218 exists, it would get sourced, and this would define potential hook functions that would get called after the file system is mounted. This way, the file system specific stuff is kept out of the way of the test script. Would that make adding fs-specific tuning/setup for tests more palatable? Regards, - Ted _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
