从文件 I/O 看 Linux 的虚拟文件系统

1 引言

Linux 中允许众多不同的文件系统共存，如 ext2, ext3, vfat 等。通过使用同一套文件 I/O 系统 调用即可对 Linux 中的任意文件进行操作而无需考虑其所在的具体文件系统格式；更进一步，对文件的 操作可以跨文件系统而执行。如图 1 所示，我们可以使用 cp 命令从 vfat 文件系统格式的硬盘拷贝数据到 ext3 文件系统格式的硬盘；而这样的操作涉及到两个不同的文件系统。

图 1. 跨文件系统的文件操作

“一切皆是文件”是 Unix/Linux 的基本哲学之一。不仅普通的文件，目录、字符设备、块设备、 套接字等在 Unix/Linux 中都是以文件被对待；它们虽然类型不同，但是对其提供的却是同一套操作界面。

图 2. 一切皆是文件

而虚拟文件系统正是实现上述两点 Linux 特性的关键所在。虚拟文件系统（Virtual File System, 简称 VFS）， 是 Linux 内核中的一个软件层，用于给用户空间的程序提供文件系统接口；同时，它也提供了内核中的一个 抽象功能，允许不同的文件系统共存。系统中所有的文件系统不但依赖 VFS 共存，而且也依靠 VFS 协同工作。

为了能够支持各种实际文件系统，VFS 定义了所有文件系统都支持的基本的、概念上的接口和数据 结构；同时实际文件系统也提供 VFS 所期望的抽象接口和数据结构，将自身的诸如文件、目录等概念在形式 上与VFS的定义保持一致。换句话说，一个实际的文件系统想要被 Linux 支持，就必须提供一个符合VFS标准 的接口，才能与 VFS 协同工作。实际文件系统在统一的接口和数据结构下隐藏了具体的实现细节，所以在VFS 层和内核的其他部分看来，所有文件系统都是相同的。图3显示了VFS在内核中与实际的文件系统的协同关系。

图3. VFS在内核中与其他的内核模块的协同关系

我们已经知道，正是由于在内核中引入了VFS，跨文件系统的文件操作才能实现，“一切皆是文件” 的口号才能承诺。而为什么引入了VFS，就能实现这两个特性呢？在接下来，我们将以这样的一个思路来切入 文章的正题：我们将先简要介绍下用以描述VFS模型的一些数据结构，总结出这些数据结构相互间的关系；然后 选择两个具有代表性的文件I/O操作sys_open()和sys_read()来详细说明内核是如何借助VFS和具体的文件系统打 交道以实现跨文件系统的文件操作和承诺“一切皆是文件”的口号。

2 VFS数据结构

2.1 一些基本概念

从本质上讲，文件系统是特殊的数据分层存储结构，它包含文件、目录和相关的控制信息。为了描述 这个结构，Linux引入了一些基本概念:

文件 一组在逻辑上具有完整意义的信息项的系列。在Linux中，除了普通文件，其他诸如目录、设备、套接字等 也以文件被对待。总之，“一切皆文件”。

目录 目录好比一个文件夹，用来容纳相关文件。因为目录可以包含子目录，所以目录是可以层层嵌套，形成 文件路径。在Linux中，目录也是以一种特殊文件被对待的，所以用于文件的操作同样也可以用在目录上。

目录项 在一个文件路径中，路径中的每一部分都被称为目录项；如路径/home/source/helloworld.c中，目录 /, home, source和文件 helloworld.c都是一个目录项。

索引节点 用于存储文件的元数据的一个数据结构。文件的元数据，也就是文件的相关信息，和文件本身是两个不同 的概念。它包含的是诸如文件的大小、拥有者、创建时间、磁盘位置等和文件相关的信息。

超级块 用于存储文件系统的控制信息的数据结构。描述文件系统的状态、文件系统类型、大小、区块数、索引节 点数等，存放于磁盘的特定扇区中。

如上的几个概念在磁盘中的位置关系如图4所示。

图4. 磁盘与文件系统

关于文件系统的三个易混淆的概念：

创建 以某种方式格式化磁盘的过程就是在其之上建立一个文件系统的过程。创建文现系统时，会在磁盘的特定位置写入 关于该文件系统的控制信息。

注册 向内核报到，声明自己能被内核支持。一般在编译内核的时侯注册；也可以加载模块的方式手动注册。注册过程实 际上是将表示各实际文件系统的数据结构struct file_system_type 实例化。

安装 也就是我们熟悉的mount操作，将文件系统加入到Linux的根文件系统的目录树结构上；这样文件系统才能被访问。

2.2 VFS数据结构

VFS依靠四个主要的数据结构和一些辅助的数据结构来描述其结构信息，这些数据结构表现得就像是对象； 每个主要对象中都包含由操作函数表构成的操作对象，这些操作对象描述了内核针对这几个主要的对象可以进行的操作。

2.2.1 超级块对象

存储一个已安装的文件系统的控制信息，代表一个已安装的文件系统；每次一个实际的文件系统被安装时， 内核会从磁盘的特定位置读取一些控制信息来填充内存中的超级块对象。一个安装实例和一个超级块对象一一对应。 超级块通过其结构中的一个域s_type记录它所属的文件系统类型。

根据第三部分追踪源代码的需要，以下是对该超级块结构的部分相关成员域的描述，（如下同）：

清单1. 超级块

2.2.2 索引节点对象

索引节点对象存储了文件的相关信息，代表了存储设备上的一个实际的物理文件。当一个 文件首次被访问时，内核会在内存中组装相应的索引节点对象，以便向内核提供对一个文件进行操 作时所必需的全部信息；这些信息一部分存储在磁盘特定位置，另外一部分是在加载时动态填充的。

清单2. 索引节点

2.2.3 目录项对象

引入目录项的概念主要是出于方便查找文件的目的。一个路径的各个组成部分，不管是目录还是 普通的文件，都是一个目录项对象。如，在路径/home/source/test.c中，目录 /, home, source和文件 test.c都对应一个目录项对象。不同于前面的两个对象，目录项对象没有对应的磁盘数据结构，VFS在遍 历路径名的过程中现场将它们逐个地解析成目录项对象。

清单3. 目录项

2.2.4 文件对象

文件对象是已打开的文件在内存中的表示，主要用于建立进程和磁盘上的文件的对应关系。它由sys_open() 现场创建，由sys_close()销毁。文件对象和物理文件的关系有点像进程和程序的关系一样。当我们站在用户空间来看 待VFS，我们像是只需与文件对象打交道，而无须关心超级块，索引节点或目录项。因为多个进程可以同时打开和操作 同一个文件，所以同一个文件也可能存在多个对应的文件对象。文件对象仅仅在进程观点上代表已经打开的文件，它 反过来指向目录项对象（反过来指向索引节点）。一个文件对应的文件对象可能不是惟一的，但是其对应的索引节点和 目录项对象无疑是惟一的。

清单4. 文件对象

2.2.5 其他VFS对象

2.2.5.1 和文件系统相关

根据文件系统所在的物理介质和数据在物理介质上的组织方式来区分不同的文件系统类型的。 file_system_type结构用于描述具体的文件系统的类型信息。被Linux支持的文件系统，都有且仅有一 个file_system_type结构而不管它有零个或多个实例被安装到系统中。

而与此对应的是每当一个文件系统被实际安装，就有一个vfsmount结构体被创建，这个结构体对应一个安装点。

清单5. 和文件系统相关

2.2.5.2 和进程相关

清单6. 打开的文件集

2.2.5.3 和路径查找相关

清单7. 辅助查找

2.2.6 对象间的联系

如上的数据结构并不是孤立存在的。正是通过它们的有机联系，VFS才能正常工作。如下的几张图是对它们之间的联系的描述。

如图5所示，被Linux支持的文件系统，都有且仅有一个file_system_type结构而不管它有零个或多个实例被安装到系统 中。每安装一个文件系统，就对应有一个超级块和安装点。超级块通过它的一个域s_type指向其对应的具体的文件系统类型。具体的 文件系统通过file_system_type中的一个域fs_supers链接具有同一种文件类型的超级块。同一种文件系统类型的超级块通过域s_instances链 接。

图5. 超级块、安装点和具体的文件系统的关系

从图6可知：进程通过task_struct中的一个域files_struct files来了解它当前所打开的文件对象；而我们通常所说的文件 描述符其实是进程打开的文件对象数组的索引值。文件对象通过域f_dentry找到它对应的dentry对象，再由dentry对象的域d_inode找 到它对应的索引结点，这样就建立了文件对象与实际的物理文件的关联。最后，还有一点很重要的是, 文件对象所对应的文件操作函数 列表是通过索引结点的域i_fop得到的。图6对第三部分源码的理解起到很大的作用。

图6. 进程与超级块、文件、索引结点、目录项的关系

3 基于VFS的文件I/O

到目前为止，文章主要都是从理论上来讲述VFS的运行机制；接下来我们将深入源代码层中，通过阐述两个具有代表性的系统 调用sys_open()和sys_read()来更好地理解VFS向具体文件系统提供的接口机制。由于本文更关注的是文件操作的整个流程*，所以我 们在追踪源代码时，对一些细节性的处理不予关心。又由于篇幅所限，只列出相关代码。本文中的源代码来自于linux-2.6.17内核版本。

