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

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

[Eric Sandeen]

On 3/18/13 12:09 PM, Theodore Ts'o wrote:
> On Mon, Mar 18, 2013 at 11:10:51AM -0500, Eric Sandeen wrote:

<previous discussion thread about test 285 SEEK_HOLE test
breaking on ext4 due to change in opportunistic hole-filling
behavior and how to make it work again on ext4, and mention
of sysctl which makes it pass>

>> The test could do this too, right?
>>
>> _need_to_be_root
>>
>> and:
>>
>> if [ "$FSTYP" == "ext4" ]; then
>> 	ORIG_ZEROOUT_KB=`cat /sys/fs/ext4/$TEST_DEV/extent_max_zeroout_kb`
>> 	echo 0 > /sys/fs/ext4/$TEST_DEV/extent_max_zeroout_kb
>> fi
>>
>> and put it back to default in _cleanup:
>>
>> 	echo $ORIG_ZEROOUT_KB > /sys/fs/ext4/$TEST_DEV/extent_max_zeroout_kb
>>
>> That way we'd be testing seek hole correctness w/o being subject to
>> the vagaries in allocator behavior.
> 
> Yeah, the question is whether it would be more acceptable to put
> ext4-specific hacks like this into the test, or to modify
> src/seek_sanity_test.c so that it writes the test block-size block
> using pwrite at offset blocksize*42 instead of offset blocksize*10.

That seems like more of an obtuse hack, since it depends on current
default behavior, right?

Explicitly setting the zeroout to 0, with a comment as to why, should
make it clear to the reader of the test I think.

I'll have to look, xfs speculative preallocation fills in holes in
some cases as well, I'm not certain how it behaves on this test.

But we could put in a specific tuning for xfs as well if needed.

If it becomes clear that every fs requires tuning to not opportunistically
fill in holes, then maybe we should make it non-generic, and only support
filesystems we've tested or tuned to work with the testcase.

> I had assumed putting hacks which tweaked sysfs tunables into the
> xfstest script itself would be frowned upon, but if that's considered
> OK, that would be great.

I don't see any real problem with it, myself.

cc: xfs list to see if there are any objections...

-Eric

> 
> 	      	 		       - Ted
> 

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

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

[Ben Myers]

Hi Eric,

On Mon, Mar 18, 2013 at 12:34:59PM -0500, Eric Sandeen wrote:
> On 3/18/13 12:09 PM, Theodore Ts'o wrote:
> > On Mon, Mar 18, 2013 at 11:10:51AM -0500, Eric Sandeen wrote:
> 
> <previous discussion thread about test 285 SEEK_HOLE test
> breaking on ext4 due to change in opportunistic hole-filling
> behavior and how to make it work again on ext4, and mention
> of sysctl which makes it pass>
> 
> >> The test could do this too, right?
> >>
> >> _need_to_be_root
> >>
> >> and:
> >>
> >> if [ "$FSTYP" == "ext4" ]; then
> >> 	ORIG_ZEROOUT_KB=`cat /sys/fs/ext4/$TEST_DEV/extent_max_zeroout_kb`
> >> 	echo 0 > /sys/fs/ext4/$TEST_DEV/extent_max_zeroout_kb
> >> fi
> >>
> >> and put it back to default in _cleanup:
> >>
> >> 	echo $ORIG_ZEROOUT_KB > /sys/fs/ext4/$TEST_DEV/extent_max_zeroout_kb
> >>
> >> That way we'd be testing seek hole correctness w/o being subject to
> >> the vagaries in allocator behavior.
> > 
> > Yeah, the question is whether it would be more acceptable to put
> > ext4-specific hacks like this into the test, or to modify
> > src/seek_sanity_test.c so that it writes the test block-size block
> > using pwrite at offset blocksize*42 instead of offset blocksize*10.
> 
> That seems like more of an obtuse hack, since it depends on current
> default behavior, right?
> 
> Explicitly setting the zeroout to 0, with a comment as to why, should
> make it clear to the reader of the test I think.
> 
> I'll have to look, xfs speculative preallocation fills in holes in
> some cases as well, I'm not certain how it behaves on this test.

My impression was that we are not zeroing holes, but I'd also have to look to
be sure.  ;)
 
> But we could put in a specific tuning for xfs as well if needed.
> 
> If it becomes clear that every fs requires tuning to not opportunistically
> fill in holes, then maybe we should make it non-generic, and only support
> filesystems we've tested or tuned to work with the testcase.
> 
> > I had assumed putting hacks which tweaked sysfs tunables into the xfstest
> > script itself would be frowned upon, but if that's considered OK, that
> > would be great.
> 
> I don't see any real problem with it, myself.
> 
> cc: xfs list to see if there are any objections...

Seems like the options being discussed so far are:

