在我看来, "虚拟"二字主要有两层含义:html
1, 在同一个目录结构中, 能够挂载着若干种不一样的文件系统. VFS隐藏了它们的实现细节, 为使用者提供统一的接口;node
2, 目录结构自己并非绝对的, 每一个进程可能会看到不同的目录结构. 目录结构是由"地址空间(namespace)"来描述的, 不一样的进程可能拥有不一样的namespace, 不一样的namespace可能有着不一样的目录结构(由于它们可能挂载了不一样的文件系统).linux
操做已打开的文件shell
VFS的使用者是进程(用户访问文件系统老是须要启动进程). 描述进程的task_struct结构中files指针指向了一个files_struct结构, 后者描述了进程已打开的文件集合.数组
files_struct结构维护了一个已打开文件所对应的file结构的指针数组, 数组下标被用做用户程序操做已打开文件的句柄(一般称做fd). files_struct还维护着已使用的fd位图, 以便在须要打开文件时, 为其分配一个未使用的fd.缓存
file结构是一个已打开文件实例. 用户程序经过fd操做一个已打开文件的过程比较简单, 由fd索引到对应的file结构, 再执行file结构的f_op中对应的操做便可(好比read, write).数据结构
不一样的file结构可能拥有不一样的f_op, 由于它们的文件类型不一样(好比, 普通文件, socket, fifo, 等等).多线程
而这个对应的f_op是在文件打开时被赋值的, 对于已打开的文件, 只管使用f_op中的函数便可, 不用再判断到底这个文件是什么类型. 而至于具体的f_op中的函数是如何实现的, 本文不做描述(实际上这一部分也是很复杂的, 参见<linux内核文件读写浅析>).socket
用户程序操做一个已打开的文件也未必就会调用到f_op中的函数, 有些操做是只涉及file结构自己的. 好比file结构中维护了文件的当前位置(f_pos), lseek系统调用只负责移动这个pos值.函数
相似f_pos, f_mode(文件的访问模式), 等这样的属性, 是存放在file结构中的, 这意味着这些属性都是跟一个已打开文件的实例相关的. 一个文件可能会打开多个实例(在一个或多个进程中), 每一个实例中的这些值都有可能不一样.
好比, 两个进程同时打开同一个文件, 进行读操做. 因为两个实例(file结构)对应的f_pos不一样, 两个读操做互不影响.
而有时候多个进程也会共享同一个打开文件实例, 当使用clone系统调用建立子进程时, 若是设置了CLONE_FILES标志, 则父子进程将共享files_struct结构, 从而共享所有已打开的文件实例. 典型的例子是多线程.
打开文件
相比于对已打开文件的操做的简单, 打开一个文件的过程倒是很复杂的. 从上面的图中也能够看出, 操做已打开的文件只占了不多的篇幅, 而其余的内容则都与打开文件有关.
要打开一个文件, 首先须要文件路径, 如"dir0/dir1/file". 这个路径被'/'拆分红多级, 每一级都是一个文件(目录也是文件, 如dir0, dir1).
在寻找这个文件路径的一开始, 咱们须要一个起点. 若是文件路径以'/'开头, 则以根目录为起点; 不然以当前路径为起点.
这两个可能的起点都保存在进程的task_struct所对应的fs_struct结构中. 每一个文件在目录结构中由目录项(dentry)结构来表示, "起点"自己也是一个dentry结构.
咱们在shell中执行cd命令时, 实际上就是改变了fs_struct结构中表明当前路径的那个dentry.
进程也能够经过chroot系统调用来改变fs_struct结构中表明根路径的那个dentry. 这样一来, 这个dentry之上的那些路径对该进程将不可见.
做为文件的索引结构, 若干dentry描绘了一个树型的目录结构, 这就是用户所看到的目录结构. (咱们暂且将其称为dentry树.)
每一个dentry指向一个索引节点(inode)结构, 后者才是实际描述这个文件信息的结构. 而多个dentry能够指向同一个inode, 这样就实现了link.
dentry中实现了一组方法(d_op), 主要是用于匹配子节点. dentry实现了一个散列表, 以便于查找子节点.
d_op可能随文件系统类型的不一样而不一样, 好比, 散列方法可能不一样, 节点的匹配方法也可能不一样(有的文件系统文件名大小写敏感, 有的则不).
寻找文件路径的过程就是在这个dentry树中不断查找子dentry, 直到找到路径中的最后一个dentry的过程.
虽然dentry树描绘了文件系统的目录结构, 可是, 这些dentry结构并非常驻内存的. 整个目录结构可能会很是大, 以至于内存根本装不下.
初始状态下, 系统中只有表明根目录的dentry和它所指向的inode(这是在根文件系统挂载时生成的, 见下文). 此时要打开一个文件, 文件路径中对应的节点都是不存在的, 根目录的dentry没法找到须要的子节点(它如今尚未子节点). 这时候就要经过inode->i_op中的lookup方法来寻找须要的inode的子节点(这每每是经过特定的文件系统类型定义的方法, 从文件系统存储介质中去查找的。参见《linux文件系统实现浅析》), 找到之后(此时inode已被载入内存), 再建立一个dentry与之关联上.
由这一过程可见, 实际上是先有inode再有dentry. inode自己是存在于文件系统的存储介质上的, 而dentry则是在内存中生成的. dentry的存在加速了对inode的查询.
既然整个目录结构可能不能所有载入内存, 在内存中生成的dentry将在无人使用时被释放. d_count字段记录了dentry的引用计数, 引用为0时, dentry将被释放.
这里所谓的释放dentry并非直接销毁并回收, 而是将dentry放入一个"最近最少使用(LRU)"队列(与对应的超级块相关联). 当队列过大, 或系统内存紧缺时, 最近最少使用的一些dentry才真正被释放.
这个LRU队列就像是一个缓存池, 加速了对重复的路径的访问. 而当dentry被真正释放时, 它所对应的inode将被减引用. 若是引用为0, inode也被释放.
当寻找一个文件路径时, 对于其中经历的每个节点, 有三种状况:
1, 对应的dentry引用计数还没有减为0, 它们还在dentry树中, 直接使用便可;
2, 若是对应的dentry不在dentry树中, 则试图从LRU队列去寻找. LRU队列中的dentry同时被散列到一个散列表中, 以便查找. 查找到须要的dentry后, 这个dentry被从LRU队列中拿出来, 从新添加到dentry树中;
3, 若是对应的dentry在LRU队列中也找不到, 则只好去文件系统的存储介质里面查找inode了. 找到之后dentry被建立, 并添加以dentry树中;
文件系统挂载
VFS容许多种不一样的文件系统挂载在同一个目录结构中, 文件系统挂载的路径称为挂载点.
如, 磁盘有两个分区A和B, A做为根文件系统被挂载在"/"路径下, 而B做为A的子文件系统, 挂载在"/mnt/B/"下.
要完成这一挂载, A文件系统中必须有"/mnt/"这个目录. 而无论A中有没有"/mnt/B", 都会生成一个dentry与之对应, 可是这个dentry并不对应A中的"/mnt/B"所对应的inode(即便这个inode存在). 这个dentry中的d_mounted标记被置位, 表示这是一个挂载点.
若是在寻找文件路径的过程当中遇到这样的一个挂载点, 则表明当前路径的指针将从当前dentry切换到挂载的文件系统的"/"所对应的dentry. 便是说, 访问A分区中的"/mnt/B"这个路径时, 实际访问到的是B分区中的"/"路径.
文件系统使用vfsmount结构来描述, 多个挂载的文件系统也被组织成树型结构.
vfsmount结构中有两个指向dentry的指针, mnt_mountpoint指向其父文件系统的挂载点dentry(例如A分区中的"/mnt/B"), 而mnt_root指向本文件系统的根路径dentry(例如B分区中的"/"). 经过这两个指针, 能够完成上面提到的当前路径的切换.
因而, 寻找文件路径的过程当中, 除了要记录当前dentry, 还要记录当前vfsmount. 若是当前dentry是一个挂载点, 则经过当前vfsmount, 找到其儿子中挂载点为当前dentry的子vfsmount, 而后获得这个子vfsmount的mnt_root.
可能会有多个vfsmount都挂载在同一个dentry上, 这时候, 只有其中一个vfsmount会被选中, 而其余vfsmount将被隐藏. 直到被选中的那个vfsmount被卸载后, 被隐藏的vfsmount才可能被选中. 利用这个特色, 咱们能够实现目录的隐藏. 好比/home/kouu/secret下保存着一些不但愿别人看到的文件, 能够在这个目录上mount一下tmpfs, 以达到隐藏的目的.
子文件系统老是被挂载在父文件系统的某个dentry上, 而根文件系统则是由mnt_namespace对象来引用的. 不一样的mnt_namespace能够引用不一样的根文件系统, 组织不一样的文件系统挂载树, 造成不一样的目录结构.
通常而言, 新建立的进程老是与其父进程共用mnt_namespace. 而全部进程都是1号进程(init)的子孙进程, 则通常状况下全部进程都使用相同的mnt_namespace, 都生活在相同的目录结构中.
可是在经过clone系统调用建立新进程时, 能够指定CLONE_NEWNS标志, 为子进程建立新的名字空间(其中就包含了mnt_namespace, 此外名字空间还有其余内容).
前面只是说某个设备被挂载, 其实挂载文件系统除了要添加相应的存储介质的设备文件, 还要在内核中注册文件系统类型(对应file_system_type结构)(如ext2, ext3, tmpfs). 一个文件系统老是包含设备和类型两个要素的.
已注册file_system_type被存储在链表结构中, 经过它们注册的名字(好比ext3)来找到它们. 它们是文件数据的解释器, 解释设备文件所对应的物理存储介质中的数据.
每一个文件系统都有一个超级块(对应super_block结构), 这个超级块经过file_system_type结构的get_sb方法从块设备中读出来.
而一个文件系统能够被挂载屡次, 造成多个vfsmount结构. 它们都对应同一个super_block. 实际上只有文件系统第一次被挂载时, 才会去读它的super_block. 不然这个super_block已是存在的, 直接引用便可.
在get_sb的过程当中, 这个文件系统的根路径所对应的inode也会从存储介质中载入, 并建立对应的dentry. super_block->s_root就指向根路径的dentry.
数据结构总结
最后, 咱们对上面的一些数据结构及其函数指针集合进行一下整理, 这些东西实在容易让人找不着北.
file_system_type
含义: 文件系统类型, 如ext2, ext3, 等等
建立: 内核启动或内核模块加载时, 为每一种文件系统类型建立一个对应的file_system_type结构
函数: get_sb, 获取超级块的方法. 在注册文件系统类型时提供
super_block
含义: 超级块, 对应一个存储文件的设备
建立: 文件系统挂载时, 经过对应的file_system_type->get_sb从设备中读取, 并初始化(可见, super_block结构中一部分信息是保存在设备中的, 一部分则是在内在中初始化的)
函数: s_op, 超级块的函数集, 主要包含对索引节点和文件系统实例的操做. file_system_type->get_sb从设备中读取超级块后, 用file_system_type对应的特定函数集进行初始化
inode
含义: 索引节点, 对应设备上存放的一个文件
建立: 1)在超级块被载入时, 做为根的inode一并被载入; 2)经过mknod调用创新新的索引节点; 3)在寻找文件路径的过程当中, 从设备中读取, 并初始化(跟super_block同样, inode结构中一部分信息是保存在设备中的, 一部分则是在内在中初始化的)
函数: i_op, 索引节点函数集, 主要包含对子inode的建立, 删除等操做. f_op, 文件函数集, 主要包含对本inode的读写等操做. 在inode被建立后, 1)若是是特殊文件, 则根据对应文件的类型(包括块设备, 字符设备, fifo, 等等)赋予特定的函数集(并不直接与设备和文件系统类型相关); 2)不然, 对应的文件系统类型会提供相应的函数集, 而且目录和文件函数集极可能不一样
dentry
含义: 目录项, 寻找文件路径的过程当中使用的树型结构, 与inode关联
建立: inode被建立后, dentry就要被建立并初始化
函数: d_op, 目录项函数集, 主要包含对子dentry的查询操做. 由文件系统类型肯定
file
含义: 打开文件的实例
建立: 在open调用时建立, 并与一个inode对应
函数: f_op, 文件读写等操做. 1)等于inode->f_op, 对于普通文件, 块设备文件, 等; 2)由inode->f_op->open函数在文件打开时指定, 典型的状况是字符设备. 全部字符设备具备相同的inode->f_op, 在inode->f_op->open过程当中, 找到对应设备驱动注册的f_op, 赋给file->f_op
摘自kouu's home
来自：http://www.2cto.com/os/201110/108845.html