Ext3 and ext4 File System Disk Layout

 

Disk Layout

To better understand the online resizing mechanism, we first need to understand the disk layout of the ext3 and ext4 file systems. For the implementation of this function, these two file systems have the same structure on the disk, and we will not introduce any content unrelated to the online resize function to simplify and highlight the key.

The ext3 file system divides the disks or partitions managed by the file system (excluding boot blocks) into different block groups. The size of each block group is the same. Of course, the number of blocks managed by the last block group may be smaller. The size of the blocks depends on the size of the file system when the file system is created, for a 4 K file system block, the block group size is 168 MB. Each block group contains some important metadata information, as shown in Figure 1:

Figure 1 ext3 and ext4 File System Disk Layout
 

Each block group contains one block bitmap block, one inode bitmap block, and one or more blocks used to describe inode tables and data blocks used to store file data. In addition, it may also contain Super blocks and all block group descriptor tables (depending on the block group number and the parameters used when the file system is created ). The following describes the metadata.

Block bitmap is used to describe the distribution status of the blocks managed by the block group. If the bit corresponding to a block is not set, it indicates that the block is not allocated and can be used to store data. Otherwise, indicates that the block is used to store data or cannot be used (for example, the block does not exist physically ). Because the block bitmap only occupies one block, this determines the size of the block group.

Inode bitmap is used to describe the allocation status of inode managed by this block group. We know that inode is used to describe the metadata of a file. Each inode corresponds to a unique number in the file system. If the inode bitmap contains the corresponding location, it indicates that the inode has been allocated; otherwise, it can be used. Because it only occupies one block, this also limits the maximum number of inode that can be used in a block group.

Inode tables are used to store inode information. It occupies one or more blocks (multiple inodes are stored in one block for effective space utilization). The size depends on the parameters when the file system is created, the maximum space occupied by inode bitmap is determined by the limitations of inode bitmap.

Super block is used to store the configuration parameters (such as block size, total number of blocks, and inode number) and dynamic information (such as the number of idle blocks and inode number) of the file system ), it is 1 K at the starting position of the file system and occupies 1 K. For system robustness, each block group initially has a copy of the super block and group Descriptor Table (gdt will be used below), but when the file system is very large, this wastes a lot of blocks (especially the gdt occupies a lot of blocks). Later, we used a sparse method to store these copies. Only the block number is 3, 5, block groups of the power of 7 (for example, 1, 3, 5, 7, 9, 25, 49 ...) Back up this copy. Generally, only the super block information of the master copy (0th block group) is used by the file system. Other copies are used only when the master copy is damaged.

Gdt is used to store block group descriptors. It occupies one or more data blocks, depending on the size of the file system. It mainly contains the block bitmap, inode bitmap and inode table location, the number of currently idle blocks, the number of inode, and the number of directories used (used to balance the number of directories in each block group ), for specific definitions, see the struct ext3_group_desc in the ext3_fs.h file. Each block group corresponds to such a descriptor. Currently, this structure occupies 32 bytes. Therefore, for file systems with a block size of 4 K, each block can store 128 block group descriptors. Gdt is very important for locating the metadata of the file system, so it is backed up like a super block. Gdt has the same content in each block group (if any) and shares the same number of blocks. From the above introduction, we can see that the metadata in the block group, such as the block bitmap, inode bitmap, and inode table, is not fixed. Of course, by default, when a file system is created, its location is the same in each block group, as shown in figure 2 (assuming that it is stored in Sparse Mode and N is not the power of 3, 5, 7 ):

Figure 2 store the super block and block group Descriptor Table in Sparse Mode

From the figure, we can see that each block group is of the same size, except that the last block group may contain fewer blocks (expressed by dotted lines and shadows ).