您的位置:首页 > 运维架构 > Linux

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

2017-04-17 21:03 411 查看

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

tags: Linux源码

Linux 虚拟文件系统二MountOpen设备文件挂载和打开文件
梗概

挂载
设备文件

设备文件从哪里来的

挂载做了什么

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

打开文件实际情况

请结合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
,下面来分析一下打开该文件的过程 :

虚拟文件系统将
/home/片/艳照门1.png
分割为
/
home
艳照门1.png
,然后试图从左到右去目录项缓存中找能匹配尽可能深一点的目录的
detry
实例,也就是说找到
detry
实例比找到
home
更好,因为
距离要读的目标文件更近一些。由于刚刚执行过挂在操作
目录对应的
detry
实例应该存在于目录项缓存中。

虚拟文件系统检查返回的
detry
的实例的
d_mount
是否为0,

2.1 如果为0的话说明没有其他设备挂载在该
detry
实例上,返回该实例。

2.2 如果不为0的话说明有其他设备挂载在该
detry
实例上面,需要借助上图的数据结构找到被挂在设备的根目录的
detry
实例。

本情景中的
对应的
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
视图为



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

打开文件实际情况

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

上文刚刚讨论的过程指定是发生在内核态的,怎样从用户态的一个系统调用到达内核态的函数实现,这虽然是系统调用模块的任务,但是还是需要虚拟文件系统按照系统调用模块的要求,配置好系统调用表完成优先级的转变的。

上文中没有提及
struct file
结构体,实际上一个文件的读写请求的发出者都是一个进程,所以记录进程打开的所有的文件、某个文件的打开状态、某个文件当前的读写指针这些操作都是要和
file
结构体打交道的。

上文忽略了权限检查的过程,这个过程当然也是有虚拟文件系统实现的。不过需要注意的是如果实际的文件系统想要实现自己的权限检查机制,就应该按照虚拟文件系统框架的要求实现特定的函数并在注册文件系统的时候告诉虚拟文件系统。

处理
.
..
和比较复杂的文件路径,譬如
/home/../jiangjinhao/./../jiangjinhao/片/./艳照门1.png
这样的路径虽然看似无理取闹但是却是一个正确的路径。

处理符号连接。

解决多进程读写文件的冲突,保证并发的正确性。

锁机制和一些其他的边边角角的情况。

请结合Linux内核情景分析

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





声明

文中引用都已超链接的形式给出了来源,如有侵权即可删除。
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息