Linux file System (EXT2)

A disk can be partitioned into multiple partitions, and each partition must first be formatted with a format tool (such as a MKFS command) to format the file system before the file is stored, and the formatted process writes some information about the storage layout on disk. is a disk partition that is formatted as a storage layout After the ext2 file system:

The smallest unit stored in the file system is block, and how large a block is determined at the time of formatting, such as the-B option for MKE2FS can set the block size to 1024, 2048, or 4096 bytes. While the size of the boot block (bootblock) is determined, is 1KB, the boot block is defined by the PC standard, used to store disk partition information and startup information, no file system can use the boot block. After the boot block is the beginning 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 components:

Super Block describes the file system information for the entire partition, such as the block size, file system version number, time of the last mount, and so on. The super block has one copy at the beginning of each block group.

The Block group Descriptor Table (Gdt,group descriptor) consists of a number of block group descriptors, and the entire partition is divided into the number of block groups that correspond to the number of block group descriptors. Each block group descriptor (Group descriptor) stores the descriptive information for a block group, such as where the Inode table begins in this block group, where it starts as a block of data, how many free inode and data blocks are available, and so on. Similar to the Super block, the Block group descriptor has a copy at the beginning of each block group, which is very important, and once the super block is accidentally damaged it loses the entire partition's data, and once the block group descriptor is accidentally corrupted, the entire block group of data is lost, so they all have multiple copies. Normally the kernel only uses copies of the NO. 0 block group, and when performing e2fsck checks for file system consistency, the Super block and block group descriptor in the NO. 0 block group are copied to other block groups, so that when the beginning of the NO. 0 block group is accidentally damaged, other copies can be used to recover, thereby reducing the loss.

Block Bitmap block Bitmap the blocks in a block group are leveraged: data blocks store data for all files, such as a partition with a block size of 1024 bytes and a file of 2049 bytes, which requires three blocks of data to be stored, even if the third block has only one byte to occupy a whole block ; Super block, Block Group Descriptor table, block bitmap, inode bitmap, inode tables These sections store the description information for this block group. So how do you know which blocks have been used to store file data or other descriptive information, and which blocks are still available for free? Block bitmaps are used to describe which blocks in the entire block group have been used for free, and it itself occupies a block, where each bit represents a block in the block, and this bit is 1 to indicate that the block is used, and that bit is 0 to indicate that the block is free.

Note 1:

Why is it very fast to use the DF command to count the entire disk's used space? Because you only need to look at the block bitmap for each block group, you don't need to search through the entire partition. Conversely, using the du command to view the used space for a larger directory is very slow because it is unavoidable to search through all the files in the entire directory.

NOTE 2:

Another question associated with this is: how many block groups will be drawn when a partition is formatted? The main limitation is that the block bitmap itself must occupy only one block. When formatted with MKE2FS, the default block size is 1024 bytes, you can specify the block size with the-b parameter, and now the block size is specified as B byte, then a block can have 8b bit, so that a block bitmap of size can represent the consumption of 8b blocks, so a block group can have up to 8b blocks, If the entire partition has s blocks, then you can have s/(8b) block groups. You can use the-G parameter to specify how many blocks are in a block group, but usually do not need to be specified manually, the MKE2FS tool calculates the optimal value.

The Inode bitmap (inode Bitmap) is similar to a block bitmap, which itself occupies a block, where each bit indicates whether a inode** is free * *.

Inode tables (inode table) We know that a file, in addition to the data needs to be stored, some descriptive information needs to be stored, such as file type (general, directory, symbolic link, etc.), permissions, file size, creation/modification/access time, etc., that is, the ls-l command to see the information, This information exists in the inode rather than in the data block. Each file has an inode, and all the Inode in a block group makes up the Inode table.

Note 3:inode the number of blocks in a table is determined and written to the block group descriptor when it is formatted, the default policy for the MKE2FS formatting tool is how many inode is allocated for a block group with a number of 8KB. Since the data block occupies the vast majority of the block group, it is also possible to approximate how many 8KB of data blocks are allocated, in other words, if the average size of each file is 8KB, the Inode table will be fully utilized when the partition is full, and the data block is not wasted. If the partition is very large files (such as movies), then the data block when the inode will be a waste of time, if the partition is a small file (such as source code), then it is possible that the data block is not used to complete the inode has been exhausted, the data block may be a lot of waste. If the user is able to make a prediction about the size of the file to be stored after the partition is formatted, you can also manually specify each number of bytes by assigning an inode with the-i parameter of MKE2FS.

The data block is based on different file types in the following scenarios:

1) for regular files, the data for the file is stored in the data block.

2) for the directory, all filenames and directory names in this 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 in addition to the file name is stored in the inode of the file. Note This concept: A directory is also a file, a special type of file.

3) for symbolic links, if the target pathname is shorter, it is saved directly in the inode for faster lookups, and if the target pathname is longer, a block of data is allocated for saving.

4) There are no data blocks for special files such as device files, FIFO and sockets, and the main device number and secondary device number of the device file are saved in the inode.

As you can see, index entry blocks[13] points to a level two indirection block, which can represent up to (B/4) 2+b/4+12 blocks of data, and the maximum block size for 1K can represent 64.26MB of files. Index entry blocks[14] refers to a level three indirect addressing block, which can represent a maximum of (B/4) B/4 2+b/4+12 blocks of data, with a maximum block size of 1K to represent 16.06GB of files.
It can be seen that this approach is very fast for accessing small files with no more than 12 blocks of data, and accessing any data in a file requires only two read operations, one reading of the inode (that is, reading the index entry), one read block at a time. Accessing data in large files requires up to five read operations: Inode, Level indirection block, level two indirection block, level three indirection block, data block. In fact, the inode and data blocks in the disk are often already cached by the kernel, and the efficiency of reading large files is not too low.

For touch file

Gdt->inode Bitmap->inode Join table

Write file

Gdt->block Bitmap->data Block

Extra for inode fast is distributed uniformly by the system, so the inode between multiple block groups is not the same

If we use a lot of inode but we run out of data block, we can use the data block from the other block group. That's the reason we all look like a whole.

Linux file System (EXT2)