在深入sys_open()和sys_read()之前，我们先概览下调用sys_read()的上下文。图7描述了从用户空间的read()调用到数据从 磁盘读出的整个流程。当在用户应用程序调用文件I/O read()操作时，系统调用sys_read()被激发，sys_read()找到文件所在的具体文件 系统，把控制权传给该文件系统，最后由具体文件系统与物理介质交互，从介质中读出数据。

图7. 从物理介质读数据的过程

3.1 sys_open()

sys_open()系统调用打开或创建一个文件，成功返回该文件的文件描述符。图8是sys_open()实现代码中主要的函数调用关系图。

图8. sys_open函数调用关系图

由于sys_open()的代码量大，函数调用关系复杂，以下主要是对该函数做整体的解析；而对其中的一些关键点，则列出其关键代码。

a. 从sys_open()的函数调用关系图可以看到，sys_open()在做了一些简单的参数检验后，就把接力棒传给do_sys_open()：

1）、首先，get_unused_fd()得到一个可用的文件描述符；通过该函数，可知文件描述符实质是进程打开文件列表中对应某个文件对象的索引值；

2）、接着，do_filp_open()打开文件，返回一个file对象，代表由该进程打开的一个文件；进程通过这样的一个数据结构对物理文件进行读写操作。

3）、最后，fd_install()建立文件描述符与file对象的联系，以后进程对文件的读写都是通过操纵该文件描述符而进行。

b. do_filp_open()用于打开文件，返回一个file对象；而打开之前需要先找到该文件：

1）、open_namei()用于根据文件路径名查找文件，借助一个持有路径信息的数据结构nameidata而进行；

2）、查找结束后将填充有路径信息的nameidata返回给接下来的函数nameidata_to_filp()从而得到最终的file对象；当达到目的后，nameidata这个数据结构将会马上被释放。

c.open_namei()用于查找一个文件：

1）、path_lookup_open()实现文件的查找功能；要打开的文件若不存在，还需要有一个新建的过程，则调用path_lookup_create()，后者和前者封装的是同一个实际的路径查找函数，只是参数不一样，使它们在处理细节上有所偏差；

2）、当是以新建文件的方式打开文件时，即设置了O_CREAT标识时需要创建一个新的索引节点，代表创建一个文件。在vfs_create()里的一句核心语句dir->i_op->create(dir, dentry, mode, nd)可知它调用了具体的文件系统所提供的创建索引节点的方法。注意：这边的索引节点的概念，还只是位于内存之中，它和磁盘上的物理的索引节点的关系就像位于内存中和位于磁盘中的文件一样。此时新建的索引节点还不能完全标志一个物理文件的成功创建，只有当把索引节点回写到磁盘上才是一个物理文件的真正创建。想想我们以新建的方式打开一个文件，对其读写但最终没有保存而关闭，则位于内存中的索引节点会经历从新建到消失的过程，而磁盘却始终不知道有人曾经想过创建一个文件，这是因为索引节点没有回写的缘故。

3）、path_to_nameidata()填充nameidata数据结构；

4）、may_open()检查是否可以打开该文件；一些文件如链接文件和只有写权限的目录是不能被打开的，先检查nd->dentry->inode所指的文件是否是这一类文件，是的话则错误返回。还有一些文件是不能以TRUNC的方式打开的，若nd->dentry->inode所指的文件属于这一类，则显式地关闭TRUNC标志位。接着如果有以TRUNC方式打开文件的，则更新nd->dentry->inode的信息

3.1.1__path_lookup_intent_open()

不管是path_lookup_open()还是path_lookup_create()最终都是调用__path_lookup_intent_open()来实现查找文件的功能。 查找时，在遍历路径的过程中，会逐层地将各个路径组成部分解析成目录项对象，如果此目录项对象在目录项缓存中，则直接从缓存中获得；如果该目录项在缓存中不存在，则进行一次实际的读盘操作，从磁盘中读取该目录项所对应的索引节点。得到索引节点后，则建立索引节点与该目录项的联系。如此循环，直到最终找到目标文件对应的目录项，也就找到了索引节点，而由索引节点找到对应的超级块对象就可知道该文件所在的文件系统的类型。 从磁盘中读取该目录项所对应的索引节点；这将引发VFS和实际的文件系统的一次交互。从前面的VFS理论介绍可知，读索引节点方法是由超级块来提供的。而当安装一个实际的文件系统时，在内存中创建的超级块的信息是由一个实际文件系统的相关信息来填充的，这里的相关信息就包括了实际文件系统所定义的超级块的操作函数列表，当然也就包括了读索引节点的具体执行方式。 当继续追踪一个实际文件系统ext3的ext3_read_inode()时，可发现这个函数很重要的一个工作就是为不同的文件类型设置不同的索引节点操作函数表和文件操作函数表。

清单8. ext3_read_inode

3.1.2 nameidata_to_filp子函数：__dentry_open

这是VFS与实际的文件系统联系的一个关键点。从3.1.1小节分析中可知，调用实际文件系统读取索引节点的方法读取索引节点时，实际文件系统会根据文件的不同类型赋予索引节点不同的文件操作函数集，如普通文件有普通文件对应的一套操作函数，设备文件有设备文件对应的一套操作函数。这样当把对应的索引节点的文件操作函数集赋予文件对象，以后对该文件进行操作时，比如读操作，VFS虽然对各种不同文件都是执行同一个read()操作界面，但是真正读时，内核却知道怎么区分对待不同的文件类型。

清单9. __dentry_open

3.2 sys_read()

sys_read()系统调用用于从已打开的文件读取数据。如read成功，则返回读到的字节数。如已到达文件的尾端，则返回0。图9是sys_read()实现代码中的函数调用关系图。

图9. sys_read函数调用关系图

对文件进行读操作时，需要先打开它。从3.1小结可知，打开一个文件时，会在内存组装一个文件对象，希望对该文件执行的操作方法已在文件对象设置好。所以对文件进行读操作时，VFS在做了一些简单的转换后（由文件描述符得到其对应的文件对象；其核心思想是返回current->files->fd[fd]所指向的文件对象），就可以通过语句file->f_op->read(file, buf, count, pos)轻松调用实际文件系统的相应方法对文件进行读操作了。

4 解决问题

4.1 跨文件系统的文件操作的基本原理

到此，我们也就能够解释在Linux中为什么能够跨文件系统地操作文件了。举个例子，将vfat格式的磁盘上的一个文件a.txt拷贝到ext3格式的磁盘上，命名为b.txt。这包含两个过程，对a.txt进行读操作，对b.txt进行写操作。读写操作前，需要先打开文件。由前面的分析可知，打开文件时，VFS会知道该文件对应的文件系统格式，以后操作该文件时，VFS会调用其对应的实际文件系统的操作方法。所以，VFS调用vfat的读文件方法将a.txt的数据读入内存；在将a.txt在内存中的数据映射到b.txt对应的内存空间后，VFS调用ext3的写文件方法将b.txt写入磁盘；从而实现了最终的跨文件系统的复制操作。

4.2“一切皆是文件”的实现根本

不论是普通的文件，还是特殊的目录、设备等，VFS都将它们同等看待成文件，通过同一套文件操作界面来对它们进行操作。操作文件时需先打开；打开文件时，VFS会知道该文件对应的文件系统格式；当VFS把控制权传给实际的文件系统时，实际的文件系统再做出具体区分，对不同的文件类型执行不同的操作。这也就是“一切皆是文件”的根本所在。

5 总结

VFS即虚拟文件系统是Linux文件系统中的一个抽象软件层；因为它的支持，众多不同的实际文件系统才能在Linux*存，跨文件系统操作才能实现。VFS借助它四个主要的数据结构即超级块、索引节点、目录项和文件对象以及一些辅助的数据结构，向Linux中不管是普通的文件还是目录、设备、套接字等都提供同样的操作界面，如打开、读写、关闭等。只有当把控制权传给实际的文件系统时，实际的文件系统才会做出区分，对不同的文件类型执行不同的操作。由此可见，正是有了VFS的存在，跨文件系统操作才能执行，Unix/Linux中的“一切皆是文件”的口号才能够得以实现。

6 参考文献

[1].Claudia Salzberg Rodriguez, Gordon Fischer, Steven Smolski. The Linux Kernel Primer.机械工业出版社.2006.7

[2].Robert Love.Linux内核设计与实现(第二版).机械工业出版社.2007.1

[3].Stevens W.Richard.Unix环境高级编程(第二版).人民邮电出版社.2006

[4].杨芙清，陈向群.操作系统教程.北京大学出版社.2005.7

[5].Linux-2.6.17.13内核源代码

解析 Linux 中的 VFS 文件系统机制

1. 摘要

