Shulou(Shulou.com)06/01 Report--

How to implement a file system in Linux? I believe many inexperienced people don't know what to do about it. Therefore, this paper summarizes the causes and solutions of the problem. Through this article, I hope you can solve this problem.

Linux file management introduces the way Linux manages files from the user level. Linux has a tree structure to organize files. At the top of the tree is the root directory (/), the node is the directory, and the leaves at the end are files containing data. When we give the full path to a file, we start from the root directory, go through various directories along the way, and finally reach the file.

We can do a lot of operations on files, such as opening and reading and writing. In the commands related to Linux file management, we see many commands that operate on files. Most of them are based on the opening, reading and writing of files. For example, cat can open a file, read the data, and finally display it on the terminal:

$cat test.txt

For programmers under Linux, understanding the underlying organization of the file system is necessary for in-depth system programming. Even ordinary Linux users can design a better system maintenance scheme according to the relevant content.

Storage device partition

The ultimate goal of a file system is to put large amounts of data into persistent (persistant) storage devices, such as hard disks and disks. These storage devices are different from memory. Their storage capacity is persistent and will not disappear because of a power outage; the storage capacity is large, but the reading speed is slow.

Observe common storage devices. The initial area is MBR, which is used for Linux boot (see Linux boot). The remaining space may be divided into several partition. Each partition has an associated partition table (Partition table) that records information about the partition. This partition table is stored outside the partition. The partition table describes the starting position and size of the corresponding partition.

We often see C partition, D partition and so on in Windows system. There can also be multiple partitions on a Linux system, but all are mounted on the same file system tree.

The data is stored in a partition. A typical Linux partition (partition) contains the following sections:

The first part of the partition is the boot area (Boot block), which is mainly used to boot the computer. After Linux boots, MBR is loaded first, and then MBR loads the program from the startup area of a hard disk. The program is responsible for loading and starting the further operating system. For ease of administration, Linux reserves a boot area in a partition even if the operating system is not installed in that partition.

After the start-up area is the super area (Super block). It stores information about the file system, including the type of file system, the number of inode, and the number of data blocks.

This is followed by multiple inodes, which are the key to implementing file storage. In the Linux system, a file can be stored in several blocks, just like Dragonballs scattered in different places. In order to collect Qi Longzhu smoothly, we need a "radar" guide: the inode corresponding to this file. Each file corresponds to an inode. The inode contains pointers to individual blocks of data that belong to the file. When the operating system needs to read files, just need to correspond to the "map" of inode, collect scattered data blocks, and we can harvest our files.

The last part is the data blocks that actually stores the data.

Introduction to inode

Above we see the macro structure of the storage device. We need to delve into the structure of the partition, especially how files are stored in the partition.

The file is the division unit of the file system to the data. The file system uses directories to organize files and give them a hierarchical structure. The key to implementing this hierarchical structure on the hard disk is to use inode to virtualize normal file and directory file objects.

In Linux file management, we know that in addition to its own data, a file also has an ancillary information, that is, the file's metadata. This metadata is used to record a lot of information about the file, such as file size, owner, group, modification date, and so on. Metadata is not included in the data in the file, but is maintained by the operating system. In fact, this so-called metadata is included in inode. We can use $ls-l filename to view this metadata. As we saw above, the area occupied by inode is different from the area of the data block. Each inode has a unique integer number (inode number) representation.

In saving metadata, inode is the key to "files" from abstract to concrete. As mentioned in the previous section, inode storage consists of pointers to blocks of data in the storage device in which the contents of the file are stored. When Linux wants to open a file, all it needs to do is to find the inode corresponding to the file, and then collect all the data blocks along the pointer to form the data of a file in memory.

The data block is 1, 32, 0,.

Inode is not the only way to organize files. The easiest way to organize files is to put them in the storage device sequentially, and DVD takes a similar approach. However, if there is a delete operation, the free space caused by deletion is interspersed between normal files, which is difficult to use and manage.

In complex ways, you can use linked lists, where each block has a pointer to the next block that belongs to the same file. The advantage is that you can take advantage of the scattered free space, but the disadvantage is that the operation of the file must be done in a linear manner. If you want random access, you must traverse the linked list to the target location. Because this traversal is not carried out in memory, it is very slow.

The FAT system takes out the pointer of the above linked list and puts it into an array of memory. In this way, FAT can quickly find a file according to the index of memory. The main problem with this is that the size of the index array is the same as the total number of blocks. Therefore, if the storage device is large, the index array will be large.

Inode can make full use of the space, and the memory space is not related to the storage device, which solves the above problem. But inode has its own problems. The total number of block pointers that each inode can store is fixed. If a file needs more data blocks than this total, inode needs extra space to store the extra pointers.

Inode example

In Linux, we find a file according to the directory file along the way by parsing the path. The entries in the directory have corresponding inode numbers in addition to the file names they contain. When we type $cat / var/test.txt, Linux will find the inode number of the directory file var in the root file, and then synthesize the var data based on inode. Then, according to the records in var, find the inode number of text.txt, collect data blocks along the pointer in inode, and synthesize the data of text.txt. Throughout the process, we referred to three inode: root directory file, var directory file, and inodes of text.txt file.

Under Linux, you can use $stat filename to query the inode number of a file.

It is actually stored in the storage device as:

When we read a file, we actually find the inode number of the file in the directory, and then combine the data blocks according to the inode pointer and put them into memory for further processing. When we write to a file, we assign a blank inode to the file, write down its inode number in the directory to which the file belongs, and then select the blank data block, let the pointer of the inode point to the data like these blocks, and put the data in memory.

File sharing

In the Linux process, when we open a file, we return a file descriptor. This file descriptor is the subscript of an array and corresponds to the array element as a pointer. Interestingly, instead of pointing directly to the file's inode, this pointer points to a file table and, through that table, to the inode of the target file loaded into memory. As shown in the following figure, a process opens two files.

As you can see, each file table records the file open status (status flags), such as read-only, write, and so on, as well as the current read and write location (offset) of each file. When two processes open the same file, there can be two file tables, each with a different open state and current location, thus supporting some file sharing operations, such as reading at the same time.

Note that after the process fork, the child process will only copy the array of file descriptors and share the kernel-maintained file table and inode with the parent process. At this time, you should be very careful in writing the program.

After reading the above, have you mastered how to implement a file system in Linux? If you want to learn more skills or want to know more about it, you are welcome to follow the industry information channel, thank you for reading!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.