【Linux系统】Ext系列磁盘文件系统二：引入文件系统（续篇）

inode 和 block 的映射

该博文中有详细解释：【Linux系统】inode 和 block 的映射原理

目录与文件名

这里有几个问题：

问题一： 我们访问文件，都是用的文件名，没用过 inode 号啊？

之前总是说可以通过一个文件的 inode 号就可以获取该磁盘文件的相关信息

但是，我们凭什么可以获得 inode ？

我们用户操作好像不是通过 inode 操作的，而是通过文件名操作的！

问题二：文件名存储在哪里呢？

之前说过，在 Linux下， 文件名不在 inode 结构中保存？为什么？

那 文件名存储在哪里呢？存储在目录文件！

问题三：目录是文件吗？如何理解？

目录文件

目录其实也是文件：目录文件

命令 ls -lid 目录文件名 ：查看该目录文件属性信息，如该文件的 inode 号

不卖关子：目录文件的内容存储的是文件名和 inode 的映射关系

目录既然是文件，当然也就可以打开！！！！！

举例：在终端上打开一个目录文件

（1）命令 for i in {1..5}; do touch "test$i.c"; done ：在当前目录创建 5 个 test1.c 、test2.c 这样命名的文件

（2）命令 vim . ：查看当前目录文件

既然 目录也是文件，目录文件也要有对应的数据块的！

目录 = inode + data block = 属性 + 内容

文件名和 inode 是互为映射的

因为在 Linux 或 Windows 等操作系统中的文件目录下都不能存在同名文件

如何保证文件的命名唯一性呢，可以依靠 文件名 和 inode 的映射关系，inode 绝对是唯一的，相应的文件名也为唯一的。

• 用户输入文件名，同时一般需要带上路径，系统就会在该路径下，寻找对应文件名，通过 文件名和 inode 的映射，找到该文件的唯一inode值进行文件磁盘访问的相关操作
• 文件名单向映射唯一一个 inode 值，而 inode 值可以被多个文件名映射，这种机制是通过硬链接实现的！

为什么一个目录能有 读/写/执行 rwx 权限

到这里，你应该可以明白，为什么一个目录还能有 读、写、执行 权限

若一个目录没有读权限，你就不能访问该目录下的文件：就是因为目录文件本身内部存储着文件名和inode的映射关系，必须要读目录，才能拿到该映射关系，才能拿到 inode 才能访问该文件

若一个目录没有写权限，就无法在该目录下创建文件、删除文件、修改文件名…：就是因为目录文件本身用于存储文件名和inode的映射关系，必须要有写权限，才能将文件名和inode的映射关系写入该目录文件中，而 创建文件本质就是将新文件和inode的映射关系写入、删除文件本质就是删除文件和inode的映射关系、修改文件名本质就是修改了新文件名和inode的映射关系

若一个目录没有执行权限，就无法进入该目录：进不去该目录的本质是打不开该目录文件

问题：普通文件和目录文件在底层有区别吗？

在我们前面讲解的 磁盘文件系统中，是否会区分该文件是普通文件、还是目录文件吗？

不会，在底层一视同仁！

在底层的 磁盘文件系统中，文件的属性存储在 inode 中，文件的内容存储在 Block 中，普通文件和目录文件本质都是 属性 + 内容，因此不会区分文件类型，而是按部就班的直接存储属性和内容这样的数据

---

问题：为什么要进行文件名和 inode 的映射？

那为什么要设计 inode 和文件名进行映射呢，为什么要套这一层呢？

效率问题：若我们使用文件名表示一个文件，系统寻找文件时，则需要比对众多的文件名（字符串！），时间复杂度是 O(n) ！

而文件名映射的 inode ，则只需比较 数值类型的 inode 数字串，时间复杂度是 O(1) ！

其实系统管理用户也是通过：用户名和 User 编号的映射关系

命令 ls -l 可以看到文件的创建者

命令 ls -ln ：带上一个 n ，表示能显示数字就显示数字

此时就能看到用户名在系统看来就是一串数字！

不只是这几个例子：还是什么 GID ：组别ID…