本文阐述 Linux 中的文件系统部分，源代码来自基于 IA32 的 2.4.20 内核。总体上说 Linux 下的文件系统主要可分为三大块：一是上层的文件系统的系统调用，二是虚拟文件系统 VFS(Virtual Filesystem Switch)，三是挂载到 VFS 中的各实际文件系统，例如 ext2，jffs 等。本文侧重于通过具体的代码分析来解释 Linux 内核中 VFS 的内在机制，在这过程中会涉及到上层文件系统调用和下层实际文件系统的如何挂载。文章试图从一个比较高的角度来解释 Linux 下的 VFS 文件系统机制，所以在叙述中更侧重于整个模块的主脉络，而不拘泥于细节，同时配有若干张插图，以帮助读者理解。

相对来说，VFS 部分的代码比较繁琐复杂，希望读者在阅读完本文之后，能对 Linux 下的 VFS 整体运作机制有个清楚的理解。建议读者在阅读本文前，先尝试着自己阅读一下文件系统的源代码，以便建立起 Linux 下文件系统最基本的概念，比如至少应熟悉 super block, dentry, inode，vfsmount 等数据结构所表示的意义，这样再来阅读本文以便加深理解。

2. VFS 概述

VFS 是一种软件机制，也许称它为 Linux 的文件系统管理者更确切点，与它相关的数据结构只存在于物理内存当中。所以在每次系统初始化期间，Linux 都首先要在内存当中构造一棵 VFS 的目录树(在 Linux 的源代码里称之为 namespace)，实际上便是在内存中建立相应的数据结构。VFS 目录树在 Linux 的文件系统模块中是个很重要的概念，希望读者不要将其与实际文件系统目录树混淆，在笔者看来，VFS 中的各目录其主要用途是用来提供实际文件系统的挂载点，当然在 VFS 中也会涉及到文件级的操作，本文不阐述这种情况。下文提到目录树或目录，如果不特别说明，均指 VFS 的目录树或目录。图 1 是一种可能的目录树在内存中的影像：

图 1：VFS 目录树结构

3. 文件系统的注册

这里的文件系统是指可能会被挂载到目录树中的各个实际文件系统，所谓实际文件系统，即是指VFS 中的实际操作最终要通过它们来完成而已，并不意味着它们一定要存在于某种特定的存储设备上。比如在笔者的 Linux 机器下就注册有 "rootfs"、"proc"、"ext2"、"sockfs" 等十几种文件系统。

3.1 数据结构

在 Linux 源代码中，每种实际的文件系统用以下的数据结构表示：

注册过程实际上将表示各实际文件系统的 struct file_system_type 数据结构的实例化，然后形成一个链表，内核中用一个名为 file_systems 的全局变量来指向该链表的表头。

3.2 注册 rootfs 文件系统

在众多的实际文件系统中，之所以单独介绍 rootfs 文件系统的注册过程，实在是因为该文件系统 VFS 的关系太过密切，如果说 ext2/ext3 是 Linux 的本土文件系统，那么 rootfs 文件系统则是 VFS 存在的基础。一般文件系统的注册都是通过 module_init 宏以及 do_initcalls() 函数来完成(读者可通过阅读module_init 宏的声明及 arch\i386\vmlinux.lds 文件来理解这一过程)，但是 rootfs 的注册却是通过 init_rootfs() 这一初始化函数来完成，这意味着 rootfs 的注册过程是 Linux 内核初始化阶段不可分割的一部分。

init_rootfs() 通过调用 register_filesystem(&rootfs_fs_type) 函数来完成 rootfs 文件系统注册的，其中rootfs_fs_type 定义如下：

注册之后的 file_systems 链表结构如下图2所示：

图 2: file_systems 链表结构

4. VFS 目录树的建立

既然是树，所以根是其赖以存在的基础，本节阐述 Linux 在初始化阶段是如何建立根结点的，即 "/"目录。这其中会包括挂载 rootfs 文件系统到根目录 "/" 的具体过程。构造根目录的代码是在 init_mount_tree（） 函数 （fs\namespace.c） 中。

首先，init_mount_tree() 函数会调用 do_kern_mount("rootfs", 0, "rootfs", NULL) 来挂载前面已经注册了的 rootfs 文件系统。这看起来似乎有点奇怪，因为根据前面的说法，似乎是应该先有挂载目录，然后再在其上挂载相应的文件系统，然而此时 VFS 似乎并没有建立其根目录。没关系，这是因为这里我们调用的是 do_kern_mount()，这个函数内部自然会创建我们最关心也是最关键的根目录(在 Linux 中，目录对应的数据结构是 struct dentry)。

在这个场景里，do_kern_mount() 做的工作主要是：

1）调用 alloc_vfsmnt() 函数在内存里申请了一块该类型的内存空间（struct vfsmount *mnt），并初始化其部分成员变量。

2) 调用 get_sb_nodev（） 函数在内存中分配一个超级块结构 (struct super_block) sb，并初始化其部分成员变量，将成员 s_instances 插入到 rootfs 文件系统类型结构中的 fs_supers 指向的双向链表中。

3) 通过 rootfs 文件系统中的 read_super 函数指针调用 ramfs_read_super() 函数。还记得当初注册rootfs 文件系统时，其成员 read_super 指针指向了 ramfs_read_super() 函数，参见图2.

4) ramfs_read_super() 函数调用 ramfs_get_inode() 在内存中分配了一个 inode 结构 (struct inode) inode，并初始化其部分成员变量，其中比较重要的有 i_op、i_fop 和 i_sb：

这使得将来通过文件系统调用对 VFS 发起的文件操作等指令将被 rootfs 文件系统中相应的函数接口所接管。

图3

5) ramfs_read_super() 函数在分配和初始化了 inode 结构之后，会调用 d_alloc_root() 函数来为 VFS的目录树建立起关键的根目录 (struct dentry)dentry，并将 dentry 中的 d_sb 指针指向 sb，d_inode 指针指向 inode。

6) 将 mnt 中的 mnt_sb 指针指向 sb，mnt_root 和 mnt_mountpoint 指针指向 dentry，而 mnt_parent指针则指向自身。

这样，当 do_kern_mount() 函数返回时，以上分配出来的各数据结构和 rootfs 文件系统的关系将如上图 3 所示。图中 mnt、sb、inode、dentry 结构块下方的数字表示它们在内存里被分配的先后顺序。限于篇幅的原因，各结构中只给出了部分成员变量，读者可以对照源代码根据图中所示按图索骥，以加深理解。

最后，init_mount_tree() 函数会为系统最开始的进程(即 init_task 进程)准备它的进程数据块中的namespace 域，主要目的是将 do_kern_mount() 函数中建立的 mnt 和 dentry 信息记录在了 init_task 进程的进程数据块中，这样所有以后从 init_task 进程 fork 出来的进程也都先天地继承了这一信息，在后面用sys_mkdir 在 VFS 中创建一个目录的过程中，我们可以看到这里为什么要这样做。为进程建立 namespace 的主要代码如下：

该段代码的最后两行便是将 do_kern_mount() 函数中建立的 mnt 和 dentry 信息记录在了当前进程的 fs结构中。

以上讲了一大堆数据结构的来历，其实最终目的不过是要在内存中建立一颗 VFS 目录树而已，更确切地说， init_mount_tree() 这个函数为 VFS 建立了根目录 "/"，而一旦有了根，那么这棵数就可以发展壮大，比如可以通过系统调用 sys_mkdir 在这棵树上建立新的叶子节点等，所以系统设计者又将 rootfs 文件系统挂载到了这棵树的根目录上。关于 rootfs 这个文件系统，读者如果看一下前面图 2 中它的file_system_type 结构，会发现它的一个成员函数指针 read_super 指向的是 ramfs_read_super，单从这个函数名称中的 ramfs，读者大概能猜测出这个文件所涉及的文件操作都是针对内存中的数据对象，事实上也的确如此。从另一个角度而言，因为 VFS 本身就是内存中的一个数据对象，所以在其上的操作仅限于内存，那也是非常合乎逻辑的事。在接下来的章节中，我们会用一个具体的例子来讨论如何利用 rootfs所提供的函树为 VFS 增加一个新的目录节点。

VFS 中各目录的主要用途是为以后挂载文件系统提供挂载点。所以真正的文件操作还是要通过挂载后的文件系统提供的功能接口来进行。

5. VFS 下目录的建立

为了更好地理解 VFS，下面我们用一个实际例子来看看 Linux 是如何在 VFS 的根目录下建立一个新的目录 "/dev" 的。

要在 VFS 中建立一个新的目录，首先我们得对该目录进行搜索，搜索的目的是找到将要建立的目录其父目录的相关信息，因为"皮之不存，毛将焉附"。比如要建立目录 /home/ricard，那么首先必须沿目录路径进行逐层搜索，本例中先从根目录找起，然后在根目录下找到目录 home，然后再往下，便是要新建的目录名 ricard，那么前面讲得要先对目录搜索，在该例中便是要找到 ricard 这个新目录的父目录，也就是 home 目录所对应的信息。

当然，如果搜索的过程中发现错误，比如要建目录的父目录并不存在，或者当前进程并无相应的权限等等，这种情况系统必然会调用相关过程进行处理，对于此种情况，本文略过不提。

Linux 下用系统调用 sys_mkdir 来在 VFS 目录树中增加新的节点。同时为配合路径搜索，引入了下面一个数据结构：