1) make the test fs specific
2) filesystem specific hacks to disable opportunistic zeroing of holes
3) modify the test output to work with current ext4 default behavior

It might be hard to find a tuning to produce identical output for xfs and ext4
(option 3), and option 1 and 2 are a also bit clunky.

How about option 4) fs-specific test output?

We wouldn't have multiple copies of the same test laying around, and ext4 could
still run with default settings.

Regards,
	Ben

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

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

[Dave Chinner]

On Mon, Mar 18, 2013 at 03:41:33PM -0500, Ben Myers wrote:
> Hi Eric,
> 
> On Mon, Mar 18, 2013 at 12:34:59PM -0500, Eric Sandeen wrote:
> > On 3/18/13 12:09 PM, Theodore Ts'o wrote:
> > > On Mon, Mar 18, 2013 at 11:10:51AM -0500, Eric Sandeen wrote:
> > 
> > <previous discussion thread about test 285 SEEK_HOLE test
> > breaking on ext4 due to change in opportunistic hole-filling
> > behavior and how to make it work again on ext4, and mention
> > of sysctl which makes it pass>
> > 
> > >> The test could do this too, right?
> > >>
> > >> _need_to_be_root
> > >>
> > >> and:
> > >>
> > >> if [ "$FSTYP" == "ext4" ]; then
> > >> 	ORIG_ZEROOUT_KB=`cat /sys/fs/ext4/$TEST_DEV/extent_max_zeroout_kb`
> > >> 	echo 0 > /sys/fs/ext4/$TEST_DEV/extent_max_zeroout_kb
> > >> fi
> > >>
> > >> and put it back to default in _cleanup:
> > >>
> > >> 	echo $ORIG_ZEROOUT_KB > /sys/fs/ext4/$TEST_DEV/extent_max_zeroout_kb
> > >>
> > >> That way we'd be testing seek hole correctness w/o being subject to
> > >> the vagaries in allocator behavior.
> > > 
> > > Yeah, the question is whether it would be more acceptable to put
> > > ext4-specific hacks like this into the test, or to modify
> > > src/seek_sanity_test.c so that it writes the test block-size block
> > > using pwrite at offset blocksize*42 instead of offset blocksize*10.
> > 
> > That seems like more of an obtuse hack, since it depends on current
> > default behavior, right?
> > 
> > Explicitly setting the zeroout to 0, with a comment as to why, should
> > make it clear to the reader of the test I think.
> > 
> > I'll have to look, xfs speculative preallocation fills in holes in
> > some cases as well, I'm not certain how it behaves on this test.
> 
> My impression was that we are not zeroing holes, but I'd also have to look to
> be sure.  ;)

Depends if the holes fall at EOF and there's a specualtive delalloc
over them. There isn't for this test, and the recent changes will
prevent it altogether, so there isn't a worry for XFS here.

> > But we could put in a specific tuning for xfs as well if needed.
> > 
> > If it becomes clear that every fs requires tuning to not opportunistically
> > fill in holes, then maybe we should make it non-generic, and only support
> > filesystems we've tested or tuned to work with the testcase.
> > 
> > > I had assumed putting hacks which tweaked sysfs tunables into the xfstest
> > > script itself would be frowned upon, but if that's considered OK, that
> > > would be great.
> > 
> > I don't see any real problem with it, myself.
> > 
> > cc: xfs list to see if there are any objections...
> 
> Seems like the options being discussed so far are:
> 
> 1) make the test fs specific

It was, originally.

> 2) filesystem specific hacks to disable opportunistic zeroing of holes

Not scalable.

> 3) modify the test output to work with current ext4 default behavior

And then we need hacks for each filesystem as the change behaviour.

> It might be hard to find a tuning to produce identical output for xfs and ext4
> (option 3), and option 1 and 2 are a also bit clunky.
> 
> How about option 4) fs-specific test output?

No, that's even worse. If we have filesystem specific output, then
write a set of filesystem specific tests that use a common piece of
code to run the test. the only difference between the tests will
then be the _supported_fs line. No need to hack in special output
file handling, etc.

> We wouldn't have multiple copies of the same test laying around, and ext4 could
> still run with default settings.

And when the default settings change, or some other bug fix comes
along?

So, let's step back a moment and ask ourselves what the test is
actaully trying to test. zero-out is not what it is trying to test,
nor is it trying to test specific file layouts. This is a basic
*defragmenter* sanity test. SO, we're testing 2 things:

	1. the defragmenter can recognise a fragmented file and fix
	it; and
	2. the defragmenter can recognise a sparse file and not
	modify it.

