From: Zheng Liu <gnehzuil.liu@gmail.com>
To: Theodore Ts'o <tytso@mit.edu>
Cc: Eric Whitney <enwlinux@gmail.com>, linux-ext4@vger.kernel.org
Subject: Re: possible dev branch regression - xfstest 285/1k
Date: Sun, 17 Mar 2013 14:13:00 +0800 [thread overview]
Message-ID: <20130317061259.GA21447@gmail.com> (raw)
In-Reply-To: <20130317030648.GA14225@thunk.org>
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
next prev parent reply other threads:[~2013-03-17 5:57 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-15 22:28 possible dev branch regression - xfstest 285/1k Eric Whitney
2013-03-16 2:32 ` Zheng Liu
2013-03-16 15:09 ` Zheng Liu
2013-03-17 3:06 ` Theodore Ts'o
2013-03-17 6:13 ` Zheng Liu [this message]
2013-03-18 16:10 ` Eric Sandeen
2013-03-18 16:54 ` gnehzuil.liu
2013-03-18 17:09 ` Theodore Ts'o
2013-03-18 17:34 ` Eric Sandeen
2013-03-18 17:34 ` Eric Sandeen
2013-03-18 20:41 ` Ben Myers
2013-03-18 23:12 ` Dave Chinner
2013-03-18 23:12 ` Dave Chinner
2013-03-19 1:40 ` Theodore Ts'o
2013-03-19 2:07 ` Dave Chinner
2013-03-19 2:07 ` Dave Chinner
2013-03-19 1:47 ` Dave Chinner
2013-03-19 1:47 ` Dave Chinner
2013-03-19 2:00 ` Theodore Ts'o
2013-03-19 2:22 ` Dave Chinner
2013-03-19 2:22 ` Dave Chinner
2013-03-19 2:28 ` Eric Sandeen
2013-03-19 8:50 ` Lukáš Czerner
2013-03-19 8:50 ` Lukáš Czerner
2013-03-17 3:36 ` Eric Whitney
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130317061259.GA21447@gmail.com \
--to=gnehzuil.liu@gmail.com \
--cc=enwlinux@gmail.com \
--cc=linux-ext4@vger.kernel.org \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.