From: Zheng Liu <gnehzuil.liu@gmail.com>
To: Theodore Ts'o <tytso@mit.edu>
Cc: "Lukáš Czerner" <lczerner@redhat.com>,
"Eric Whitney" <enwlinux@gmail.com>,
linux-ext4@vger.kernel.org, "Zheng Liu" <wenqing.lz@taobao.com>
Subject: Re: [REGRESSION] allocated N with only M reserved metadata blocks
Date: Wed, 13 Mar 2013 16:43:18 +0800 [thread overview]
Message-ID: <20130313084318.GA11553@gmail.com> (raw)
In-Reply-To: <20130312161913.GA4959@thunk.org>
On Tue, Mar 12, 2013 at 12:19:13PM -0400, Theodore Ts'o wrote:
> On Tue, Mar 12, 2013 at 03:11:23PM +0100, Lukáš Czerner wrote:
> > So there is indeed a problem with the mentioned commit
> >
> > 67a5da564f97f31c4054d358e00b34d7ee570da5
> >
> > Due to the bug in that code is has exactly the opposite result -
> > with this commit we will _never_ zero out blocks instead of creating
> > uninitialized extents. In other words, we will always create
> > uninitialized extent.
>
> Whoops. I even remember how this bug happened. Originally
> max_zeroout was in file system blocks, and it was suggested that we
> change this to use units of kilobytes instead. Unfortunately, this
> change wasn't done completely. :-(
>
> > This can be easily fixed by the following patch (which makes the
> > warning go away), but it brings up a question whether this "optimization"
> > was worth it in the first place since noone noticed that it had exactly
> > the opposite effect than it should have had :)
>
> Well, I had noticed that random AIO workloads resulted in the extent
> tree getting far more fragmented than I had expected. (See previous
> discusisons about how we really need to improve our ability to merge
> empty leaf and index nodes in the extent tree.)
Agree, we could do better in merging extent tree. I will take a look at
it, but, sorry, my plate is too full recently. So it has a low priority.
Regards,
- Zheng
--
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
prev parent reply other threads:[~2013-03-13 8:27 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-11 18:54 [REGRESSION] allocated N with only M reserved metadata blocks Theodore Ts'o
2013-03-11 21:02 ` Eric Whitney
2013-03-11 21:22 ` Theodore Ts'o
2013-03-12 7:58 ` Lukáš Czerner
2013-03-12 9:48 ` Lukáš Czerner
2013-03-12 14:11 ` Lukáš Czerner
2013-03-12 16:19 ` Theodore Ts'o
2013-03-13 8:43 ` Zheng Liu [this message]
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=20130313084318.GA11553@gmail.com \
--to=gnehzuil.liu@gmail.com \
--cc=enwlinux@gmail.com \
--cc=lczerner@redhat.com \
--cc=linux-ext4@vger.kernel.org \
--cc=tytso@mit.edu \
--cc=wenqing.lz@taobao.com \
/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.