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: <20130710172409.GC28076@thunk.org>
Date:	Wed, 10 Jul 2013 13:24:09 -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 Wed, Jul 10, 2013 at 06:13:08PM +0200, Felipe Monteiro de Carvalho wrote:
> 
> When I am reading a ext4 file system and I find that there exists an
> inode /etc/ with groupnr 32 and nodenr 260099, will this group 32 be
> in the same position (distance in bytes from the beginning of the
> disk) as in ext3? Or will the flex_bg make the first 16 groups fit
> into the size that previously 1 group utilized? So group 32 in ext 4
> would be in the physical position of group 2 in ext3.
> 
> If I have s_log_groups_per_flex=4 (seams the be the most popular
> value), then each and every set of 16 groups will be groups into
> flex_bgs or only some are grouped into flex_bgs?
> 
> Basically I have a reader for ext3 and I added EXTENT support and it
> works now fine for the group 0, but for higher groups it is not
> working and I'm trying to find out what I need to change ... I'm
> trying to find what physically changed here... but it is a hard
> battle. Much harder than EXTENT support was.

Your reader shouldn't care about the flex_bg feature.  From a reader's
perspective, flex_bg's don't matter.  Just ignore it.  Just think in
terms of block groups, and you'll be find.  The Flex_bg feature
matters for how our block allocation strategy works, and it influences
how online resizing works, and it tells e2fsck that it's ok for the
inode table for a particular block group to be located outside of its
own block group (which is where the "flexible" came from).

But from a read-only client is concerned, it doesn't matter.  Just use
the block group descriptors to find the location of the inode table,
and just expunge the concept of flex_bg's from your mind entirely.  Or
better yet, just use the libext2fs library, and don't try to reinvent
the wheel.....

					- 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