Closed mypark42 closed 1 year ago
The gap is not for backup of the block group descriptor; it is instead reserved space so the file system can be resized online (while it is mounted). If your OS doesn't support online resize you can create the file system without the resize_inode feature, This is also much clearer if you use the dumpe2fs program.
Compare what happens when you run the command "mke2fs -t ext4 /tmp/foo.img 1G" and then examine the file system using dumpe2fs /tmp/foo.img:
Group 0: (Blocks 0-32767)
Primary superblock at 0, Group descriptors at 1-1
Reserved GDT blocks at 2-64
Block bitmap at 65 (+65)
Inode bitmap at 66 (+66)
Inode table at 67-578 (+67)
32183 free blocks, 8181 free inodes, 2 directories
Free blocks: 585-32767
Free inodes: 12-8192
But you run "mke2fs -t ext2 -O ^resize_inode /tmp/foo.img 1G", then dumpe2fs will display for the first block group:
Group 0: (Blocks 0-32767)
Primary superblock at 0, Group descriptors at 1-1
Block bitmap at 2 (+2)
Inode bitmap at 3 (+3)
Inode table at 4-515 (+4)
32247 free blocks, 8181 free inodes, 2 directories
Free blocks: 521-32767
Free inodes: 12-8192
The exact number of reserved GDT blocks is dependant on how much the file system can be resized while it is mounted. By default, we reserve enough blocks so that a file system can be resized by a 1000x, up to a limit of 16TB for 4k block size file systems (since there is a different scheme used after the block number exceeds 32-bits). How that gets handled is more complicated, so we'll keep it simple here. How much the file system can be tuned via mke2fs -E resize=NNN. See the man page for more details.
Thank you for answering my question!
I'm implementing ext2 filesystem for my hubby OS.
In this article, Superblock and BGDT(block group descriptor table) is just two block size.
When printing the BGDT, there are additional 256 block offset to the block bitmap of backup block groups.
So, I guess there are 256 blocks for backup!
But, why there are 256 blocks and not 2 blocks?