Linux 虚拟文件系统 (VFS) 分析

关注

发布于: 4 小时前

我们知道在 Linux 系统中一切皆文件，如果说文件系统是 Linux 系统的基石一点也不过分。在 Linux 系统中基本上把其中的所有内容都看作文件，除了我们普通意义理解的文件之外，目录、字符设备、块设备、套接字、进程、线程、管道等都被视为是一个“文件”。例如对于块设备，我们通过 fdisk -l 显示块设备列表，其实块设备可以理解为在文件夹/dev 下面的文件。只不过这些文件是特殊的文件。

root@vmhost:~# ls /dev/ -alh |grep sdbrw-rw---- 1 root disk 8, 0 Dec 31 09:38 sdabrw-rw---- 1 root disk 8, 16 Dec 31 09:38 sdbbrw-rw---- 1 root disk 8, 32 Dec 31 09:38 sdc

复制代码

如上面代码所示，每个块设备的前面有一个字符串 brw-rw----，这个用于描述文件的属性，其中 b 字符表示这个文件是一个块设备，如果是 d 字符则表示是一个文件夹。同样，还有其它类型的设备也是一文件的形式进行表示的。那么 Linux 的文件系统要支持如此之多类型的文件是怎么做到的呢？那就是通过虚拟文件系统（Virtual File System 简称 VFS）。

虚拟文件系统总图

VFS 是一个抽象层，其向上提供了统一的文件访问接口，而向下则兼容了各种不同的文件系统。不仅仅是诸如 Ext2、Ext4、XFS 和 Btrfs 等常规意义上的文件系统，还包括伪文件系统和设备等等内容。由图 1 可以看出，虚拟文件系统位于应用与具体文件系统之间，其主要起适配的作用。对于应用程序来说，其访问的接口是完全一致的（例如 open、read 和 write 等），并不需要关系底层的文件系统细节。也就是一个应用可以对一个文件进行任何的读写，不用关心文件系统的具体实现。另外，VFS 实现了一部分公共的功能，例如页缓存和 inode 缓存等，从而避免多个文件系统重复实现的问题。

VFS 的存在可以让 Linux 操作系统实现非常复杂的文件系统关联关系。如图 2 所示，该系统根文件系统是 Ext3 文件系统，而在其/mnt 目录下面又分别挂载了 Ext4 文件系统和 XFS 文件系统。最后形成了一个由多个文件系统组成的文件系统树。

文件系统目录树

从 VFS 到具体文件系统

VFS 是一个抽象层，VFS 建立了应用程序与具体文件系统的联系，其提供了统一的访问接口实现对具体文件系统的访问（例如 Ext2 文件系统）。那么两者是怎么关联起来的呢？这里涉及如下几个处理流程：

挂载，也就是具体文件系统（例如 Ext2）的挂载
打开文件，我们在访问一个文件之前首先要打开它（open）
文件访问，进行文件的读写操作（read 或者 write）

其中第 1 个流程其实是建立 VFS 和诸如 Ext4 文件系统的关联，这样当用户在后面打开某个文件的时候，VFS 就知道应该调用那个文件系统的函数实现。而第 2 个流程则是初始化文件系统必要的数据结构和操作函数（例如 read 和 write 等），为后面的具体操作做准备。挂载的流程比较复杂，本文先概括的介绍一下，后续再做详细介绍。

挂载也是用户态发起的命令，就是我们知道的 mount 命令，该命令执行的时候需要指定文件系统的类型（本文假设 Ext2）和文件系统数据的位置（也就是设备）。通过这些关键信息，VFS 就可以完成 Ext2 文件系统的初始化，并将其关联到当前已经存在的文件系统中，也就是建立其图 2 所示的文件系统树。

本文不介绍代码细节，仅仅从数据结构方面介绍一下 Linux 文件系统挂载的具体原理。如图 3 是虚拟文件系统涉及的主要的数据结构。在挂载的过程中，最为重要的数据结构是 vfsmount，它代表一个挂载点。其次是 dentry 和 inode，这两个都是对文件的表示，且都会缓存在哈希表中以提高查找的效率。其中 inode 是对磁盘上文件的唯一表示，其中包含文件的元数据（管理数据）和文件数据等内容，但不含文件名称。而 dentry 则是为了 Linux 内核中查找文件方便虚拟出来的一个数据结构，其中包含文件名称、子目录（如果存在的话）和关联的 inode 等信息。

文件系统核心数据结构

这里面 dentry 结构体最为关键，其维护了内核中的文件目录树。其中里面比较重要的几个结构体分别是 d_name、d_hash 和 d_subdirs。其中 d_name 代表一个路径节点的名称（文件夹名称）、d_hash 则用于构建哈希表，d_subdirs 则是下级目录（或文件）的列表。这样，通过 dentry 就可以形成一个非常复杂的目录树。

dentry数据结构

其中 inode 是文件的唯一表示，其中除了包含元数据和数据的索引之外，还包含关键操作的函数指针。比如对于文件读写和属性更改等操作接口都存在该结构体中，具体如图 3 所示。这里面主要涉及 3 个结构体，分别是 address_space、inode_operations 和 file_operations，其中每一个结构体中都包含很多函数指针。

回到正题，所谓文件系统的挂载过程，其实就是构建上述几个结构体的过程，特别是 inode 结构体的初始化。以 Ext4 为例，在挂载的时候就会将其中的 address_space、inode_operations 和 file_operations 函数指针初始化为 Ext4 文件系统的函数。因此当对文件进行访问的时候，只要找到这个 inode，就能知道是什么类型的文件系统。

处理流程示例

我们都知道，在用户态打开一个文件是返回的是一个文件描述符，其实也就是一个整数值。同时，访问文件也是通过这个文件描述符进行的，如下面代码所示的函数原型。那么操作系统是怎么通过这个整数值实现不同类型文件系统的访问呢？前文我们知道不同文件系统的差异其实就是 inode 中初始化的函数指针的差异，因此问题的关键是这个文件描述符和 inode 是怎么关联起来的。

int fd = open（const char *pathname,int flags,mode_t mode）;ssize_t read(int fd, void * buf, size_t count);

复制代码

在 Linux 操作系统中，文件的打开必须要与进程（或者线程）关联，也就是说一个打开的文件必须隶属于某个进程。在 linux 内核当中一个进程通过 task_struct 结构体描述，而打开的文件则用 file 结构体描述，打开文件的过程也就是对 file 结构体的初始化的过程。在打开文件的过程中会将 inode 部分关键信息填充到 file 中，特别是文件操作的函数指针。在 task_struct 中保存着一个 file 类型的数组，而用户态的文件描述符其实就是数组的下标。这样通过文件描述符就可以很容易到找到 file，然后通过其中的函数指针访问数据。