I know that Ted has already asked "what is an extent", but that's
also missing the point. An extent is defined, just like for on-disk
extent records, as a region of a file that is both logically and
physically contiguous. From that, a fragmented file is a file that
is logically contiguous but physically disjointed, and a sparse file
is one that is logically disjointed. i.e. it is the relationship
between extents that defines "sparse" and "fragmented", not the
definition of an extent itself.

Looking at the test itself, then.  The backwards synchronous write
trick that is used by 218?  That's an underhanded trick to make XFS
create a fragmented file. We are not testing that the defragmenter
knows that it's a backwards written file - we are testing that it
sees the file as logically contiguous and physically disjointed, and
then defragments it successfully.

Similarly, the remaining two tests are checking that a sparse file
with a couple of different layouts are detected and left alone. The
first sparse file will be both logically and physically disjointed,
the second one is logically disjointed but often ends up physically
contiguous.

That's what we are actually testing here. We are not testing that
exact, specific file layouts are handled correctly, we are checking
that the defragmenter recognises the different extent relationships
to determine which it shoul defragment and those it should leave
alone.

IOWs, we can change this test to create files in any way we want, as
long as the files fit the same 3 categories:

	1. logically contiguous, physically disjointed
		- successful defragmentation
	2. logically disjointed, physically disjointed
		- unchanged
	3. logically disjointed, physically contiguous
		- unchanged.

If that means we need to create the files differently to ensure we
end up with the layouts we need for different filesystems, then so
be it. If we can't do that generically for all the supported
filesystems, then lets split the test apart again into filesystem
specific tests and make 218 an XFS only test again.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

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

[Theodore Ts'o]

On Tue, Mar 19, 2013 at 10:12:33AM +1100, Dave Chinner wrote:
> I know that Ted has already asked "what is an extent", but that's
> also missing the point. An extent is defined, just like for on-disk
> extent records, as a region of a file that is both logically and
> physically contiguous. From that, a fragmented file is a file that
> is logically contiguous but physically disjointed, and a sparse file
> is one that is logically disjointed. i.e. it is the relationship
> between extents that defines "sparse" and "fragmented", not the
> definition of an extent itself.

Dave --- I think we're talking about two different tests.  This
particular test is xfstest #285.

The test in question is subtest #8, which preallocates a 4MB file, and
then writes a block filled with 'a' which is sized to the file system
block size, at offset 10*fs_block_size.  It then checks to make sure
SEEK_HOLE and SEEK_DATA is what it expects.

This is why opportunistic hole filling (to avoid unnecessary expansion
of the extent tree) is making a difference here.

The problem with filesystem specific output is that the output is
different depending on the blocksize.  The test is also determining
what's considered good or not as hard-coded logic in
src/seek_sanity_test.c.  So there's no fs-specific output at all in
xfstest #285.

> Looking at the test itself, then.  The backwards synchronous write
> trick that is used by 218?  That's an underhanded trick to make XFS
> create a fragmented file. We are not testing that the defragmenter
> knows that it's a backwards written file - we are testing that it
> sees the file as logically contiguous and physically disjointed, and
> then defragments it successfully.

What I was saying --- in the other mail thread --- is that it's open
to question whether a file which is being written via a random-write
pattern, resulting in a physically contiguous, but not contiguous from
a logical block number point of view, is worth defragging or not.  It
all depends on whether the file is likely to be read sequentially in
the future, or whether it will continue to be accessed via a random
access pattern.  In the latter case, it might not be worth defragging
the file.

In fact, I tend to agree with the argument we might as well attempt to
make the file logically contiguous so that it's efficient to read the
file sequentially.  But the people at Fujitsu who wrote the algorithms
in e2defrag had gone out of their way to detect this case and avoid
defragging the file so long as the physical blocks in use were
contiguous --- and I believe that's also a valid design decision.

Depending on how we resolve this particular design question, we can
then decide whether we need to make test #218 fs specific or not.
There was no thought design choics made by ext4 should drive changes
in how the defragger works in xfs or btrfs, or vice versa.

So I was looking for discussion by the ext4 developers; I was not
requesting any changes from the XFS developers with respect to test
#218.  (Not yet; and perhaps not ever.)

Regards,

						- Ted

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

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

[Dave Chinner]

On Mon, Mar 18, 2013 at 09:40:14PM -0400, Theodore Ts'o wrote:
> On Tue, Mar 19, 2013 at 10:12:33AM +1100, Dave Chinner wrote:
> > I know that Ted has already asked "what is an extent", but that's
> > also missing the point. An extent is defined, just like for on-disk
> > extent records, as a region of a file that is both logically and
> > physically contiguous. From that, a fragmented file is a file that
> > is logically contiguous but physically disjointed, and a sparse file
> > is one that is logically disjointed. i.e. it is the relationship
> > between extents that defines "sparse" and "fragmented", not the
> > definition of an extent itself.
> 
> Dave --- I think we're talking about two different tests.  This
> particular test is xfstest #285.

Yeah, I just realised that as I was reading through my ext4 list
feed...

> The test in question is subtest #8, which preallocates a 4MB file, and
> then writes a block filled with 'a' which is sized to the file system
> block size, at offset 10*fs_block_size.  It then checks to make sure
> SEEK_HOLE and SEEK_DATA is what it expects.

Yup, and as I just said in reply to myself, this means the same
reasoning applies - we can simply change the file layout to make
holes large enough that zero-out isn't an issue.

> > Looking at the test itself, then.  The backwards synchronous write
> > trick that is used by 218?  That's an underhanded trick to make XFS
> > create a fragmented file. We are not testing that the defragmenter
> > knows that it's a backwards written file - we are testing that it
> > sees the file as logically contiguous and physically disjointed, and
> > then defragments it successfully.
> 
> What I was saying --- in the other mail thread --- is that it's open
> to question whether a file which is being written via a random-write
> pattern, resulting in a physically contiguous, but not contiguous from
> a logical block number point of view, is worth defragging or not.  It
> all depends on whether the file is likely to be read sequentially in
> the future, or whether it will continue to be accessed via a random
> access pattern.  In the latter case, it might not be worth defragging
> the file.

AFAICT, that's something the defragmenter has no information on.
For example, two files with identical fragmentation patterns may be
accessed differently - how does the defragmenter know about that and
hence treat each file differently?

> In fact, I tend to agree with the argument we might as well attempt to
> make the file logically contiguous so that it's efficient to read the
> file sequentially.  But the people at Fujitsu who wrote the algorithms
> in e2defrag had gone out of their way to detect this case and avoid
> defragging the file so long as the physical blocks in use were
> contiguous --- and I believe that's also a valid design decision.

Sure - I never said it wasn't a valid categorisation. What is now
obvious to everyone is that it's a different defintion of
fragmentation to what the test (and xfs_fsr) expects. ;)

