http://www.cnblogs.com/zsw-1993/p/5048144.html
在我看来, "虚拟"二字主要有两层含义:
1, 在同一个目录结构中, 可以挂载着若干种不同的文件系统. VFS隐藏了它们的实现细节, 为使用者提供统一的接口;
2, 目录结构本身并不是绝对的, 每个进程可能会看到不一样的目录结构. 目录结构是由"地址空间(namespace)"来描述的, 不同的进程可能拥有不同的namespace, 不同的namespace可能有着不同的目录结构(因为它们可能挂载了不同的文件系统).
操作已打开的文件
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内核文件读写浅析>).
用户程序操作一个已打开的文件也未必就会调用到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