File system notes

　　 I have been dealing with the whole system for a long time bring up,  To the system disk   Data disk mount   Partition , uboot  Boot kernel 、 Mount the root file system debug. At present, record the file system knowledge learned .

The file system is designed with the following features

• Take a tree structure 、 Folder design
• Cache hotspot files , Easy to read and write
• Using index structure , Easy to find classification
• Maintain a set of data structures to record which documents are being used by which tasks

So take a look at Linux Design of file system

　　 In the hard disk drive, we use blocks as storage units , And in the file system , We need to have a basic structure for storing block information , This is the cornerstone of the file system ​​inode​​​, The source code is as follows .​​inode​​​ Meaning for ​​index node​​, That is, the inode

Log in and copy

      
      

       
       /*
       
       
 * Structure of an inode on the disk
       
       
 */
       
       
struct ext4_inode {
       
       
    __le16    i_mode;        /* File mode Read and write permissions for files  */
       
       
    __le16    i_uid;        /* Low 16 bits of Owner Uid  To which user   */
       
       
    __le32    i_size_lo;    /* Size in bytes  What's the size */
       
       
    __le32    i_atime;    /* Access time  The last time the file was accessed */
       
       
    __le32    i_ctime;    /* Inode Change time  Last change  inode  Time for */
       
       
    __le32    i_mtime;    /* Modification time The last time the file was changed  */
       
       
    __le32    i_dtime;    /* Deletion Time */
       
       
    __le16    i_gid;        /* Low 16 bits of Group Id  Which group do you belong to  */
       
       
    __le16    i_links_count;    /* Links count */
       
       
    __le32    i_blocks_lo;    /* Blocks count  How many blocks does it take */
       
       
    __le32    i_flags;    /* File flags */
       
       
    union {
       
       
        struct {
       
       
            __le32  l_i_version;
       
       
        } linux1;
       
       
        struct {
       
       
            __u32  h_i_translator;
       
       
        } hurd1;
       
       
        struct {
       
       
            __u32  m_i_reserved1;
       
       
        } masix1;
       
       
    } osd1;                /* OS dependent 1 */
       
       
    __le32    i_block[EXT4_N_BLOCKS];/*  This member variable actually stores each block of the file contents Pointers to blocks */
       
       
    __le32    i_generation;    /* File version (for NFS) */
       
       
    __le32    i_file_acl_lo;    /* File ACL */
       
       
    __le32    i_size_high;
       
       
    __le32    i_obso_faddr;    /* Obsoleted fragment address */
       
       
    union {
       
       
        struct {
       
       
            __le16    l_i_blocks_high; /* were l_i_reserved1 */
       
       
            __le16    l_i_file_acl_high;
       
       
            __le16    l_i_uid_high;    /* these 2 fields */
       
       
            __le16    l_i_gid_high;    /* were reserved2[0] */
       
       
            __le16    l_i_checksum_lo;/* crc32c(uuid+inum+inode) LE */
       
       
            __le16    l_i_reserved;
       
       
        } linux2;
       
       
        struct {
       
       
            __le16    h_i_reserved1;    /* Obsoleted fragment number/size which are removed in ext4 */
       
       
            __u16    h_i_mode_high;
       
       
            __u16    h_i_uid_high;
       
       
            __u16    h_i_gid_high;
       
       
            __u32    h_i_author;
       
       
        } hurd2;
       
       
        struct {
       
       
            __le16    h_i_reserved1;    /* Obsoleted fragment number/size which are removed in ext4 */
       
       
            __le16    m_i_file_acl_high;
       
       
            __u32    m_i_reserved2[2];
       
       
        } masix2;
       
       
    } osd2;                /* OS dependent 2 */
       
       
    __le16    i_extra_isize;
       
       
    __le16    i_checksum_hi;    /* crc32c(uuid+inum+inode) BE */
       
       
    __le32  i_ctime_extra;  /* extra Change time      (nsec << 2 | epoch) */
       
       
    __le32  i_mtime_extra;  /* extra Modification time(nsec << 2 | epoch) */
       
       
    __le32  i_atime_extra;  /* extra Access time      (nsec << 2 | epoch) */
       
       
    __le32  i_crtime;       /* File Creation time */
       
       
    __le32  i_crtime_extra; /* extra FileCreationtime (nsec << 2 | epoch) */
       
       
    __le32  i_version_hi;    /* high 32 bits for 64-bit version */
       
       
    __le32    i_projid;    /* Project ID */
       
       
};
      
      
      
      

       
       
