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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