这个数据结构在路径搜索的过程中用来记录相关信息，起着类似"路标"的作用。其中前两项中的 dentry记录的是要建目录的父目录的信息，mnt 成员接下来会解释到。后三项记录的是所查找路径的最后一个节点(即待建目录或文件)的信息。 现在为建立目录 "/dev" 而调用 sys_mkdir("/dev", 0700)，其中参数 0700 我们不去管它，它只是限定将要建立的目录的某种模式。sys_mkdir 函数首先调用 path_lookup("/dev", LOOKUP_PARENT, &nd)；来对路径进行查找，其中 nd 为 struct nameidata nd 声明的变量。在接下来的叙述中，因为函数调用关系的繁琐，为了突出过程主线，将不再严格按照函数的调用关系来进行描述。

path_lookup 发现 "/dev" 是以 "/" 开头，所以它从当前进程的根目录开始往下查找，具体代码如下：

记得在 init_mount_tree() 函数的后半段曾经将新建立的 VFS 根目录相关信息记录在了 init_task 进程的进程数据块中，那么在这个场景里，nd->mnt 便指向了图 3 中 mnt 变量，nd->dentry 便指向了图 3 中的 dentry 变量。

然后调用函数 path_walk 接着往下查找，找到最后通过变量 nd 返回的信息是 nd.last.name="dev"，nd.last.len=3，nd.last_type=LAST_NORM，至于 nd 中 mnt 和 dentry 成员，在这个场景里还是前面设置的值，并无变化。这样一圈下来，只是用 nd 记录下相关信息，实际的目录建立工作并没有真正展开，但是前面所做的工作却为接下来建立新的节点收集了必要的信息。

好，到此为止真正建立新目录节点的工作将会展开，这是由函数 lookup_create 来完成的，调用这个函数时会传入两个参数：lookup_create(&nd, 1)；其中参数 nd 便是前面提到的变量，参数1表明要建立一个新目录。

这里的大体过程是：新分配了一个 struct dentry 结构的内存空间，用于记录 dev 目录所对应的信息，该dentry 结构将会挂接到其父目录中，也就是图 3 中 "/" 目录对应的 dentry 结构中，由链表实现这一关系。接下来会再分配一个 struct inode 结构。Inode 中的 i_sb 和 dentry 中的 d_sb 分别都指向图 3 中的 sb，这样看来，在同一文件系统下建立新的目录时并不需要重新分配一个超级块结构，因为毕竟它们都属于同一文件系统，因此一个文件系统只对应一个超级块。

这样，当调用 sys_mkdir 成功地在 VFS 的目录树中新建立一个目录 "/dev" 之后，在图 3 的基础上，新的数据结构之间的关系便如图 4 所示。图 4 中颜色较深的两个矩形块 new_inode 和 new_entry 便是在sys_mkdir() 函数中新分配的内存结构，至于图中的 mnt,sb,dentry,inode 等结构，仍为图 3 中相应的数据结构，其相互之间的链接关系不变(图中为避免过多的链接曲线，忽略了一些链接关系，如 mnt 和 sb,dentry之间的链接，读者可在图 3 的基础上参看图 4)。

需要强调一点的是，既然 rootfs 文件系统被 mount 到了 VFS 树上，那么它在 sys_mkdir 的过程中必然会参与进来，事实上在整个过程中，rootfs 文件系统中的 ramfs_mkdir、ramfs_lookup 等函数都曾被调用过。

图 4: 在 VFS 树中新建一目录 "dev"

6. 在 VFS 树中挂载文件系统

在本节中，将描述在 VFS 的目录树中向其中某个目录(安装点 mount point)上挂载(mount)一个文件系统的过程。

这一过程可简单描述为：将某一设备(dev_name)上某一文件系统(file_system_type)安装到VFS目录树上的某一安装点(dir_name)。它要解决的问题是：将对 VFS 目录树中某一目录的操作转化为具体安装到其上的实际文件系统的对应操作。比如说，如果将 hda2 上的根文件系统(假设文件系统类型为 ext2)安装到了前一节中新建立的 "/dev" 目录上(此时，"/dev" 目录就成为了安装点)，那么安装成功之后应达到这样的目的，即：对 VFS 文件系统的 "/dev" 目录执行 "ls" 指令，该条指令应能列出 hda2 上 ext2 文件系统的根目录下所有的目录和文件。很显然，这里的关键是如何将对 VFS 树中 "/dev" 的目录操作指令转化为安装在其上的 ext2 这一实际文件系统中的相应指令。所以，接下来的叙述将抓住如何转化这一核心问题。在叙述之前，读者不妨自己设想一下 Linux 系统会如何解决这一问题。记住：对目录或文件的操作将最终由目录或文件所对应的 inode 结构中的 i_op 和 i_fop 所指向的函数表中对应的函数来执行。所以，不管最终解决方案如何，都可以设想必然要通过将对 "/dev" 目录所对应的 inode 中 i_op 和 i_fop 的调用转换到 hda2 上根文件系统 ext2 中根目录所对应的 inode 中 i_op 和 i_fop 的操作。

初始过程由 sys_mount() 系统调用函数发起，该函数原型声明如下：

其中，参数 char *type 为标识将要安装的文件系统类型字符串，对于 ext2 文件系统而言，就是"ext2"。参数 flags 为安装时的模式标识数，和接下来的 data 参数一样，本文不将其做为重点。

为了帮助读者更好地理解这一过程，笔者用一个具体的例子来说明：我们准备将来自主硬盘第 2 分区(hda2)上的 ext2 文件系统安装到前面创建的 "/dev" 目录中。那么对于 sys_mount() 函数的调用便具体为：

该函数在将这些来自用户内存空间(user space)的参数拷贝到内核空间后，便调用 do_mount() 函数开始真正的安装文件系统的工作。同样，为了便于叙述和讲清楚主流程，接下来的说明将不严格按照具体的函数调用细节来进行。

do_mount() 函数会首先调用 path_lookup() 函数来得到安装点的相关信息，如同创建目录过程中叙述的那样，该安装点的信息最终记录在 struct nameidata 类型的一个变量当中，为叙述方便，记该变量为nd。在本例中当 path_lookup() 函数返回时，nd 中记录的信息如下：nd.entry = new_entry; nd.mnt = mnt; 这里的变量如图 3 和 4 中所示。

然后，do_mount() 函数会根据调用参数 flags 来决定调用以下四个函数之一：do_remount()、 do_loopback()、do_move_mount()、do_add_mount()。

在我们当前的例子中，系统会调用 do_add_mount() 函数来向 VFS 树中安装点 "/dev " 安装一个实际的文件系统。在 do_add_mount() 中，主要完成了两件重要事情：一是获得一个新的安装区域块，二是将该新的安装区域块加入了安装系统链表。它们分别是调用 do_kern_mount() 函数和 graft_tree() 函数来完成的。这里的描述可能有点抽象，诸如安装区域块、安装系统链表等，不过不用着急，因为它们都是笔者自己定义出来的概念，等一下到后面会有专门的图表解释，到时便会清楚。

do_kern_mount() 函数要做的事情，便是建立一新的安装区域块，具体的内容在前面的章节 VFS 目录树的建立中已经叙述过，这里不再赘述。

graft_tree() 函数要做的事情便是将 do_kern_mount() 函数返回的一 struct vfsmount 类型的变量加入到安装系统链表中，同时 graft_tree() 还要将新分配的 struct vfsmount 类型的变量加入到一个hash表中，其目的我们将会在以后看到。

这样，当 do_kern_mount() 函数返回时，在图 4 的基础上，新的数据结构间的关系将如图 5 所示。其中，红圈区域里面的数据结构便是被称做安装区域块的东西，其中不妨称 e2_mnt 为安装区域块的指针，蓝色箭头曲线即构成了所谓的安装系统链表。

在把这些函数调用后形成的数据结构关系理清楚之后，让我们回到本章节开始提到的问题，即将 ext2 文件系统安装到了 "/dev " 上之后，对该目录上的操作如何转化为对 ext2 文件系统相应的操作。从图 5上看到，对 sys_mount() 函数的调用并没有直接改变 "/dev " 目录所对应的 inode (即图中的 new_inode变量)结构中的 i_op 和 i_fop 指针，而且 "/dev " 所对应的 dentry(即图中的 new_dentry 变量)结构仍然在 VFS 的目录树中，并没有被从其中隐藏起来，相应地，来自 hda2 上的 ext2 文件系统的根目录所对应的 e2_entry 也不是如当初笔者所想象地那样将 VFS 目录树中的 new_dentry 取而代之，那么这之间的转化到底是如何实现的呢？

请读者注意下面的这段代码：

