当前位置：首页 > news >正文

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

news 来源：原创 2025/6/17 7:16:52

在这里插入图片描述

`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 树中，根据给出的路径，正向解析，解析过程如下：
在这里插入图片描述

从根目录开始：
- 从根目录 / 的 dentry 开始，根目录的 dentry 通常是内核中固定的。
- 通过根目录的 dentry 获取根目录的 inode。
查找 home 目录：
- 在根目录的 inode 中查找文件名 home 的目录项。
- 如果找到 home 的目录项，获取 home 的 inode 号。
- 系统为文件 home 创建一个 struct dentry 结构，并链接到文件缓存多叉树中。
查找 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 系统调用获取文件内容。

inode 和 block 的映射

目录与文件名

目录文件

文件名和 inode 是互为映射的

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

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

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

重新理解 ls -l 命令

逆向路径解析

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

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

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

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

路径缓存

缓存树的 struct dentry 结构

进程层面

完整流程

1. 路径解析

2. 文件打开

3. 文件读取

分区挂载

相关文章：

`inode` 和 `block` 的映射

文件名和 `inode` 是互为映射的

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

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

重新理解 `ls -l` 命令

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

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

缓存树的 `struct dentry` 结构