From: Theodore Ts'o <tytso@mit.edu>
To: "Lukáš Czerner" <lczerner@redhat.com>
Cc: 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: Tue, 12 Mar 2013 12:19:13 -0400 [thread overview]
Message-ID: <20130312161913.GA4959@thunk.org> (raw)
In-Reply-To: <alpine.LFD.2.00.1303121502240.7128@dhcp-1-104.brq.redhat.com>
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.)
It will be worthwhile to fix this bug and then see how much remains of
extent tree fragmentation problem once this is fixed....
Thanks for the catch! When you have a chance, could you resend with a
commit description?
> However it still does not resolve the issue completely, because even
> without the zeroout we should have had reserved enough metadata
> blocks to cover the extent split. I still need to investigate
> a little bit further.
Yep, agreed. Sounds like there is more than one bug hiding here.
- Ted
--
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
next prev parent reply other threads:[~2013-03-12 16:19 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 [this message]
2013-03-13 8:43 ` 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=20130312161913.GA4959@thunk.org \
--to=tytso@mit.edu \
--cc=enwlinux@gmail.com \
--cc=lczerner@redhat.com \
--cc=linux-ext4@vger.kernel.org \
--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 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).