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