Talking about Ext2 file system

We know that the file system is the organization and management of files on disk and provides the user with an operational interface (open, read, write, and so on), and almost every object in Unix can be viewed as a file. The kernel constructs structured file systems on unstructured hardware, and file abstraction is widely used throughout the system. Linux supports a variety of file systems, such as EXT2,EXT3,VFAT, EXT2 are compliant with the Linux standard file system.
We know that a disk can be partitioned into partitions, and each partition must first be formatted into a file system in a format using a format tool (such as a MKFS
order) before the file can be stored, and the formatting process will write information about the storage layout on the disk. The following figure is a storage layout after a disk partition has been formatted as a ext2 file system.

Figure 1 ext2 file system overall storage layout
the smallest unit stored in the file system is block, and how much of a block is determined when it is formatted, such as the MKE2FS-B option to set the block size to 1024, 2048, or 4096 bytes. The size of the boot block (bootblock) in the above figure is OK, 1KB, and the boot block is set by the PC standard to store disk partition information and startup information, and no file system can use the boot block. After the boot block is the start of the Ext2 file system, the Ext2 file system is divided into several blocks of the same size (block group), each of which consists of the following sections.
Super Block
Describes file system information for the entire partition, such as block size, file system version number, last mount time, and so on. Super blocks have a copy at the beginning of each block group.

A

Block group descriptor (Gdt,group descriptor Table)
consists of a number of block-group descriptors that correspond to how many block groups the entire partition is divided into. Each block group descriptor (Group descriptor) stores descriptive information for a block group, such as where the Inode table starts in the block group, where it starts with the data block, the number of free inode and data blocks, and so on. Like super blocks, block group descriptors have a copy at the beginning of each block group, this information is very important, once the super block accidentally damage will lose the entire partition of data, once the block group descriptor accidentally damaged will lose the entire block group of data, so they have multiple copies. Usually the kernel uses only the copy in the NO. 0 block group, when performing e2fsck inspection
piece system consistency, the Super block and block group descriptor in the NO. 0 block group are copied to other block groups, so that the damage can be reduced by using a different copy when the beginning of the NO. 0 block group is accidentally damaged.

Chunk Bitmap (block Bitmap)
Blocks in a block are used in this way: Blocks store data for all files, for example, the block size of a partition is 1024 bytes, a file is 2049 bytes, then need three blocks to save, even if the third block only save a byte also need to occupy an entire block; Super block, Block Group descriptor, block bitmap, The Inode bitmap and the Inode table store the description information for the block group. So how do you know which blocks are already used to store file data or other descriptive information, and which blocks are still available for free? A block bitmap is used to describe which blocks of an entire block have been used in which blocks are idle, which itself takes up a block, each of which represents a block in the group, and this bit is 1, which means that the block has been used, which
A bit of 0 indicates that the block is free to be available. Why use the DF command to count the entire disk's used space is very fast. Because you just need to look at the block bitmap for each block group without having to search the entire partition. Instead, using the du command to view the used space of a larger directory is very slow because
To inevitably search through all the files in the entire directory. Another problem associated with this is how many block groups will be drawn when you format a partition. The main limitation is that the block bitmap itself must occupy only one block. The default block size is 1024 bytes when formatted with MKE2FS, you can specify the block size with the-b parameter, now set the block size to specify B bytes, then a block can have 8b bit, so that a block bitmap size can represent 8b block occupancy, so a block group can have 8b blocks, If the entire partition has s block, then there can be a s/(8b) block group. When formatted, you can specify how many blocks a block group has with the-G parameter, but usually do not need to manually specify, the MKE2FS tool calculates the optimal number.

Inode Bitmap (inode Bitmap)
Similar to a block bitmap, itself occupies a block, where each bit indicates whether an inode is available for free.

Inode table (inode table)
We know that a file, in addition to the data needed for storage, some descriptive information also needs to be stored, such as file types (general, directory, symbolic links, etc.), permissions, file size, creation/modification/access time, and so on, that is, the information that the Ls-l command sees, which exists in the inode rather than in the data block. Each file has an inode, and all the Inode in a block group form the Inode table. The number of blocks in the Inode table is to be determined and written to the block group descriptor, and the default policy for the MKE2FS formatter is how many 8KB a block group is allocated. Because the data block accounted for the vast majority of the entire block group, you can also approximate how many 8KB of data block allocated to the number of inode, in other words, if the average size of each file is 8KB, when the partition is full when the Inode table will be more fully utilized, data block is not wasted. If this partition is a large file (such as a movie), the data block is used up when the inode will have some waste, if this partition is a small file (such as source code), it is possible that the data block has not finished the inode has been used up, the data block may have a lot of waste. If the user is able to make a prediction of the size of the file to be stored after the partition is formatted, you can also use the MKE2FS-i parameter to manually specify how many bytes to allocate for each inode.

Data block
Depending on the file type, there are several things:
-> for regular files, the data for a file is stored in a block of data.
-> for the directory, all the file names and directory names under the directory are stored in the data block, note that the file name is saved in the data block of the directory in which it resides, and other information that the Ls-l command sees is saved in the inode of the file, except for the filename. Note This concept: A directory is also a file, a special type of file.
-> for symbolic links, if the target path name is shorter, it is stored directly in the Inode for faster lookup, and a block of data is allocated if the target path name is longer.
-> device files, FIFO and sockets and other special files do not have data blocks, the device files of the main device number and the secondary device number stored in the inode.