Linux | Red Hat Certification | IT Technology | Operations Engineer
👇1000 people technical exchange QQ group, note [public account] for faster access
Components of a Group
The following are the components of each group, but not every group has a super block, which will be discussed later.
inode table
The inode table is a table used in Linux file systems (such as Ext2, Ext3, Ext4) to store inodes. Each inode is a metadata storage unit for a file or directory, which does not directly store file content but contains file attributes and pointers to data blocks.
Assuming the above table is the inode table, with a data block size of 4KB and an inode size of 128 bytes, one data block can store 32 inodes. So how are inodes allocated? We can see that there is another data structure in the group called the inode bitmap.
inode bitmap
The inode bitmap is a data structure used in the file system to manage the allocation status of inodes. In Linux file systems (such as Ext2, Ext3, Ext4), the inode bitmap is part of the block group metadata, used to track the usage of inodes within a block group.
The inode bitmap is specifically used to index the positions of the inode table. When allocating inode positions, we first check the inode bitmap for a bit that is 0. If this position is 0, it indicates that the corresponding position in the inode table is unused. Thus, we find a position that is 0, set it to 1, then locate the inode in the inode table corresponding to the inode bitmap, and allocate 128 bytes for the inode, filling in its attributes.
data blocks
Data blocks are the basic units of storage for file content in the file system. They are used to store the actual data parts of files, including text, images, videos, etc.
Data blocks are specifically used to store data within files.
Data blocks are stored as data blocks, so how are data blocks allocated? In a group, there is also a bitmap that manages the usage of data blocks (block bitmap).
block bitmap
The block bitmap is another bitmap data structure used in the file system to manage disk space. It records the usage status of data blocks in the file system and helps the operating system efficiently allocate and release disk space.
The operation of the block bitmap is similar to that of the inode bitmap. When space needs to be allocated, based on the attributes in the inode, a suitable position is found in the block bitmap, which is then set to 1. This block bitmap number is returned to the data blocks, where data is written to the data block at the corresponding position. Finally, this number is returned to the inode table, and the block bitmap number is written as an attribute in the inode.
group descriptor table
The group descriptor table is a structure in file systems (especially in file systems like Ext4) that stores important metadata about block groups. Each block group contains a portion of data blocks, inodes, data block bitmaps, inode bitmaps, etc. The group descriptor table records the specific locations of these block groups and other necessary management information.
The group descriptor table is used to record the usage status of the inode table and data blocks, among other functions.
If we create a file, then there should be a corresponding inode. This inode needs to be allocated a position in the inode table. After a series of processes, if it is successfully allocated, the count in the group descriptor table needs to be incremented. If the file has content, the record for data blocks also needs to be incremented. If we delete a file, the corresponding counts need to be decremented.
Now, the steps to create a file are no longer just about directly searching for a position of 0 in the inode bitmap. Now we first check the usage of the inode bitmap in the group descriptor table. If there are remaining inodes in the inode bitmap, an inode is created for it. Next, we find a position of 0 in the inode bitmap, change the corresponding bit to 1, and save the inode in the inode table. The same process applies to the data blocks.
super block
The super block is a critical data structure that contains metadata about the file system. It stores essential information and management data, ensuring the effective operation of the file system.
The super block, also known as the superblock, is primarily used to record the overall status and basic information of the file system. Not every group has a super block, and there is not just one super block.
**Why is there more than one super block?**
In the file system, there is more than one super block, mainly to increase the fault tolerance and reliability of the file system. Generally, the file system will save copies of the super block in different locations to prevent the file system from becoming inaccessible due to disk damage or other hardware failures.
If we store the super block in a separate area at the front, then if this partition crashes, the entire file system will crash. However, if we store the super block in different groups at arbitrary positions, each saved super block is the same, being a copy of the same. If one group crashes, we only need to copy another super block for recovery.
After understanding the partitioning of each group, let’s talk about the details.
File System
About inodes and blocks
Inodes are unitized by partition, and a partition can have a set of inodes. When allocating inodes, we only need to determine the starting inode of each group. For block numbers, we only need to record the starting position number of each group, which is generally recorded in the GDT. When we look for a file, we only need to obtain the given inode and then look up which group this inode belongs to in the GDT. After finding out which group it belongs to, we just need to search for the inode in that group (Note: The inode we obtain is processed; to get the real inode, we need to subtract the current group’s start_inode from the inode we obtained). Based on the inode number, we can find the inode, which also has the block number, allowing us to locate the corresponding data blocks.
Question: How are inodes allocated?
Assuming the inode bitmap is 0000 0000 (hypothetically), and the allocated position is 0000 0100, then the allocated position is the third position. For the inode bitmap, this position is 3, but for the inode table, it is recorded as 4 because the start_inode is 1. Thus, adding the starting inode position results in 4. If it is in the second group, then the third position would be recorded as 10003 in the inode table.
Inode numbers and block numbers are globally established.
How are inodes and blocks mapped?
Each inode has 15 pointers mapped to blocks, but is 15 enough?
The answer: Yes, there are twelve direct mappings and three indirect mappings.
12 Direct Mappings
Each pointer directly points to the block where the file data is located. The downside is that it is only suitable for small files, but the indexing speed is very fast.
Single Indirect Index
The inode stores a pointer that points to this index block, which can point to more data block addresses.
One data block is 4KB, one address is 4 bytes, 1KB is 1024 bytes, so there are 4096 bytes in total. Thus, it can index 1024 data blocks, and since each data block is 4KB, it can index up to 4MB of content.
Double Indirect Index
The inode stores a pointer that points to an index block, and each pointer in this index block points to another index block, while these double index blocks point to data.
Using the algorithm for single indirect indexing, we can calculate how much data can be indexed: 4GB.
Triple Indirect Index
The inode stores a pointer that points to the single index block, which points to the double index block, the double index block points to the triple index block, and the triple index block ultimately points to the data.
The amount of data that can be indexed by the triple index is: 16TB (theoretically).
Why is it that the file is accessed by the inode, but we operate by the file name?
In the Linux system, everything is a file, so directories are also files.
Directory = inode + data block = attributes + content, so directories also need corresponding data blocks. What is stored in the data block of the directory?
Linux’s directory stores the mapping relationship between file names and inodes. Since there cannot be files with the same name in the same directory level, the indexing is 1:1 and unique.
Why does Linux do this?
Conclusion
The structural design of file systems aims to efficiently manage data storage and access. Key components such as the inode table, inode bitmap, data blocks, and block bitmap work together to track file data and ensure quick access. The group descriptor table and super block provide metadata for the organization of the file system.
Inodes play an important role in mapping files to physical data blocks, extending the file system’s management capabilities for large files through 12 direct pointers, single, double, and triple indirect pointers. Accessing files through inodes, rather than file names, separates file metadata from actual content, allowing for efficient data retrieval even when file names or locations change. This separation design makes the file system more flexible and efficient, ensuring stability and scalability in file access and management.
For course inquiries, add: HCIE666CCIE
↓ Or scan the QR code below ↓
What technical points and content do you want to see?
You can leave a message below to let Xiaomeng know!