Linux 虚拟文件系统(二)Mount、Open；设备文件、挂载和打开文件

Linux 虚拟文件系统(二)Mount、Open；设备文件、挂载和打开文件

---

tags: Linux源码

---

梗概

文中不陷入过多的代码之中，尽量尝试从原理上面说明挂载和打开文件要做的事情，所以这篇文章应该作为阅读Linux内核情景分析、深入Linux内核架构的前序文章，而且要尽可能地读一读源码。文中讨论的Linux内核版本为2.6.24。本人联系方式jiangjinhao@vip.qq.com，欢迎探讨。

挂载

要想说明白虚拟文件系统文件打开时究竟做了哪些事，绕不开的一个话题就是挂载，正是挂载和开打文件之间的默契协作，奠定了虚拟文件系统的基石–灵活的安装一个文件系统。在文章Linux虚拟文件系统(一)概述中出于行文的原因简单的提到了挂载在虚拟文件系统中的作用，通过挂载可以让操作系统(虚拟文件系统)知道一个物理设备使用的是什么文件系统，从而能够去读取解析物理设备上面的数据。但是挂载操作中有一个参数被挂载的设备比较特殊，上篇文章由于篇幅原因没有展开。这里的被挂载的设备是以设备文件的形式给出的。

设备文件

设备文件没有什么神奇的，它其实就是一个文件了。只不过它在磁盘空间中只占用一个目录项并不包含实际的数据，目录项中的一些字段可以指明该目录项对应的是一个文件还是一个设备文件。虚拟文件系统默认知道设备文件不包括实际的数据，只是用来表示一个文件。设备文件的存在并不是必须的，这是个设计的结果，大可以不使用设备文件来表示计算机系统中的一个硬件。内核设计者发现硬件设备之间存在着层次关系、存在着一些权限的限制，试想一个成熟的文件系统的抽象结构不也就是一颗有着层级关系的多叉树么、要想读写树的节点也需要满足一些权限的限制。硬件设备之间的关系不正是一个文件系统致力解决的问题么，由此这才引入了设备文件的概念。由于设备文件就代表一个物理设备，所以想要对一个设备做的事情，就可以通过对设备文件的操作表现出来的:譬如挂载、创建分区、格式化磁盘。至于设备文件是如何表示一个设备的，读者可以从其他相关博客和书籍上了解到，这里就不赘述了。
需要注意的是，通过上文的讨论可以知道，如果一个文件系统的目录项中没有足够的字段用来表示这是一个特殊的文件(设备文件)，那么这个文件系统中是不可以存储设备文件的，使用很广泛的FAT文件系统就是不支持设备文件的。

设备文件从哪里来的

设备文件大多数都保存在/dev目录下面。用户可以使用mknod在指定的目录中创建设备文件。现阶段的/dev是基于内存的文件系统，如果运行mount命令可以看到

$ mount
......
udev on /dev type devtempfs(rw,mode=0755)
......

udev表示一个设备，这是一个虚拟的设备；/dev表示被挂载点；devtempfs表示挂载使用的文件系统。

(以前)/dev中的设备节点一般是在基于磁盘的文件系统中静态创建的，随着支持的设备越来越多，必须安置和管理越来越多的项，且其中的大多数项是不必要的。因此几乎所有的Linux发布版都使用了基于磁盘的tempfs作为/dev的文件系统，管理工作交付给一个守护进程udevd，允许从用户态动态创建设备文件。udev模拟了一个设备，挂在到了跟文件系统的/dev目录上，这也就是为什么可以用mount命令看到上面展示的一项。
在内核启动的过程中会检测计算机系统中所有可用的设备，每当内核检测到一个设备，就在/dev中对应的位置创建一个目录项。系统启动之后在运行期间如果有新的设备插入，硬件产生的热拔插中断消息会通知内核创建对应的目录项。正是这些机制才使得能够在/dev下看到那许许多多的设备文件。

挂载做了什么

有了上一篇文章的铺垫和对设备文件的理解，是时候更详细的讨论挂载的过程了。我们还是使用上篇文章中的一个情景 : 用户想要查看磁盘A上的艳照门1.png，所以用户以极简文件系统挂载磁盘A到/home/片下面，然后读取文件/home/片/艳照门1.png。在执行挂载操作之前，从detry和vsfmount的视角看到的此时的内存数据结构关系为

目录树结构是使用d_child孩子指针和d_subdirs兄弟指针建立的；图中的箭头都是表示是一个指针；其中的数据结构已在上篇文章中给出了较好的分析。
在执行了挂载操作之后数据结构关系为

挂载操作所做的事情也就不外乎建立了如上图示的数据结构。可以看出，ext2文件系统和极简文件系统之间的关系是依靠两个vfsmount建立起来的；mnt_root指向被挂在设备的根目录；mnt_hash是为了加速子vfsmount查找而建立的；挂载点片的detry中的字段d_mount执行了加一的操作，如果一个detry的d_mount!=0表示这个目录被挂载了。还需要注意的是一同创建的还有极简文件系统根目录的inode，只不过在图中没有表示出来，在内存中找到一个目录的detry必然能找到其对应的inode。更详细的挂载的过程还是推荐mount过程分析之六——挂载关系(图解)这篇文章。