这段代码在 link_path_walk() 函数中被调用，而 link_path_walk() 最终又会被 path_lookup() 函数调用，如果读者阅读过 Linux 关于文件系统部分的代码，应该知道 path_lookup() 函数在整个 Linux 繁琐的文件系统代码中属于一个重要的基础性的函数。简单说来，这个函数用于解析文件路径名，这里的文件路径名和我们平时在应用程序中所涉及到的概念相同，比如在 Linux 的应用程序中 open 或 read 一个文件 /home/windfly.cs 时，这里的 /home/windfly.cs 就是文件路径名，path_lookup() 函数的责任就是对文件路径名中进行搜索，直到找到目标文件所属目录所对应的 dentry 或者目标直接就是一个目录，笔者不想在有限的篇幅里详细解释这个函数，读者只要记住 path_lookup() 会返回一个目标目录即可。

上面的代码非常地不起眼，以至于初次阅读文件系统的代码时经常会忽略掉它，但是前文所提到从 VFS 的操作到实际文件系统操作的转化却是由它完成的，对 VFS 中实现的文件系统的安装可谓功不可没。现在让我们仔细剖析一下该段代码： d_mountpoint(dentry) 的作用很简单，它只是返回 dentry 中 d_mounted 成员变量的值。这里的dentry 仍然还是 VFS 目录树上的东西。如果 VFS 目录树上某个目录被安装过一次，那么该值为 1。对VFS 中的一个目录可进行多次安装，后面会有例子说明这种情况。在我们的例子中，"/dev" 所对应的new_dentry 中 d_mounted=1，所以 while 循环中第一个条件满足。下面再来看__follow_down(&nd->mnt, &dentry)代

图 5：安装 ext2 类型根文件系统到 "/dev " 目录上

码做了什么？到此我们应该记住，这里 nd 中的 dentry 成员就是图 5 中的 new_dentry，nd 中的 mnt成员就是图 5 中的 mnt，所以我们现在可以把 __follow_down(&nd->mnt, &dentry) 改写成__follow_down(&mnt, &new_dentry)，接下来我们将 __follow_down() 函数的代码改写(只是去处掉一些不太相关的代码，并且为了便于说明，在部分代码行前加上了序号)如下：

代码行[1]中的 lookup_mnt() 函数用于查找一个 VFS 目录树下某一目录最近一次被 mount 时的安装区域块的指针，在本例中最终会返回图 5 中的 e2_mnt。至于查找的原理，这里粗略地描述一下。记得当我们在安装 ext2 文件系统到 "/dev" 时，在后期会调用 graft_tree() 函数，在这个函数里会把图 5 中的安装区域块指针 e2_mnt 挂到一 hash 表(Linux 2.4.20源代码中称之为 mount_hashtable)中的某一项，而该项的键值就是由被安装点所对应的 dentry(本例中为 new_dentry)和 mount(本例中为 mnt)所共同产生，所以自然地，当我们知道 VFS 树中某一 dentry 被安装过(该 dentry 变成为一安装点)，而要去查找其最近一次被安装的安装区域块指针时，同样由该安装点所对应的 dentry 和 mount 来产生一键值，以此值去索引 mount_hashtable，自然可找到该安装点对应的安装区域块指针形成的链表的头指针，然后遍历该链表，当发现某一安装区域块指针，记为 p，满足以下条件时：

P 便为该安装点所对应的安装区域块指针。当找到该指针后，便将 nd 中的 mnt 成员换成该安装区域块指针，同时将 nd 中的 dentry 成员换成安装区域块中的 dentry 指针。在我们的例子中，e2_mnt->mnt_root成员指向 e2_dentry，也就是 ext2 文件系统的 "/" 目录。这样，当 path_lookup() 函数搜索到 "/dev"时，nd 中的 dentry 成员为 e2_dentry，而不再是原来的 new_dentry，同时 mnt 成员被换成 e2_mnt，转化便在不知不觉中完成了。

现在考虑一下对某一安装点多次安装的情况，同样作为例子，我们假设在 "/dev" 上安装完一个 ext2文件系统后，再在其上安装一个 ntfs 文件系统。在安装之前，同样会对安装点所在的路径调用path_lookup() 函数进行搜索，但是这次由于在 "/dev" 目录上已经安装过了 ext2 文件系统，所以搜索到最后，由 nd 返回的信息是：nd.dentry = e2_dentry, nd.mnt = e2_mnt。由此可见，在第二次安装时，安装点已经由 dentry 变成了 e2_dentry。接下来，同样地，系统会再分配一个安装区域块，假设该安装区域块的指针为 ntfs_mnt，区域块中的 dentry 为 ntfs_dentry。ntfs_mnt 的父指针指向了e2_mnt，mnfs_mnt 中的 mnt_root 指向了代表 ntfs 文件系统根目录的 ntfs_dentry。然后，系统通过 e2_dentry和 e2_mnt 来生成一个新的 hash 键值，利用该值作为索引，将 ntfs_mnt 加入到 mount_hashtable 中，同时将 e2_dentry 中的成员 d_mounted 值设定为 1。这样，安装过程便告结束。

读者可能已经知道，对同一安装点上的最近一次安装会隐藏起前面的若干次安装，下面我们通过上述的例子解释一下该过程：

在先后将 ext2 和 ntfs 文件系统安装到 "/dev" 目录之后，我们再调用 path_lookup() 函数来对"/dev" 进行搜索，函数首先找到 VFS 目录树下的安装点 "/dev" 所对应的 dentry 和 mnt，此时它发现dentry 成员中的 d_mounted 为 1，于是它知道已经有文件系统安装到了该 dentry 上，于是它通过 dentry 和 mnt 来生成一个 hash 值，通过该值来对 mount_hashtable 进行搜索，根据安装过程，它应该能找到 e2_mnt 指针并返回之，同时原先的 dentry 也已经被替换成 e2_dentry。回头再看一下前面已经提到的下列代码： while (d_mountpoint(dentry) && __follow_down(&nd->mnt, &dentry)); 当第一次循环结束后, nd->mnt 已经是 e2_mnt，而 dentry 则变成 e2_dentry。此时由于 e2_dentry 中的成员 d_mounted 值为 1，所以 while 循环的第一个条件满足，要继续调用 __follow_down() 函数，这个函数前面已经剖析过，当它返回后 nd->mnt 变成了 ntfs_mnt，dentry 则变成了 ntfs_dentry。由于此时 ntfs_dentry 没有被安装过其他文件，所以它的成员 d_mounted 应该为 0，循环结束。对 "/dev" 发起的 path_lookup() 函数最终返回了 ntfs 文件系统根目录所对应的 dentry。这就是为什么 "/dev" 本身和安装在其上的 ext2 都被隐藏的原因。如果此时对 "/dev" 目录进行一个 ls 命令，将返回安装上去的 ntfs 文件系统根目录下所有的文件和目录。

7. 安装根文件系统

有了前面章节 5 的基础，理解 Linux 下根文件系统的安装并不困难，因为不管怎么样，安装一个文件系统到 VFS 中某一安装点的过程原理毕竟都是一样的。

这个过程大致是：首先要确定待安装的 ext2 文件系统的来源，其次是确定 ext2 文件系统在 VFS中的安装点，然后便是具体的安装过程。

关于第一问题，Linux 2.4.20 的内核另有一大堆的代码去解决，限于篇幅，笔者不想在这里去具体说明这个过程，大概记住它是要解决到哪里去找要安装的文件系统的就可以了，这里我们不妨就认为要安装的根文件系统就来自于主硬盘的第一分区 hda1.

关于第二个问题，Linux 2.4.20 的内核把来自于 hda1 上 ext2 文件系统安装到了 VFS 目录树中的"/root" 目录上。其实，把 ext2 文件系统安装到 VFS 目录树下的哪个安装点并不重要(VFS 的根目录除外)，只要是这个安装点在 VFS 树中是存在的，并且内核对它没有另外的用途。如果读者喜欢，尽可以自己在 VFS 中创建一个 "/Windows" 目录，然后将 ext2 文件系统安装上去作为将来用户进程的根目录，没有什么不可以的。问题的关键是要将进程的根目录和当前工作目录设定好，因为毕竟只用用户进程才去关心现实的文件系统，要知道笔者的这篇稿子可是要存到硬盘上去的。

在 Linux 下，设定一个进程的当前工作目录是通过系统调用 sys_chdir() 进行的。初始化期间，Linux 在将 hda1 上的 ext2 文件系统安装到了 "/root" 上后，通过调用 sys_chdir("/root") 将当前进程，也就是 init_task 进程的当前工作目录(pwd)设定为 ext2 文件系统的根目录。记住此时 init_task进程的根目录仍然是图 3 中的 dentry，也就是 VFS 树的根目录，这显然是不行的，因为以后 Linux 世界中的所有进程都由这个 init_task 进程派生出来，无一例外地要继承该进程的根目录，如果是这样，意味着用户进程从根目录搜索某一目录时，实际上是从 VFS 的根目录开始的，而事实上却是从 ext2 的根文件开始搜索的。这个矛盾的解决是靠了在调用完 mount_root() 函数后，系统调用的下面两个函数：

其主要作用便是将 init_task 进程的根目录转化成安装上去的 ext2 文件系统的根目录。有兴趣的读者可以自行去研究这一过程。

所以在用户空间下，更多地情况是只能见到 VFS 这棵大树的一叶，而且还是被安装过文件系统了的，实际上对用户空间来说还是不可见。我想，VFS 更多地被内核用来实现自己的功能，并以系统调用的方式提供过用户进程使用，至于在其上实现的不同文件系统的安装，也只是其中的一个功能罢了。

8. 结束语

文件系统在整个 Linux 的内核中具有举足轻重的地位，代码量也很复杂繁琐。但是因为其重要的地位，要想对 Linux 的内核有比较深入的理解，必须要能越过文件系统这一关。当然阅读其源代码便是其中最好的方法，本文试图给那些已经尝试着去阅读，但是目前尚有困惑的读者画一张 VFS 文件系统的草图，希望能对读者有些许启发。但是想在如此有限的篇幅里去阐述清楚 Linux 中整个文件系统的来龙去脉，是根本不现实的。而且本文也只是侧重于剖析 VFS 的机制，对于象具体的文件读写，为提高效率而引入的各种 buffer,hash 等内容以及文件系统的安全性方面，都没有提到。毕竟，本文只想帮助读者理清一个大体的脉络，最终的理解与领悟，还得靠读者自己去潜心研究源代码。最后，对本文相关的任何问题或建议，都欢迎用 email 和笔者联系。

1. 通用文件模型

Linux内核支持装载不同的文件系统类型，不同的文件系统有各自管理文件的方式。Linux中标准的文件系统为Ext文件系统族，当然，开发者不能为他们使用的每种文件系统采用不同的文件存取方式，这与操作系统作为一种抽象机制背道而驰。

为支持各种文件系统，Linux内核在用户进程（或C标准库）和具体的文件系统之间引入了一个抽象层，该抽象层称之为“虚拟文件系统（VFS）”。

VFS一方面提供一种操作文件、目录及其他对象的统一方法，使用户进程不必知道文件系统的细节。另一方面，VFS提供的各种方法必须和具体文件系统的实现达成一种妥协，毕竟对几十种文件系统类型进行统一管理并不是件容易的事。

为此，VFS中定义了一个通用文件模型，以支持文件系统中对象（或文件）的统一视图。

Linux对Ext文件系统族的支持是最好的，因为VFS抽象层的组织与Ext文件系统类似，这样在处理Ext文件系统时可以提高性能，因为在Ext和VFS之间转换几乎不会损失时间。

内核处理文件的关键是inode，每个文件（和目录）都有且只有一个对应的inode（struct inode实例），其中包含元数据和指向文件数据的指针，但inode并不包含文件名。系统中所有的inode都有一个特定的编号，用于唯一的标识各个inode。文件名可以随时更改，但是索引节点对文件是唯一的，并且随文件的存在而存在。

对于每个已经挂载的文件系统，VFS在内核中都生成一个超级块结构（struct super_block实例），超级块代表一个已经安装的文件系统，用于存储文件系统的控制信息，例如文件系统类型、大小、所有inode对象、脏的inode链表等。

inode和super block在存储介质中都是有实际映射的，即存储介质中也存在超级块和inode。但是由于不同类型的文件系统差异，超级块和inode的结构不尽相同。而VFS的作用就是通过具体的设备驱动获得某个文件系统中的超级块和inode节点，然后将其中的信息填充到内核中的struct super_block和struct inode中，以此来试图对不同文件系统进行统一管理。

由于块设备速度较慢（于内存而言），可能需要很长时间才能找到与一个文件名关联的inode。Linux使用目录项（dentry）缓存来快速访问此前的查找操作结果。在VFS读取了一个目录或文件的数据之后，则创建一个dentry实例（struct dentry），以缓存找到的数据。

dentry结构的主要用途就是建立文件名和相关的inode之间的联系。一个文件系统中的dentry对象都被放在一个散列表中，同时不再使用的dentry对象被放到超级块指向的一个LRU链表中，在某个时间点会删除比较老的对象以释放内存。

另外简单提一下两个数据结构：

每种注册到内核的文件系统类型以struct file_system_type结构表示，每种文件系统类型中都有一个链表，指向所有属于该类型的文件系统的超级块。

当一个文件系统挂载到内核文件系统的目录树上，会生成一个挂载点，用来管理所挂载的文件系统的信息。该挂载点用一个struct vfsmount结构表示，这个结构后面会提到。

上面的这些结构的关系大致如下：

其中红色字体的链表为内核中的全局链表。

2. 挂载文件系统

在用户程序中，使用mount系统调用来挂载文件系统，相应的使用umount卸载文件系统。当然，内核必须支持将要挂载的文件系统类型，在内核启动时或者在安装内核模块时，可以注册特定的文件系统类型到内核，注册的函数为register_filesystem()。

mount命令最常用的方式是mount [-t fstype] something somewhere

其中something是将要被挂载的设备或目录，somewhere指明要挂载到何处。-t选项指明挂载的文件系统类型。由于something指向的设备是一个已知设备，即其上的文件系统类型是确定的，所以-t选项必须设置正确才能挂载成功。

每个装载的文件系统都对应一个vfsmount结构的实例。

由于装载过程是向内核文件系统目录树中添加装载点，这些装载点就存在一种父子关系，这和父目录与子目录的关系类似。例如，我的根文件系统类型是squashfs，装载到根目录“/”，生成一个挂载点，之后我又在/tmp目录挂载了ramfs文件系统，在根文件系统中的tmp目录生成了一个挂载点，这两个挂载点就是父子关系。这种关系存储在struct
vfsmount结构中。

在下图中，根文件系统为squashfs，根目录为“/”，然后创建/tmp目录，并挂载为ramfs，之后又创建了/tmp/usbdisk/volume9和/tmp/usbdisk/volume1两个目录，并将/tmp/dev/sda1和/tmp/dev/sdb1两个分区挂载到这两个目录上。其中/tmp/dev/sda1设备上有如下文件：

gccbacktrace/

----> gcc_backtrace.c

---->man_page.log

---->readme.txt

notes-fs.txt

smb.conf

挂载完成后，VFS中相关的数据结构的关系如图所示。

mount系统调用在内核中的入口点是sys_mount函数，该函数将装载的选项从用户态复制一份，然后调用do_mount()函数进行挂载，这个函数做的事情就是通过特定文件系统读取超级块和inode信息，然后建立VFS的数据结构并建立上图中的关系。

在父文件系统中的某个目录上挂载另一个文件系统后，该目录原来的内容就被隐藏了。例如，/tmp/samba/是非空的，然后，我将/tmp/dev/sda1挂载到/tmp/samba上，那这时/tmp/samba/目录下就只能看到/tmp/dev/sda1设备上的文件，直到将该设备卸载，原来目录中的文件才会显示出来。这是通过struct

vfsmount中的mnt_mountpoint和mnt_root两个成员来实现的，这两个成员分别保存了在父文件系统中挂载点的dentry和在当前文件系统中挂载点的dentry，在卸载当前挂载点之后，可以找回挂载目录在父文件系统中的dentry对象。

3. 一个进程中与文件系统相关的信息

其中fs成员指向进程当前工作目录的文件系统信息。files成员指向了进程打开的文件的信息。nsproxy指向了进程所在的命名空间，其中包含了虚拟文件系统命名空间。

从上图可以看到，fs中包含了文件系统的挂载点和挂载点的dentry信息。而files指向了一系列的struct file结构，其中struct
path结构用于将struct file和vfsmount以及dentry联系起来。struct file保存了内核所看到的文件的特征信息，进程打开的文件列表就存放在task_struct->files->fd_array[]数组以及fdtable中。

task_struct结构还存放了其打开文件的文件描述符fd的信息，这是用户进程需要用到的，用户进程在通过文件名打开一个文件后，文件名就没有用处了，之后的操作都是对文件描述符fd的，在内核中，fget_light()函数用于通过整数fd来查找对应的struct
file对象。由于每个进程都维护了自己的fd列表，所以不同进程维护的fd的值可以重复，例如标准输入、标准输出和标准错误对应的fd分别为0、1、2。

struct file的mapping成员指向属于文件相关的inode实例的地址空间映射，通常它设置为inode->i_mapping。在读写一个文件时，每次都从物理设备上获取文件的话，速度会很慢，在内核中对每个文件分配一个地址空间，实际上是这个文件的数据缓存区域，在读写文件时只是操作这块缓存，通过内核有相应的同步机制将脏的页写回物理设备。super_block中维护了一个脏的inode的链表。

struct file的f_op成员指向一个struct file_operations实例，该结构保存了指向所有可能文件操作的指针，如read/write/open等。

4. 打包文件系统

在制作好了文件系统的目录之后，可通过特定于文件系统类型的工具对目录进行打包，即制作文件系统。例如squashfs文件系统的打包工具为mksquashfs。除了打包之外，打包工具还针对特定文件系统生成超级块和inode节点信息，最终生成的文件系统镜像可以被内核解释并挂载。

附录 VFS相关数据结构

inode：

super_block：

dentry：

vfsmount：

linux文件系统体系结构 和 虚拟文件系统(VFS)

图 1. Linux 文件系统组件的体系结构

用户空间包含一些应用程序（例如，文件系统的使用者）和 GNU C 库（glibc），它们为文件系统调用（打开、读取、写和关闭）提供用户接口。系统调用接口的作用就像是交换器，它将系统调用从用户空间发送到内核空间中的适当端点。