1.
       
       
2.
       
       
3.
       
       
4.
       
       
5.
       
       
6.
       
       
7.
       
       
8.
       
       
9.
       
       
10.
       
       
11.
       
       
12.
       
       
13.
       
       
14.
       
       
15.
       
       
16.
       
       
17.
       
       
18.
       
       
19.
       
       
20.
       
       
21.
       
       
22.
       
       
23.
       
       
24.
       
       
25.
       
       
26.
       
       
27.
       
       
28.
       
       
29.
       
       
30.
       
       
31.
       
       
32.
       
       
33.
       
       
34.
       
       
35.
       
       
36.
       
       
37.
       
       
38.
       
       
39.
       
       
40.
       
       
41.
       
       
42.
       
       
43.
       
       
44.
       
       
45.
       
       
46.
       
       
47.
       
       
48.
       
       
49.
       
       
50.
       
       
51.
       
       
52.
       
       
53.
       
       
54.
       
       
55.
       
       
56.
       
       
57.
       
       
58.
       
       
59.
       
       
60.
       
       
61.
       
       
62.
       
       
63.
      
      

 ext4_inode  The structure of the i_block  Each block of the file contents is actually stored , stay ext2 and ext3 Format file system , Before we use it 12 Blocks store the corresponding file data , Each piece 4KB, If the file is too large to fit , You need to use the following indirect storage blocks to save data , The following figure vividly shows the storage principle

　　 The problem with this storage structure is that for large files , We need multiple calls to access the contents of the corresponding block , So access is slow . So ,ext4 Put forward a new solution ：​ ​Extents​​. To put it simply ,Extents A tree structure is used to store file blocks consecutively , To improve access speed , The general structure is shown in the figure below .

 

 

The main structure is the node ​​ext4_extent_header​​​,​​eh_entries​​  Indicates how many items are in this node . There are two kinds of items here ：

• If it's a leaf node , This entry points directly to the address of the contiguous blocks on the hard disk , We call it data nodes ​​ext4_extent​​;
• If it's a branch node , This item points to the branch node or leaf node at the next level , We call it the inode ​​ext4_extent_idx​​​. The size of both types of items is 12 individual ​​byte​​

　　 If the file is not big ,​​inode​​​  Inside  ​​i_block​​​  in , It can hold the next one  ​​ext4_extent_header​​​  and 4 term  ​​ext4_extent​​​. So at this point ,​​eh_depth​​​  by 0, That is to say  ​​inode​​​  Inside is the leaf node , The height of the tree is 0. If the file is large ,4 individual  ​​extent​​​  can't let go , It's about to split into a tree ,​​eh_depth>0​​​  The node of is the index node , The root node has the largest depth , stay  ​​inode​​​  in . At the bottom  ​​eh_depth=0​​​  It's the leaf node . Except for the root node , The other nodes are stored in a block 4k Inside ,4k deduction  ​​ext4_extent_header​​​  Of 12 individual  ​​byte​​​, The rest can put 340 term , Every  ​​extent​​​  Maximum energy means 128MB The data of ,340 individual  ​​extent​​  Will make the file you represent reach 42.5GB. This is already very big , If it's bigger , We can increase the depth of the tree .

　　 therefore , We can go through ​​inode​​​ To represent a series of blocks , Thus forming a file . On the hard disk , Through a series of ​​inode​​​, We can store a lot of files . But we still need a way to store and manage ​​inode​​, This is the bitmap . alike , We will use block bitmap to manage block information

​​inode​​ And blocks are the smallest components of a file system , On top of that, there are multi-level systems , There are roughly the following ：