打开文件

打开文件和挂载的巧妙结合

上文也说过，挂载和文件的打开过程的协作才是虚拟文件系统的精髓所在。顺着上文的情景继续往下看，在挂载完之后用户试图访问/hone/片/艳照门1.png，下面来分析一下打开该文件的过程 :

1. 虚拟文件系统将/home/片/艳照门1.png分割为/、home、片、艳照门1.png，然后试图从左到右去目录项缓存中找能匹配尽可能深一点的目录的detry实例，也就是说找到片的detry实例比找到home更好，因为片距离要读的目标文件更近一些。由于刚刚执行过挂在操作片目录对应的detry实例应该存在于目录项缓存中。
2. 虚拟文件系统检查返回的detry的实例的d_mount是否为0，
   2.1 如果为0的话说明没有其他设备挂载在该detry实例上，返回该实例。
   2.2 如果不为0的话说明有其他设备挂载在该detry实例上面，需要借助上图的数据结构找到被挂在设备的根目录的detry实例。
3. 本情景中的片对应的detry的实例是一个挂载点，虚拟文件系统顺藤摸瓜找到极简文件系统的根目录的detry实例片_detry、inode实例片_inode， 一定要注意这两个数据结构的实例是在挂载的时候生成的，磁盘A上面并没有一个叫做/的目录项 ! 生成一个磁盘上面没有的目录项的detry、inode实例的目的就是实现查找的过程中从ext2文件系统到极简文件系统的切换。在生成这两个实例的时候，虚拟文件系统的实现会对极简文件系统注册的极简_look_up、极简_read_page执行如下操作:

//这就是**解析目录项的函数**
片_inode -> inode_operations -> look_up = 极简_look_up; 

片_inode -> address_space -> address_space_operations -> read_page = 极简_read_page;
//极简_read_page的实现通常为下面的样子
static int 极简_readpage(struct file *file, struct page *page)
{
    return mpage_readpage(page, 极简_get_block);
}                                 

这个极简_get_block是一个函数指针，就是千呼万唤始出来的文件相对块号到磁盘逻辑块号映射的函数。mpage_readpage是虚拟文件系统提供的通用的以页为单位读磁盘的函数，其中实现了缓存、预读、权限检测、页块转换等逻辑，需要的时候会调用以指针的形式传进去的极简_get_block函数。也就相当于极简文件系统主要实现了实现了极简_look_up和极简_get_block这两个主要的函数，这两点也正是上篇文章一再强调的虚拟文件系统和实际文件系统交互的最重要的两个方面。
4. 接下来尝试去目录项缓存中寻找艳照门1.png，由于之前没有读取过，这个时候的寻找缓存应该是无果的。虚拟文件系统就会调用inode中的look_up函数，也就是使用实际的文件系统的逻辑来解析目录项。look_up函数返回艳照门1.png对应的inode、detry实例。此时的detry、inode视图为

到此打开文件所做的事情基本上完成了，需要注意的是并不是要读写文件就必须要经历一个所谓的打开文件这样的过程，大可以不要这个过程，把其实际做的工作放到第一次读写文件的时候，这完全是一个设计的问题。

打开文件实际情况

刚刚只是以尽可能容易理解的方式说明了打开文件所做的事情，实际上打开文件要做的事情更多也更复杂。

1. 上文刚刚讨论的过程指定是发生在内核态的，怎样从用户态的一个系统调用到达内核态的函数实现，这虽然是系统调用模块的任务，但是还是需要虚拟文件系统按照系统调用模块的要求，配置好系统调用表完成优先级的转变的。
2. 上文中没有提及struct file结构体，实际上一个文件的读写请求的发出者都是一个进程，所以记录进程打开的所有的文件、某个文件的打开状态、某个文件当前的读写指针这些操作都是要和file结构体打交道的。
3. 上文忽略了权限检查的过程，这个过程当然也是有虚拟文件系统实现的。不过需要注意的是如果实际的文件系统想要实现自己的权限检查机制，就应该按照虚拟文件系统框架的要求实现特定的函数并在注册文件系统的时候告诉虚拟文件系统。
4. 处理.、..和比较复杂的文件路径，譬如/home/../jiangjinhao/./../jiangjinhao/片/./艳照门1.png这样的路径虽然看似无理取闹但是却是一个正确的路径。
5. 处理符号连接。
6. 解决多进程读写文件的冲突，保证并发的正确性。
7. 锁机制和一些其他的边边角角的情况。

请结合Linux内核情景分析

到这个位置结合源代码深入分析打开机制是再合适不过的了，不过不认为自己能够写的比Linux内核情景分析好，不敢妄自企及。但是Linux内核情景分析的代码线拉的比较深，容易在看的时候摸不清头脑所以下面给出了系统调用sys_open的主要流程图。第一张图介绍了基本的工作，第二张图为打开文件的核心函数其完成了绝大多数的任务。希望这两张流程图在读者读书或者看代码的时候能够给予帮助，不至于迷失在代码之中。(第二张图有点大，可以下载下来看)

---

声明

文中引用都已超链接的形式给出了来源，如有侵权即可删除。