Message-ID: <20130317061259.GA21447@gmail.com>
Date:	Sun, 17 Mar 2013 14:13:00 +0800
From:	Zheng Liu <gnehzuil.liu@...il.com>
To:	Theodore Ts'o <tytso@....edu>
Cc:	Eric Whitney <enwlinux@...il.com>, linux-ext4@...r.kernel.org
Subject: Re: possible dev branch regression - xfstest 285/1k

Hi Ted,

Thanks for looking at this.

On Sat, Mar 16, 2013 at 11:06:48PM -0400, Theodore Ts'o wrote:
> On Sat, Mar 16, 2013 at 11:09:23PM +0800, Zheng Liu wrote:
> > 
> > I see what's going on.  First of all it isn't a bug. :-)  Please let me
> > describe why it happens.
> > 
> > In this commit (4f42f80a8f), it tries to fix a bug that we never zero
> > out an unwritten extent.  So after applied it, when an unwritten extent
> > is converted, it could be zeroed out.  In xfstests #285 subtest 08 it
> > preallocates an unwritten extent which is 4MB.  Then it writes some data
> > at offset 10 * blocksize, which the length is one blocksize, and calles
> > sync_file_range(2) to flush it.
> 
> Specifically, we are now honoring the default setting which sets the
> max_zeroout_kb value to be 32.  With a 4k block file system, if we
> were to zeroout the extent, we would have to zero out 40k, which is
> greater than 32k, so resulting file after pwrite(fd, 4096, 40960)
> looks like this:
> 
> % filefrag -v /u1/foo08 
> Filesystem type is: ef53
> File size of /u1/foo08 is 4194304 (1024 blocks of 4096 bytes)
>  ext:     logical_offset:        physical_offset: length:   expected: flags:
>    0:        0..       9:    1852416..   1852425:     10:             unwritten
>    1:       10..      10:    1852426..   1852426:      1:            
>    2:       11..    1023:    1852427..   1853439:   1013:             unwritten,eof
> /u1/foo08: 1 extent found
> 
> With a 1k block file system, we only need to zero out 10k, which is
> less than 32k, and so after pwrite(fd, 1024, 10240), the file looks
> like this:
> 
> % filefrag -v /mnt/foo08
> Filesystem type is: ef53
> File size of /mnt/foo08 is 4194304 (4096 blocks of 1024 bytes)
>  ext:     logical_offset:        physical_offset: length:   expected: flags:
>    0:        0..      10:      81921..     81931:     11:            
>    1:       11..    4095:      81932..     86016:   4085:             unwritten,eof
> /mnt/foo08: 1 extent found
> 
> If we run src/seek_sanity_test by hand, we can make it happy by
> setting the following configuration option before we run it:
> 
> echo 0 > /sys/fs/ext4/<dev>/extent_max_zeroout_kb 
> 
> I'm not sure what's the best way to make xfstest #285 happy, though.
> 
> One way might be to change the test so that instead of writing the
> data at offset bufsize*10, we change it so it writes the data at
> offset bufsize*40, and change the expected values accordingly.  The
> other would be to add some kind of ext4-specific hack to test #285
> which manually sets the extent_max_zeroout_kb tuning parameter after
> the file system is mounted.
> 
> I'm not sure which is more likely to be accepted by the xfstests
> maintainers.  I suspect the former, but they may not like either
> solution, in which case we might have to disable 285 for ext4 and
> create an ext4-specific test.

It has been on my TODO list for a long time.  I will try the former.  I
think we just need to disable 285 for ext4 with indirect-based file and
create a new generic test for all file systems.

Regards,
                                                - Zheng
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists