Chapter 9: The Extended Filesystem Family
The contents of each group descriptor include not only status entries indicating the number of free
blocks (bg_free_blocks_count), and inodes (bg_free_inodes_count)aswellasthenumberofdirec-
tories (bg_used_dirs_count), but also, and more importantly, two pointers to blocks containing the
bitmaps needed to organize used and free blocks and inodes. These are calledbg_block_bitmapand
bg_inode_bitmapand are implemented by means of a 32-bit number that uniquely describes a block on
the hard disk.
The block to whichbg_block_bitmaprefers is not used to store data. Each of its bits stands for a data
block of the current block group. If a bit is set, the block is being used by the filesystem; otherwise,
the block is available. Because the position at which the first data block is located is known and all data
blocks are in linear sequence, it is easy for the kernel to convert between bit positions in the block bitmap
and the associated block positions.
The same method is applied for the inode pointerbg_inode_bitmap. It, too, points to a block whose
individual bits are used to describe all inodes of a block group. Because it is also known in which blocks
the inode structures are located and how big the inodestructure is, the kernel can convert between the
bitmap entries and the associated positions on the hard disk (see also Figure 9-2).
Each block group contains not just one but a large number of group descriptor structures — a copy
for each block group in the filesystem. From each block group, it is therefore possible to determine the
following information forevery singleblock group in the system:
❑ The position of the block and inode bitmaps.
❑ The position of the inode table.
❑ Thenumberoffreeblocksandinodes.
The blocks used as block and inode bitmaps are not, however, duplicated in each block group for all
other block groups: in fact, there is only one occurrence of them in the system. Each block group has a
localblock for the block bitmap and an extra block for the inode bitmap. Nevertheless, all data and inode
bitmaps of the remaining groups can be accessed fromeveryblock group because their position can be
determined with the help of the entries in the group descriptor.
Because the filesystem block size is variable, the number of blocks that can be represented by a block
bitmap also changes accordingly. If the block size is set to 2,048 bytes, each block has exactly 2,048× 8 =
16,384bitsthat can be used to describe the state of data blocks. Similarly, block sizes of 1,024 and 4,096
bytes mean that exactly 8,192 and 32,768 blocks can be managed. This data are summarized in Table 9-2.
In our example, we use only 2 bytes to store the block bitmap so that exactly 16 blocks can be addressed.
The data blocks that hold the actual contents of the filesystem files (and the data used for indirection) are
at the end of the block group.
Table 9-2: Maximum Sizes in a Block Group
Block size Number of blocks
1,024 8,192
2,048 16,384
4,096 32,768