系统会主动规避字符串，而是使用映射的数字，字符串是给人看的，数字对系统来说才是高效的！

重新理解 ls -l 命令

该命令本质上是打开当前目录的目录文件，遍历所有文件和 inode 的映射关系，通过 inode 值找到磁盘中该文件的 inode 结构体，返回该结构体中存储的文件属性信息，将这些文件信息和文件名拼接处理成字符串展示到屏幕上，下图中文件名前面的都是该文件存储在 struct inode 中的文件信息！

可是问题又来了！

找到文件名 -> 首先要打开当前目录 -> 当前目录，也是文件！！也有文件名的呀！！

那目录的文件名如何被找到呢？

目录的目录的文件名又如何被找到呢？套娃呢

此时就需要 逆向的路径解析！

逆向路径解析

我如果需要访问 /lesson21 目录文件内容（如访问 test.txt 文件），就需要拿到目录文件 lesson21 的 inode 找到磁盘中的相关的数据块，此时就要目录文件 /code 提供/lesson21 目录文件的 inode值

我如果需要访问目录文件 /code ，就需要拿到目录文件 /code 的 inode 找到磁盘中的相关的数据块，此时就要目录文件 /112 提供/code 目录文件的 inode值

一环一环，本级目录文件的内容访问，需要拿到 inode值，只能通过上级目录文件拿到该inode值

最终逆向回到根目录，而根目录是写死的，根目录文件的 inode值可以直接被获取然后访问对应数据块，相当于递归到出口了！！

正解：其实路径是被正向解析的，逆向只是为了方便理解路径需要被解析的！

系统其实是获取一个全路径，从根目录开始一次从左向右，依次解析路径的！！！

问题：为什么任何一个文件都要有路径？

就是要一环套一环的嵌套存储数据！！！！

没有路径，就根本不能直接找到该文件，只有通过一个全路径，对全路径进行一次解析解环，最终才能找到目标！

问题：为什么每个进程都要有一个 CWD ？？

每个进程都有一个当前工作目录（CWD, Current Working Directory）主要是为了方便文件路径的引用。当你在命令行中运行程序或脚本时，很多时候需要访问或操作文件系统中的文件。这些文件可能位于不同的目录中，而使用相对路径来引用它们可以极大地简化这一过程。

当你启动一个新的进程时，它会继承其父进程的当前工作目录，除非特别指定了另一个工作目录。例如，当你从Bash启动一个程序时，这个程序默认的当前工作目录就是启动它的那个Bash进程的当前工作目录。这就是为什么即使是像Bash这样的祖先进程也需要维护一个CWD——它不仅用于自身的操作，也为所有由它启动的子进程提供了一个起点。

当前工作目录 CWD 最主要作用是用于形成相对路径

如下图，一个点 的意思是当前目录，两个点 的意思是上级目录

若你在当前目录下，打开当前目录的一个 log.txt 文件，只需要用当前目录的一个点 + 文件名的形式组成的路径，这就是相对路径！

open("./log.txt");

在该程序底层，表示当前目录的这个点，就会用 CWD 替换掉，如下：

// 假如 cwd 为 /root/code/"./log.txt"等于
"/root/code/log.txt" 

问题：路径需要被重复解析吗？

前面我们讲解了一个文件需要被系统做层层的路径解析，这个过程其实是不断的在访问磁盘，和磁盘进行IO交互的

/home/whb/code/code/112/code/1esson21

我们通过路径解析找到文件 lesson21，那如果我们还要查找访问当前路径下的 test1.c，难道我们还需要将该路径再次重复的解析一遍吗？？

/home/whb/code/code/112/code/test1.c

并不需要，Linux系统会对路径进行缓存，解释如下：

路径缓存和缓存树 struct dentry 结构

路径缓存

在磁盘文件系统中是没有文件路径的概念的，如果有也是逻辑上的存在（路径本就是从物理层面抽象出来的一种逻辑化的概念）

磁盘中仅仅存在纯粹的 inode 和数据块，就是纯粹的存储文件及其数据内容