• Block group ： A constituent unit that stores a piece of data , The data structure is ​​ext4_group_desc​​​. This is for a block group of ​​inode​​​  Bitmap ​​bg_inode_bitmap_lo​​​、 Block bitmap ​​bg_block_bitmap_lo​​​、​​inode​​​  list ​​bg_inode_table_lo​​ There are corresponding definitions . Block by block , It basically constitutes the structure of our entire file system .block The size of can be different . Typical block Size is 1024 bytes perhaps 4096 bytes. This size is creating ext2、ext3 File system time is determined ,mkfs –t ext2/3 –b xx You can set the block size ！ On a hard disk partition block The count is from 0 At the beginning , in general ,block This concept is easy to understand .
• Block group descriptor table ： A table composed of descriptors of multiple block groups
• All on the hard disk partition block Be gathered together and divided into several large block group. Each of them block group How many of them block Is constant . You can see from the picture below ！ Every block group All correspond to one group descriptor, Every group descriptor There are several important block The pointer , Point to block group Medium inode table、block bitmap and inode bitmap.
• Superblock ： Describe the whole file system , namely ​​ext4_super_block​​​, Store global information , For example, how many files are there in the entire file system ​​inode​​​：​​s_inodes_count​​​; How many pieces are there ：​​s_blocks_count_lo​​​, How many... Per block group ​​inode​​​：​​s_inodes_per_group​​​, How many pieces per block group ：​​s_blocks_per_group​​  etc. .
• Guide block ： For the entire file system , We need to reserve an area as the boot area for the startup of the operating system , So the first block group should be preceded by 1K, Used to start the boot zone .

 

 

 

 　　Super block Super block , It is the beginning of the hard disk partition —— from  byte 1024 Start the next part of the data . because  block size The minimum is  1024 bytes, therefore super block May be in block 1 in （ here block  The size of is just  1024 bytes）; That is, the superblock is located in the 1 Within logical blocks , Because the first block group reserves 1KB As the system boot , Therefore, the position of the super block in the block group is 1KB Offset , The superblocks in other backup block groups are offset by the block group 0 The place of . The superblock will occupy 1 Space of logical blocks （ The actual occupied space should be less than this value ）, That is, the block group descriptor （ext2_group_desc） Is in 4KB The offset
The data in the super block is actually the control information part of the file volume , It can also be said to be a volume resource table , Most of the information about file volumes is saved here . for example ： Each in the hard disk partition block Size 、 How many are there on the hard disk partition block group、 And each block group How many of them inode.

 

 

Both superblock and block group descriptor tables are global information , And these data are important . If the data is lost , The entire file system can't be opened , This is more serious than a block of a file . therefore , We need to back up both parts , But take a different strategy .

• The default policy ： A copy of the superblock and block group description table is saved in each block
• sparse_super Strategy ： Adopt sparse storage , Only if the block group index is 0、3、5、7 Stored in the integer power of .
• Meta Block Groups Strategy ： We divide block components into multiple metablock groups （Meta Block Groups), The block group descriptor table in each meta block group only contains its own content , A chunk group contains 64 Block groups , Such a metablock group has the largest number of block group descriptors 64 term . This is similar to ​​merkle tree​​, Space can be optimized to a large extent .
• 
  

 

 　　 To facilitate the search of documents , We must have an index , File directory . In fact, the directory itself is a file , Also have  ​​inode​​​.​​inode​​​  It also points to some blocks . Different from ordinary documents , The file data is stored in the block of ordinary file , The block of the directory file stores the file information of each item in the directory . This information we call  ​​ext4_dir_entry​​​. There are two versions , Second version  ​​ext4_dir_entry_2​​​  Is the one 16 Bit  ​​name_len​​​, Become a 8 Bit  ​​name_len​​​  and 8 Bit  ​​file_type​​.

　　 In the block of the catalog file , The simplest format to save is a list , One by one  ​​ext4_dir_entry_2​​​  Where is the column . Each item will save the file name of the next level file in this directory and the corresponding file name  ​​inode​​​, Through this  ​​inode​​​, You can find the real file . The first is “.”, Represents the current directory , The second is “…”, Represents the directory above , Next are the file names and  ​​inode​​. occasionally , If there are too many files in a directory , We want to find a file in this directory , It's too slow to find one by one according to the list , So we added the index schema

　　 If we want to find the file name under a directory , You can hash by name . If the hash matches , It means that the information of this file is in the corresponding block . And then open this block , If it's no longer an index , It's the leaf node of the index tree , There is still  ​​ext4_dir_entry_2​​  A list of , We just need to find the file names one by one . Through the index tree , We can put a directory under N Many files are scattered into many blocks , It's quick to find .

 

 

Storage format of soft link and hard link

　　 Hard links share one with the original file  ​​inode​​​ , however  ​​inode​​​  Is not cross file system , Each file system has its own  ​​inode​​​  list , Therefore, there is no way for hard links to cross file systems . Soft links are different , Soft links are equivalent to re creating a file . This file also has a separate  ​​inode​​, It's just that when you open this file to see the contents , The content points to another file . This is very flexible . We can cross file systems , Even if the target file is deleted, the linked file still exists , It's just that the pointing file can't be found .

  Reprint ​ ​ come from ​​

 

http proxy server （3-4-7 Layer of the agent ）- Network event library common component 、 kernel kernel drive Camera drive tcpip Network protocol stack 、netfilter、bridge Seems to have seen ！！！！ But he that doeth good Don't ask future -- Height and weight 180 Fat man