linux-ext4 - Re: Status of META

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] [day] [month] [year] [list]

Message-Id: <A5C905B1-EC90-4C03-8157-4B2EBEEE5105@dilger.ca>
Date:	Sun, 18 Mar 2012 17:20:41 -0600
From:	Andreas Dilger <aedilger@...il.com>
To:	Ted Ts'o <tytso@....edu>
Cc:	Phillip Susi <psusi@...ntu.com>,
	ext4 development <linux-ext4@...r.kernel.org>
Subject: Re: Status of META_BG?

On 2012-03-18, at 2:41 PM, Ted Ts'o wrote:
> On Thu, Mar 15, 2012 at 01:55:36PM -0400, Phillip Susi wrote:
>>> META_BG addresses both of these issues by distributing the group
>>> descriptor blocks into the filesystem for each "meta group" (= the
>>> number of groups whose descriptors fit into a single block).
>> 
>> So it puts one GD block at the start of every several block groups?
>> Wouldn't that drastically slow down opening/mounting the fs since
>> the disk has to seek to every block group?
> 
> Not necessarily; right now we pull in every single block group
> descriptor at mount time because we need to update s_free_inodes_count
> and s_free_blocks_count.  If we change things so that we only pull in
> the block group descriptors at mount time after a journal replay (but
> not after a clean umount, when the last inodes count and free blocks
> count should be correctly updated), that would avoid seeking to every
> 16th block group at mount time.  

The lazy init thread also walks all of the group descriptors in the
background after mount, so this could be handled asynchronously even
without any changes.

That is OK if there are free blocks and no user processes trying to
write files, but we've had slowdowns in the past due to block bitmap
lookups of every group looking for free space.  Loading the group
descriptors will be 32x or 16x faster than loading the bitmaps, but
we still saw delays of up to 10 minutes for filesystems under 16TB
due to seeking (before flex_bg) so I imagine this will also be an
issue with meta_bg.

It would be nice to retroactively define the semantics of flex_bg +
meta_bg to mean that 2^s_log_groups_per_flex group descriptors are
co-located.

Cheers, Andreas

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