linux-ext4 - Re: Beginner questions about ext4

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]

Message-ID: <20130623115953.GA16193@thunk.org>
Date:	Sun, 23 Jun 2013 07:59:53 -0400
From:	Theodore Ts'o <tytso@....edu>
To:	Felipe Monteiro de Carvalho <felipemonteiro.carvalho@...il.com>
Cc:	linux-ext4@...r.kernel.org
Subject: Re: Beginner questions about ext4

On Sun, Jun 23, 2013 at 06:29:18AM +0000, Felipe Monteiro de Carvalho wrote:
> 
> I am still very much interesting in knowing this! Are all groups flexible 
> groups when FLEX_BG feature is activated?
> 
> I found this image for how things relate to one another without flex_bg:
> 
> http://origin-ars.els-cdn.com/content/image/1-s2.0-S1742287612000357-gr1.jpg
> 
> Does anyone know if there is a simular image with flex_bg???

Historically, before flex_bg, the allocation bitmaps and inode tables
for a particular block group had to be located within that block
group, per the image that you've referenced above.

This had two difficulties.  The first is that every 128MB (assuming a
4k blocksize and the default/maximum number of blocks per block
group), there would be file system metadata, thus breaking up the
maximum contiguous free space available for data blocks.  The second
is that if e2fsck or resize2fs needed to relocate a metadata block, it
reduced the flexibility of where the new location of that metadata
block might be.

So the flex_bg feature relaxes this constraint.  So if we can put the
metadata blocks anywhere, where do we put them?  That's where
s_log_flex_bg_size in the superblock comes in.  This is a default
policy used by mke2fs and for online resizing where we try to put the
allocation bitmaps and inode table blocks at the beginning of a flex
group, where flex group N is defined as blocks falling within the
range (N * flex_bg_size) through (((N + 1) * flex_bg_size) - 1).

Note though that this is not a mandatory layout; there may be times
where e2fsck or resize2fs may need to change where these blocks end up
living.

The other thing which we do with this flex_bg layout is that it
influences ext4's inode and block allocation hueristcs.  For example,
ext4 will try to bias its allocation of directory blocks to try to
keep them within the first block group, and it will bias the
allocation of data blocks away from the first block group in a flex_bg
group.

Regards,

						- 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