xfs
[Top] [All Lists]

Re: possible dev branch regression - xfstest 285/1k

To: Eric Sandeen <sandeen@xxxxxxxxxxx>
Subject: Re: possible dev branch regression - xfstest 285/1k
From: Lukáš Czerner <lczerner@xxxxxxxxxx>
Date: Tue, 19 Mar 2013 09:50:21 +0100 (CET)
Cc: "Theodore Ts'o" <tytso@xxxxxxx>, Dave Chinner <david@xxxxxxxxxxxxx>, Eric Whitney <enwlinux@xxxxxxxxx>, Eric Sandeen <sandeen@xxxxxxxxxx>, Ben Myers <bpm@xxxxxxx>, linux-ext4@xxxxxxxxxxxxxxx, xfs-oss <xfs@xxxxxxxxxxx>
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <5147CD46.1090205@xxxxxxxxxxx>
References: <20130315222818.GA16100@wallace> <20130316150923.GA18589@xxxxxxxxx> <20130317030648.GA14225@xxxxxxxxx> <51473C8B.5070509@xxxxxxxxxx> <20130318170927.GA5639@xxxxxxxxx> <51475043.4010505@xxxxxxxxxx> <20130318204133.GE22182@xxxxxxx> <20130318231233.GQ6369@dastard> <20130319014718.GV6369@dastard> <20130319020056.GC4660@xxxxxxxxx> <5147CD46.1090205@xxxxxxxxxxx>
User-agent: Alpine 2.00 (LFD 1167 2008-08-23)
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
> 

<Prev in Thread] Current Thread [Next in Thread>