VFS 是底层文件系统的主要接口。这个组件导出一组接口，然后将它们抽象到各个文件系统，各个文件系统的行为可能差异很大。有两个针对文件系统对象的缓存（inode 和 dentry）。它们缓存最近使用过的文件系统对象。

每个文件系统实现（比如 ext2、JFS 等等）导出一组通用接口，供 VFS
使用。缓冲区缓存会缓存文件系统和相关块设备之间的请求。例如，对底层设备驱动程序的读写请求会通过缓冲区缓存来传递。这就允许在其中缓存请求，减少访问物理设备的次数，加快访问速度。以最近使用（LRU）列表的形式管理缓冲区缓存。注意，可以使用 sync 命令将缓冲区缓存中的请求发送到存储媒体（迫使所有未写的数据发送到设备驱动程序，进而发送到存储设备）。

什么是块设备？ 块设备就是以块（比如磁盘扇区）为单位收发数据的设备，它们支持缓冲和随机访问（不必顺序读取块，而是可以在任何时候访问任何块）等特性。块设备包括硬盘、CD-ROM 和 RAM 盘。与块设备相对的是字符设备，字符设备没有可以进行物理寻址的媒体。字符设备包括串行端口和磁带设备，只能逐字符地读取这些设备中的数据。

这就是 VFS 和文件系统组件的高层情况。现在，讨论实现这个子系统的主要结构。

主要结构

Linux
以一组通用对象的角度看待所有文件系统。这些对象是超级块（superblock）、inode、dentry
和文件。超级块在每个文件系统的根上，超级块描述和维护文件系统的状态。文件系统中管理的每个对象（文件或目录）在 Linux 中表示为一个
inode。inode 包含管理文件系统中的对象所需的所有元数据（包括可以在对象上执行的操作）。另一组结构称为 dentry，它们用来实现名称和
inode 之间的映射，有一个目录缓存用来保存最近使用的
dentry。dentry 还维护目录和文件之间的关系，从而支持在文件系统中移动。最后，VFS
文件表示一个打开的文件（保存打开的文件的状态，比如写偏移量等等）。

虚拟文件系统层

VFS 作为文件系统接口的根层。VFS 记录当前支持的文件系统以及当前挂装的文件系统。

可以使用一组注册函数在 Linux 中动态地添加或删除文件系统。内核保存当前支持的文件系统的列表，可以通过 /proc 文件系统在用户空间中查看这个列表。这个虚拟文件还显示当前与这些文件系统相关联的设备。在 Linux 中添加新文件系统的方法是调用 register_filesystem。这个函数的参数定义一个文件系统结构（file_system_type）的引用，这个结构定义文件系统的名称、一组属性和两个超级块函数。也可以注销文件系统。

在注册新的文件系统时，会把这个文件系统和它的相关信息添加到 file_systems 列表中（见图 2 和 linux/include/linux/mount.h）。这个列表定义可以支持的文件系统。在命令行上输入 cat /proc/filesystems，就可以查看这个列表。

图 2. 向内核注册的文件系统

VFS 中维护的另一个结构是挂装的文件系统（见图 3）。这个结构提供当前挂装的文件系统（见 linux/include/linux/fs.h）。它链接下面讨论的超级块结构。

图 3. 挂装的文件系统列表 

超级块

超级块结构表示一个文件系统。它包含管理文件系统所需的信息，包括文件系统名称（比如
ext2）、文件系统的大小和状态、块设备的引用和元数据信息（比如空闲列表等等）。超级块通常存储在存储媒体上，但是如果超级块不存在，也可以实时创建它。可以在
./linux/include/linux/fs.h 中找到超级块结构（见图 4）。

图 4. 超级块结构和 inode 操作 

超级块中的一个重要元素是超级块操作的定义。这个结构定义一组用来管理这个文件系统中的 inode 的函数。例如，可以用 alloc_inode 分配 inode，用 destroy_inode 删除 inode。可以用 read_inode 和write_inode 读写
inode，用 sync_fs 执行文件系统同步。可以在 ./linux/include/linux/fs.h 中找到 super_operations 结构。每个文件系统提供自己的 inode 方法，这些方法实现操作并向 VFS 层提供通用的抽象。

inode 和 dentry

inode 表示文件系统中的一个对象，它具有惟一标识符。各个文件系统提供将文件名映射为惟一 inode 标识符和 inode 引用的方法。图 5 显示 inode 结构的一部分以及两个相关结构。请特别注意inode_operations 和 file_operations。这些结构表示可以在这个 inode 上执行的操作。inode_operations 定义直接在
inode 上执行的操作，而 file_operations 定义与文件和目录相关的方法（标准系统调用）。

图 5. inode 结构和相关联的操作 

inode 和目录缓存分别保存最近使用的 inode 和 dentry。注意，对于 inode 缓存中的每个 inode，在目录缓存中都有一个对应的 dentry。可以在 ./linux/include/linux/fs.h 中找到 inode 和 dentry 结构。

缓冲区缓存

除了各个文件系统实现（可以在 ./linux/fs
中找到）之外，文件系统层的底部是缓冲区缓存。这个组件跟踪来自文件系统实现和物理设备（通过设备驱动程序）的读写请求。为了提高效率，Linux
对请求进行缓存，避免将所有请求发送到物理设备。缓存中缓存最近使用的缓冲区（页面），这些缓冲区可以快速提供给各个文件系统。

《Linux内核设计与实现》读书笔记（十三）- 虚拟文件系统

/*

 * 超级块结构中定义的字段非常多，

 * 这里只介绍一些重要的属性

 */

struct super_block {

    struct list_head    s_list;               /* 指向所有超级块的链表 */

    const struct super_operations    *s_op; /* 超级块方法 */

    struct dentry        *s_root;           /* 目录挂载点 */

    struct mutex        s_lock;            /* 超级块信号量 */

    int            s_count;                   /* 超级块引用计数 */

    struct list_head    s_inodes;           /* inode链表 */

    struct mtd_info        *s_mtd;            /* 存储磁盘信息 */

    fmode_t            s_mode;                /* 安装权限 */

};

/*

 * 其中的 s_op 中定义了超级块的操作方法

 * 这里只介绍一些相对重要的函数

 */

struct super_operations {

       struct inode *(*alloc_inode)(struct super_block *sb); /* 创建和初始化一个索引节点对象 */

    void (*destroy_inode)(struct inode *);                /* 释放给定的索引节点 */

       void (*dirty_inode) (struct inode *);                 /* VFS在索引节点被修改时会调用这个函数 */

    int (*write_inode) (struct inode *, int);             /* 将索引节点写入磁盘，wait表示写操作是否需要同步 */

    void (*drop_inode) (struct inode *);                  /* 最后一个指向索引节点的引用被删除后，VFS会调用这个函数 */

    void (*delete_inode) (struct inode *);                /* 从磁盘上删除指定的索引节点 */

    void (*put_super) (struct super_block *);             /* 卸载文件系统时由VFS调用，用来释放超级块 */

    void (*write_super) (struct super_block *);           /* 用给定的超级块更新磁盘上的超级块 */

    int (*sync_fs)(struct super_block *sb, int wait);     /* 使文件系统中的数据与磁盘上的数据同步 */

    int (*statfs) (struct dentry *, struct kstatfs *);    /* VFS调用该函数获取文件系统状态 */

    int (*remount_fs) (struct super_block *, int *, char *); /* 指定新的安装选项重新安装文件系统时，VFS会调用该函数 */

    void (*clear_inode) (struct inode *);                 /* VFS调用该函数释放索引节点，并清空包含相关数据的所有页面 */

    void (*umount_begin) (struct super_block *);          /* VFS调用该函数中断安装操作 */

};

/*

 * 索引节点结构中定义的字段非常多，

 * 这里只介绍一些重要的属性

 */

struct inode {

    struct hlist_node    i_hash;     /* 散列表，用于快速查找inode */

    struct list_head    i_list;        /* 索引节点链表 */

    struct list_head    i_sb_list;  /* 超级块链表超级块  */

    struct list_head    i_dentry;   /* 目录项链表 */

    unsigned long        i_ino;      /* 节点号 */

    atomic_t        i_count;        /* 引用计数 */

    unsigned int        i_nlink;    /* 硬链接数 */

    uid_t            i_uid;          /* 使用者id */

    gid_t            i_gid;          /* 使用组id */

    struct timespec        i_atime;    /* 最后访问时间 */

    struct timespec        i_mtime;    /* 最后修改时间 */

    struct timespec        i_ctime;    /* 最后改变时间 */

    const struct inode_operations    *i_op;  /* 索引节点操作函数 */

    const struct file_operations    *i_fop;    /* 缺省的索引节点操作 */

    struct super_block    *i_sb;              /* 相关的超级块 */

    struct address_space    *i_mapping;     /* 相关的地址映射 */

    struct address_space    i_data;         /* 设备地址映射 */

    unsigned int        i_flags;            /* 文件系统标志 */

    void            *i_private;             /* fs 私有指针 */

};

