Re: 64bit filesystem questions

[Phillip Susi <psusi@cfl.rr.com>]

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.