而我们操作系统中又是如何通过例如一个 tree 命令将整个系统的路径关系展示出来的呢？

是不是系统遍历了所有文件路径，然后不断和磁盘交互得来的，肯定不是，这样太慢了

其实，Linux系统会对路径进行缓存！，而且就是通过 多叉树这样的结构进行缓存的！！

缓存路径的多叉树并不会一次性将磁盘中的所有文件路径缓存下来，这个树展示的只是磁盘文件系统中的一小部分文件路径

除了一些基本文件和访问几率较大的文件会先被缓存下来，还有就是会缓存我们历史访问过的文件路径

如果下次还需使用到该路径，就直接查找文件路径缓存树即可

我们使用 find 命令查询文件时

比如在根目录下，按照名字查询目标文件：find / -name test.txt

find 命令查询文件也是要不断访问磁盘对应文件数据块内容

而我们说过，首次进行 find 命令查询时可能会比较慢，第二次之后就相对比较快了

这就是因为首次查询时，系统已经将访问过的文件路径缓存下来了，第二次之后的查询就不用过多的访问磁盘，只需查询路径树即可！！！

缓存树的 struct dentry 结构

Linux中，在内核中维护树状路径结构的内核结构体叫做： struct dentry

---

---

树的组成：一个 struct dentry 结构实际上算作一种树节点结构，多个 struct dentry 结构链接就形成所谓的 文件路径缓存树 ！

struct dentry 结构：含有三个主要的字段

• 父节点指针 ：指向父亲 struct dentry 节点结构
• 子节点指针 ：指向孩子 struct dentry 节点结构
• inode 值：本文件对应的 inode 值

每个文件都有dentry：每个文件其实都要有对应的 dentry 结构，包括普通文件。这样所有被打开的文件，就可以在内存中形成整个树形结构。

LRU 淘汰机制：整个树形节点也同时会隶属于 LRU(Least Recently Used)，最近最少使用)结构中，进行节点淘汰。

整个树形节点也同时会隶属于Hash，方便快速查找。

更重要的是，这个树形结构，整体构成了Linux的路径缓存结构，打开访问任何文件，都在先在这棵树下根据路径进行查找，找到就返回属性inode和内容，没找到就从磁盘加载路径，添加dentry结构，缓存新路径。

例如我们需要通过该路径访问该 test 文件：/home/test
系统会在系统内存中的文件路径缓存 dentry 树中，根据给出的路径，正向解析，解析过程如下：

1. 从根目录开始：
   • 从根目录 / 的 dentry 开始，根目录的 dentry 通常是内核中固定的。
   • 通过根目录的 dentry 获取根目录的 inode。
2. 查找 home 目录：
   • 在根目录的 inode 中查找文件名 home 的目录项。
   • 如果找到 home 的目录项，获取 home 的 inode 号。
   • 系统为文件 home 创建一个 struct dentry 结构，并链接到文件缓存多叉树中。
3. 查找 test 文件：
   • 在 home 目录的 inode 中查找文件名 test 的目录项。
   • 如果找到 test 的目录项，获取 test 的 inode 号。
   • 系统为文件 test 创建一个 struct dentry 结构，并链接到文件缓存多叉树中。

这个过程少不了访问磁盘，因此路径解析一次通常会将文件路径缓存到文件缓存多叉树上，便于下次路径查询利用。

进程层面

这块内容记住就好：

通过查询源码，进程 task_struct 、文件 struct file 和 文件dentry 之间的关系如下

进程 struct task_struct 中存在文件描述符表 struct files_struct *file，该表中存储着文件描述符和文件 struct file 的映射关系，而每个加载到内存中的文件都会有对于的 struct file 结构，这个结构体中包含着很多和文件在内存中操作相关的字段属性，如

• const struct file_operations *f_op 操作函数表、
• struct address_space 内核文件缓冲区、
• struct path *f_path 文件路径相关属性，指向一个path结构体
  • struct path 该path结构体中包含着 dentry 结构
    • dentry 结构：包含着不少的字段：

      • struct dentry *d_parent ：指向父节点

      • struct list_head d_child：指向子节点

      • struct inode *d_inode：指向文件属性结构 inode

