linux-ext4 - Re: 64bit filesystem questions

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: <4DF28AC0.2010505@cfl.rr.com>
Date:	Fri, 10 Jun 2011 17:21:04 -0400
From:	Phillip Susi <psusi@....rr.com>
To:	Andreas Dilger <adilger@...ger.ca>
CC:	linux-ext4@...r.kernel.org
Subject: Re: 64bit filesystem questions

On 6/10/2011 4:37 PM, Andreas Dilger wrote:
> I hope it is obvious that a single bitmap block can only address the number
> of bits (==blocks) that fit within that block.  To address more blocks the
> block bitmap needs to be larger than a single block in size.  One possible
> way to do this (discussed early on for ext4) would be to have N block
> bitmap blocks per group.  That raises issues of how to address those blocks
> for each "block group", and what the meaning of a "block group" really is.

I thought it was obvious that if there were more blocks, then you would 
have more than one bitmap block and it would just follow the first.

> The other (very similar, but not identical) approach is to essentially merge
> N adjacent "block groups" into a single "large block group" that has N block
> bitmaps, and addresses N * blocksize * 8 blocks per "large block group".
> In this case "N" is the flex_bg factor (constrained to 2^n), and the "large
> block group" is called a "flex group".  It achieves exactly the same thing
> as having N block bitmaps per group, with the only difference that there are
> N group descriptors that point to the bitmaps, and they no longer have to be
> located within the groups themselves

The other side effect is that you have N inode tables and N inode 
bitmaps.  A typical fs these days seems to have 8192 inodes in each bg, 
which gives far more inodes than needed, and only uses 1/4 of the inode 
bitmap block.

Now that I've looked a bit more at the code, it seems the 32k block 
limit comes from the old ext2 block group descriptor only having a 16 
bit field for the free blocks count.  This was fixed in the ext4 bg 
descriptor, but it seems that is not actually used except on a 64bit fs. 
  It looks like a few more bits of code need cleaned up to allow for 
more blocks per group when using 64bit.

> If you treat the four "bbbb" blocks as a single block bitmap, and "iiii"
> as a single inode bitmap, and the contiguous range of free blocks as a
> single group, it is exactly what you are asking for - a larger bitmap.

While each of those inode bitmaps may follow the previous, each one is 
typically only 1/4 used and the rest ignored.  It would be better to 
have only the single inode bitmap for a single, larger bg.
--
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