Linux 虚拟文件系统(VFS)分析
概述
本文将介绍一下Linux的VFS虚拟机文件系统，主要介绍该文件系统在Linux中的作用及概要实现。我们知道在Linux系统中一切皆文件，如果说文件系统是Linux系统的基石一点也不过分。在Linux系统中基本上把其中的所有内容都看作文件，除了我们普通意义理解的文件之外，目录、字符设备、块设备、 套接字、进程、线程、管道等都被视为是一个“文件”。例如对于块设备，我们通过fdisk -l显示块设备列表，其实块设备可以理解为在文件夹/dev下面的文件。只不过这些文件是特殊的文件。
aaa@qq.com:~# ls /dev/ -alh |grep sd brw-rw---- 1 root disk 8, 0 Dec 31 09:38 sda brw-rw---- 1 root disk 8, 16 Dec 31 09:38 sdb brw-rw---- 1 root disk 8, 32 Dec 31 09:38 sdc
如上面代码所示，每个块设备的前面有一个字符串brw-rw----，这个用于描述文件的属性，其中b字符表示这个文件是一个块设备，如果是d字符则表示是一个文件夹。同样，还有其它类型的设备也是一文件的形式进行表示的。那么Linux的文件系统要支持如此之多类型的文件是怎么做到的呢？那就是通过虚拟文件系统（Virtual File System简称VFS）。
图1 虚拟文件系统总图
VFS是一个抽象层，其向上提供了统一的文件访问接口，而向下则兼容了各种不同的文件系统。不仅仅是诸如Ext2、Ext4、XFS和Btrfs等常规意义上的文件系统，还包括伪文件系统和设备等等内容。由图1可以看出，虚拟文件系统位于应用与具体文件系统之间，其主要起适配的作用。对于应用程序来说，其访问的接口是完全一致的（例如open、read和write等），并不需要关系底层的文件系统细节。也就是一个应用可以对一个文件进行任何的读写，不用关心文件系统的具体实现。另外，VFS实现了一部分公共的功能，例如页缓存和inode缓存等，从而避免多个文件系统重复实现的问题。
VFS的存在可以让Linux操作系统实现非常复杂的文件系统关联关系。如图2所示，该系统根文件系统是Ext3文件系统，而在其/mnt目录下面又分别挂载了Ext4文件系统和XFS文件系统。最后形成了一个由多个文件系统组成的文件系统树。
图2 文件系统目录树
从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等信息。
图3 文件系统核心数据结构
这里面dentry结构体最为关键，其维护了内核中的文件目录树。其中里面比较重要的几个结构体分别是d_name、d_hash和d_subdirs。其中d_name代表一个路径节点的名称（文件夹名称）、d_hash则用于构建哈希表，d_subdirs则是下级目录（或文件）的列表。这样，通过dentry就可以形成一个非常复杂的目录树。
图4 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，然后通过其中的函数指针访问数据。
图5 进程与文件
例如我们以Ext2文件系统的写数据为例，在调用用户态的写数据接口的时候，需要传入文件描述符。内核根据文件描述符找到file，然后调用函数接口（file->f_op->write）文件磁盘数据。其中file结构体的f_op指针就是在打开文件的时候通过inode初始化的。
图6 Ext2写数据流程
本文先简要介绍一下VFS的原理及如何与具体文件系统的关系。后续文章再逐个部件进行深入的剖析。