/*

 * 其中的 i_op 中定义了索引节点的操作方法

 * 这里只介绍一些相对重要的函数

 */

struct inode_operations {

    /* 为dentry对象创造一个新的索引节点 */

    int (*create) (struct inode *,struct dentry *,int, struct nameidata *);

    /* 在特定文件夹中寻找索引节点，该索引节点要对应于dentry中给出的文件名 */

    struct dentry * (*lookup) (struct inode *,struct dentry *, struct nameidata *);

    /* 创建硬链接 */

    int (*link) (struct dentry *,struct inode *,struct dentry *);

    /* 从一个符号链接查找它指向的索引节点 */

    void * (*follow_link) (struct dentry *, struct nameidata *);

    /* 在 follow_link调用之后，该函数由VFS调用进行清除工作 */

    void (*put_link) (struct dentry *, struct nameidata *, void *);

    /* 该函数由VFS调用，用于修改文件的大小 */

    void (*truncate) (struct inode *);

};

[wangyubin@localhost kernel]$ sudo cat /proc/slabinfo | grep dentry

dentry            212545 212625    192   21    1 : tunables    0    0    0 : slabdata  10125  10125      

/* 目录项对象结构 */

struct dentry {

    atomic_t d_count;       /* 使用计数 */

    unsigned int d_flags;   /* 目录项标识 */

    spinlock_t d_lock;        /* 单目录项锁 */

    int d_mounted;          /* 是否登录点的目录项 */

    struct inode *d_inode;    /* 相关联的索引节点 */

    struct hlist_node d_hash;    /* 散列表 */

    struct dentry *d_parent;    /* 父目录的目录项对象 */

    struct qstr d_name;         /* 目录项名称 */

    struct list_head d_lru;        /* 未使用的链表 */

    /*

     * d_child and d_rcu can share memory

     */

    union {

        struct list_head d_child;    /* child of parent list */

         struct rcu_head d_rcu;

    } d_u;

    struct list_head d_subdirs;    /* 子目录链表 */

    struct list_head d_alias;    /* 索引节点别名链表 */

    unsigned long d_time;        /* 重置时间 */

    const struct dentry_operations *d_op; /* 目录项操作相关函数 */

    struct super_block *d_sb;    /* 文件的超级块 */

    void *d_fsdata;            /* 文件系统特有数据 */

    unsigned char d_iname[DNAME_INLINE_LEN_MIN];    /* 短文件名 */

};

/* 目录项相关操作函数 */

struct dentry_operations {

    /* 该函数判断目录项对象是否有效。VFS准备从dcache中使用一个目录项时会调用这个函数 */

    int (*d_revalidate)(struct dentry *, struct nameidata *);

    /* 为目录项对象生成hash值 */

    int (*d_hash) (struct dentry *, struct qstr *);

    /* 比较 qstr 类型的2个文件名 */

    int (*d_compare) (struct dentry *, struct qstr *, struct qstr *);

    /* 当目录项对象的 d_count 为0时，VFS调用这个函数 */

    int (*d_delete)(struct dentry *);

    /* 当目录项对象将要被释放时，VFS调用该函数 */

    void (*d_release)(struct dentry *);

    /* 当目录项对象丢失其索引节点时（也就是磁盘索引节点被删除了），VFS会调用该函数 */

    void (*d_iput)(struct dentry *, struct inode *);

    char *(*d_dname)(struct dentry *, char *, int);

};

/*

 * 文件对象结构中定义的字段非常多，

 * 这里只介绍一些重要的属性

 */

struct file {

    union {

        struct list_head    fu_list;    /* 文件对象链表 */

        struct rcu_head     fu_rcuhead; /* 释放之后的RCU链表 */

    } f_u;

    struct path        f_path;             /* 包含的目录项 */

    const struct file_operations    *f_op; /* 文件操作函数 */

    atomic_long_t        f_count;        /* 文件对象引用计数 */

};

/*

 * 其中的 f_op 中定义了文件对象的操作方法

 * 这里只介绍一些相对重要的函数

 */

struct file_operations {

    /* 用于更新偏移量指针,由系统调用lleek()调用它 */

    loff_t (*llseek) (struct file *, loff_t, int);

    /* 由系统调用read()调用它 */

    ssize_t (*read) (struct file *, char __user *, size_t, loff_t *);

    /* 由系统调用write()调用它 */

    ssize_t (*write) (struct file *, const char __user *, size_t, loff_t *);

    /* 由系统调用 aio_read() 调用它 */

    ssize_t (*aio_read) (struct kiocb *, const struct iovec *, unsigned long, loff_t);

    /* 由系统调用 aio_write() 调用它 */

    ssize_t (*aio_write) (struct kiocb *, const struct iovec *, unsigned long, loff_t);

    /* 将给定文件映射到指定的地址空间上,由系统调用 mmap 调用它 */

    int (*mmap) (struct file *, struct vm_area_struct *);

    /* 创建一个新的文件对象,并将它和相应的索引节点对象关联起来 */

    int (*open) (struct inode *, struct file *);

    /* 当已打开文件的引用计数减少时,VFS调用该函数 */

    int (*flush) (struct file *, fl_owner_t id);

};

struct file_system_type {

    const char *name;   /* 文件系统名称 */

    int fs_flags;       /* 文件系统类型标志 */

    /* 从磁盘中读取超级块,并且在文件系统被安装时,在内存中组装超级块对象 */

    int (*get_sb) (struct file_system_type *, int,

               const char *, void *, struct vfsmount *);

    /* 终止访问超级块 */

    void (*kill_sb) (struct super_block *);

    struct module *owner;           /* 文件系统模块 */

    struct file_system_type * next; /* 链表中下一个文件系统类型 */

    struct list_head fs_supers;     /* 超级块对象链表 */

    /* 下面都是运行时的锁 */

    struct lock_class_key s_lock_key;

    struct lock_class_key s_umount_key;

    struct lock_class_key i_lock_key;

    struct lock_class_key i_mutex_key;

    struct lock_class_key i_mutex_dir_key;

    struct lock_class_key i_alloc_sem_key;

};

struct vfsmount {

    struct list_head mnt_hash;      /* 散列表 */

    struct vfsmount *mnt_parent;    /* 父文件系统，也就是要挂载到哪个文件系统 */

    struct dentry *mnt_mountpoint;    /* 安装点的目录项 */

    struct dentry *mnt_root;        /* 该文件系统的根目录项 */

    struct super_block *mnt_sb;        /* 该文件系统的超级块 */

    struct list_head mnt_mounts;    /* 子文件系统链表 */

    struct list_head mnt_child;        /* 子文件系统链表 */

    int mnt_flags;                  /* 安装标志 */

    /* 4 bytes hole on 64bits arches */

    const char *mnt_devname;        /* 设备文件名 e.g. /dev/dsk/hda1 */

    struct list_head mnt_list;      /* 描述符链表 */

    struct list_head mnt_expire;    /* 到期链表的入口 */

    struct list_head mnt_share;        /* 共享安装链表的入口 */

    struct list_head mnt_slave_list;/* 从安装链表 */

    struct list_head mnt_slave;        /* 从安装链表的入口 */

    struct vfsmount *mnt_master;    /* 从安装链表的主人 */

    struct mnt_namespace *mnt_ns;    /* 相关的命名空间 */

    int mnt_id;            /* 安装标识符 */

    int mnt_group_id;        /* 组标识符 */

    /*

     * We put mnt_count & mnt_expiry_mark at the end of struct vfsmount

     * to let these frequently modified fields in a separate cache line

     * (so that reads of mnt_flags wont ping-pong on SMP machines)

     */

    atomic_t mnt_count;         /* 使用计数 */

    int mnt_expiry_mark;        /* 如果标记为到期，则为 True */

    int mnt_pinned;             /* "钉住"进程计数 */

    int mnt_ghosts;             /* "镜像"引用计数 */

#ifdef CONFIG_SMP

    int *mnt_writers;           /* 写者引用计数 */

#else

    int mnt_writers;            /* 写者引用计数 */

#endif

};

struct files_struct {

    atomic_t count;      /* 使用计数 */

    struct fdtable *fdt; /* 指向其他fd表的指针 */

    struct fdtable fdtab;/* 基 fd 表 */

    spinlock_t file_lock ____cacheline_aligned_in_smp; /* 单个文件的锁 */

    int next_fd;                                       /* 缓存下一个可用的fd */

    struct embedded_fd_set close_on_exec_init;         /* exec()时关闭的文件描述符链表 */

    struct embedded_fd_set open_fds_init;              /* 打开的文件描述符链表 */

    struct file * fd_array[NR_OPEN_DEFAULT];           /* 缺省的文件对象数组 */

};

struct fs_struct {

    int users;               /* 用户数目 */

    rwlock_t lock;           /* 保护结构体的读写锁 */

    int umask;               /* 掩码 */

    int in_exec;             /* 当前正在执行的文件 */

    struct path root, pwd;   /* 根目录路径和当前工作目录路径 */

};

/* filesystem information */

    struct fs_struct *fs;

/* open file information */

    struct files_struct *files;

/* namespaces */

    struct nsproxy *nsproxy;