possible dev branch regression - xfstest 285/1k

[Lukáš Czerner]

On Mon, 18 Mar 2013, Eric Sandeen wrote:

> Date: Mon, 18 Mar 2013 21:28:22 -0500
> From: Eric Sandeen <sandeen at sandeen.net>
> To: Theodore Ts'o <tytso at mit.edu>
> Cc: Dave Chinner <david at fromorbit.com>, Eric Whitney <enwlinux at gmail.com>,
>     Eric Sandeen <sandeen at redhat.com>, Ben Myers <bpm at sgi.com>,
>     linux-ext4 at vger.kernel.org, xfs-oss <xfs at oss.sgi.com>
> 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 at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>