图示如下：下面有多张图片，选自己能看懂的即可

---

---

---

题外话：其中，进程 task_struct 中 struct fs_struct *fs 指向的 struct fs_struct 结构中，存储着 pwd，这就是为什么每个进程都有自己的 pwd ！

这个 pwd 是一种 struct path 路径结构，内部也存储着一个 dentry，当我们获取当前的 pwd 时，就是通过查询 pwd 的 dentry 的所处路径！

再次梳理：

目录项结构就是 struct dentry ，存储在上级目录文件的 inode 结构指向的数据块中

本目录文件目录项结构 struct dentry 中存储着本目录文件的 inode 结构指针，通过该指针找到自己的 inode 结构，进一步访问自己数据块的内容，内容中存储着自己这个目录文件存储的所有下级文件的目录项：下级文件名和其 inode 号的映射关系

路径解析核心是依次读取目录文件的 dentry ，并通过读取该 dentry 的 inode 查找下一级目录或文件的目录项，并获取下级目录或文件的 inode 号。同时每次读取过的目录文件的 dentry 就会加载到内存中，并链接到文件缓存多叉树中，包括最终需要打开的文件，也是先要将该文件的 dentry 结构加载到内存中，然后才是通过dentry 结构访问 inode

完整流程

这是一次从路径解析到文件打开，再到文件读取的完整流程，目的是为了从具体的例子中梳理之前的学习内容，包括：文件打开需要的`struct file` 、路径解析、`inode` 结构等等综合知识点！

1. 路径解析

假设我们要访问路径 /home/test 并打开 test 文件，路径解析过程如下：

(1) 从根目录开始

• 从根目录 / 的 dentry 开始，根目录的 dentry 通常是内核中固定的。
• 通过根目录的 dentry 获取根目录的 inode。

(2) 查找 home 目录：

• 在根目录的 inode 中查找文件名 home 的目录项。
• 如果找到 home 的目录项，获取 home 的 inode 号。
• 为文件 home创建一个 struct dentry结构，并链接到文件缓存多叉树中。

(3) 查找 test 文件：

• 在 whb 目录的 inode 中查找文件名 test 的目录项。
• 如果找到 test 的目录项，获取 test 的 inode 号。
• 为文件 test创建一个 struct dentry结构，并链接到文件缓存多叉树中。
  
  
  

2. 文件打开

当文件 test 被打开时，内核会执行以下步骤：

(1) 获取 inode 结构：

• 通过 test 文件的 inode 号，从磁盘中读取 inode 结构并加载到内存中。
• inode 结构包含文件的元数据，如权限、所有者、大小、数据块指针等。

(2) 创建 struct file 结构：

• 内核为 test 文件创建一个 struct file 结构。
• struct file 结构包含文件描述符、文件操作指针、文件偏移量等信息。
• struct file 结构中的 inode 指针指向 test 文件的 inode 结构。
• struct file 结构中的 dentry 指针指向 test 文件的 dentry 结构。

到这一步，可以知道，其实文件的 struct dentry 结构，是在 struct file 结构之前创建的，当 struct file 结构创建后，内部的属性 dentry 指针才会指向本文件早已创建好的 dentry 结构！

(3) 返回文件描述符：

• 内核为 test 文件分配一个文件描述符，并将其返回给用户空间。
• 用户空间通过文件描述符来操作文件。
  
  
  

3. 文件读取

当用户调用 read 系统调用读取文件内容时，内核会执行以下步骤：

(1) 查找数据块：

• 通过 test 文件的 inode 结构中的数据块指针，找到文件内容所在的数据块。
• 数据块指针可能包括直接块指针、一级间接块指针、二级间接块指针等。

(2) 加载数据块到内存：

• 将数据块从磁盘读取到内存中，存放在内核的文件缓冲区中。

(3) 拷贝数据到用户缓冲区：

• 内核将文件缓冲区中的数据拷贝到用户提供的缓冲区中。
• 用户可以通过 read 系统调用获取文件内容。

分区挂载

分区挂载