From: Zheng Liu <gnehzuil.liu@gmail.com>
To: Andreas Dilger <adilger@dilger.ca>
Cc: Zheng Liu <wenqing.lz@taobao.com>,
Eric Sandeen <sandeen@redhat.com>,
ext4 development <linux-ext4@vger.kernel.org>,
Zach Brown <zab@zabbo.net>
Subject: Re: [PATCH v2] ext4: dynamical adjust the length of zero-out chunk
Date: Tue, 17 Jul 2012 15:55:26 +0800 [thread overview]
Message-ID: <20120717075526.GA4375@gmail.com> (raw)
In-Reply-To: <7B794B69-EF6C-4279-83D7-EA47E35CD54C@dilger.ca>
On Thu, Jul 12, 2012 at 10:51:12AM -0600, Andreas Dilger wrote:
> On 2012-07-12, at 8:49 AM, Eric Sandeen wrote:
> > On 7/12/12 1:48 AM, Zheng Liu wrote:
> >> From: Zheng Liu <wenqing.lz@taobao.com>
> >>
> >> Currently in ext4 the length of zero-out chunk is set to 7. But it is
> >> too short so that it will cause a lot of fragmentation of extent when
> >> we use fallocate to preallocate some uninitialized extents and the
> >> workload frequently does some uninitialized extent conversions. Thus,
> >> now we set it to 256 (1MB chunk), and put it into super block in order
> >> to adjust it dynamically in sysfs.
> >
> > Does this in fact help the workload for which you wanted the non-flagged
> > fallocate interface?
> >
> > I'm a little wary of adding another user tunable; how will the user have
> > any idea what value to use here?
>
> It would make sense to use the s_raid_stripe_width as the default value for
> this parameter. The other thing we need to pay attention to is that the
> growth of the extent zeroing be done on a RAID or erase-block aligned manner.
> Otherwise, this might cause extra IO that doesn't benefit the application.
There is a problem that we use the s_raid_stripe_width as the default
value, which is that this value will be 0 when we simply use mkfs.ext4
without '-E stripe-width=XXX'. when this value is 0, we still need to
choose a number as the default value. So I think that we can choose 256
when the s_raid_stripe_width is 0.
Regards,
Zheng
> It appears that the current code does not pay attention to alignment, and
> that should be fixed before landing this patch with larger zero-out sizes.
next prev parent reply other threads:[~2012-07-17 7:46 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-12 6:48 [PATCH v2] ext4: dynamical adjust the length of zero-out chunk Zheng Liu
2012-07-12 14:49 ` Eric Sandeen
2012-07-12 16:51 ` Andreas Dilger
2012-07-17 7:55 ` Zheng Liu [this message]
2012-08-13 3:22 ` Theodore Ts'o
2012-08-13 6:55 ` Zheng Liu
2012-08-13 17:32 ` Zach Brown
2012-08-13 18:40 ` Theodore Ts'o
2012-08-13 19:49 ` Zach Brown
2012-08-13 21:35 ` Theodore Ts'o
2012-08-14 15:13 ` [PATCH] ext4: make the zero-out chunk size tunable Theodore Ts'o
2012-08-14 15:15 ` [PATCH -v4] " Theodore Ts'o
2012-07-17 7:19 ` [PATCH v2] ext4: dynamical adjust the length of zero-out chunk Zheng Liu
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=20120717075526.GA4375@gmail.com \
--to=gnehzuil.liu@gmail.com \
--cc=adilger@dilger.ca \
--cc=linux-ext4@vger.kernel.org \
--cc=sandeen@redhat.com \
--cc=wenqing.lz@taobao.com \
--cc=zab@zabbo.net \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).