linux-ext4 - Re: [REGRESSION] allocated N with only M reserved metadata blocks

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 12 Mar 2013 12:19:13 -0400
From:	Theodore Ts'o <tytso@....edu>
To:	Lukáš Czerner <lczerner@...hat.com>
Cc:	Eric Whitney <enwlinux@...il.com>, linux-ext4@...r.kernel.org,
	Zheng Liu <wenqing.lz@...bao.com>
Subject: Re: [REGRESSION] allocated N with only M reserved metadata blocks

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html