> Depending on how we resolve this particular design question, we can
> then decide whether we need to make test #218 fs specific or not.
> There was no thought design choics made by ext4 should drive changes
> in how the defragger works in xfs or btrfs, or vice versa.

Exactly. :)

> So I was looking for discussion by the ext4 developers; I was not
> requesting any changes from the XFS developers with respect to test
> #218.  (Not yet; and perhaps not ever.)

I know - what i was trying to do was to make sure that everyone
understood the theory behind the test before the discussion went too
far off the beaten track...

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

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

[Dave Chinner]

On Tue, Mar 19, 2013 at 10:12:33AM +1100, Dave Chinner wrote:
> On Mon, Mar 18, 2013 at 03:41:33PM -0500, Ben Myers wrote:
> > Hi Eric,
> > 
> > On Mon, Mar 18, 2013 at 12:34:59PM -0500, Eric Sandeen wrote:
> > > On 3/18/13 12:09 PM, Theodore Ts'o wrote:
> > > > On Mon, Mar 18, 2013 at 11:10:51AM -0500, Eric Sandeen wrote:
> > still run with default settings.
> 
> And when the default settings change, or some other bug fix comes
> along?
> 
> So, let's step back a moment and ask ourselves what the test is
> actaully trying to test. zero-out is not what it is trying to test,
> nor is it trying to test specific file layouts. This is a basic
> *defragmenter* sanity test. SO, we're testing 2 things:

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.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

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

[Theodore Ts'o]

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@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

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

[Dave Chinner]

On Mon, Mar 18, 2013 at 10:00:56PM -0400, 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
> shell script, if the file system in question was ext4.

Heh, you just mixed up 218 and 285 yourself. I crossed the streams,
and now the universe is going to end. ;)

Seriously, though, I'd prefer we don't need to tweak generic tests
for specific filesystems if changing the file layout will solve the
problem....

> 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?

>From an architectural POV, I think that if we need filesystem
specific tuning, it's not a generic test.

If we have common test that needs different setup and tunings for
each filesystem, then I'd prefer to think of a test "template" that
can be used by the filesytem specific tests. We already have this
sort of structure for some tests (e.g. _test_generic_punch()) where
we have factored out the common parts of several tests so they can
be shared.

Hence if we end up with needing to do this, I'd prefer to see
something like:

tests/template/foo

and the individual fs tests do:

tests/fs/foo-test

<setup test>
_clean_up()
{
	....
	<undo fs specific tuning>
}

<do fs specific tuning>

. tests/template/foo

<run test>

That way we can create shared test templates without needing to add
functions to the common/ directory, and so the common/
directory can slowly be cleaned up to contain only shared
infrastructure code....

Indeed, this makes it easy to run the same test with different
tunings and be able to see which tuning broke just by looking at the
test results...

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

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

[Eric Sandeen]

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@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

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

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs