Question: why there are 256 blocks for backup of superblock and block group descriptor table?

[mypark42]

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?

lba: 802, [[SuperBlock]]
        inodes_count: ff00
        blocks_count: 3fc00
        r_blocks_count: 3300
        free_blocks_count: 3b3e1
        free_inodes_count: fef5
        first_data_block: 1
        log_block_size: 0
        log_frag_size: 0
        blocks_per_group: 2000
        frags_per_group: 2000
        inodes_per_group: 7f8
        mtime: 0
        wtime: 64e74dec
        mnt_count: 0
        max_mnt_count: ffff
        magic: ef53
        state: 1
        errors: 1
        minor_rev_level: 0
        lastcheck: 64e74dec
        checkinterval: 0
        creator_os: 0
        rev_level: 1
        def_resuid: 0
        def_resgid: 0
        first_ino: b
        inode_size: 100
        block_group_nr: 0
...

lba: 804
[[Block Group Descriptor]]
        block_bitmap: 103
        inode_bitmap: 104
        inode_table: 105
        free_blocks_count: 1cf0
        free_inodes_count: 7ed
        used_dirs_count: 2

[[Block Group Descriptor]]
        block_bitmap: 2103
        inode_bitmap: 2104
        inode_table: 2105
        free_blocks_count: 1cfe
        free_inodes_count: 7f8
        used_dirs_count: 0

[[Block Group Descriptor]]
        block_bitmap: 4001
        inode_bitmap: 4002
        inode_table: 4003
        free_blocks_count: 1e00
        free_inodes_count: 7f8
        used_dirs_count: 0

[[Block Group Descriptor]]
        block_bitmap: 6103
        inode_bitmap: 6104
        inode_table: 6105
        free_blocks_count: 1cfe
        free_inodes_count: 7f8
        used_dirs_count: 0

[[Block Group Descriptor]]
        block_bitmap: 8001
        inode_bitmap: 8002
        inode_table: 8003
        free_blocks_count: 1e00
        free_inodes_count: 7f8
        used_dirs_count: 0

[tytso]

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.

[mypark42]

Thank you for answering my question!