大家好，我是本期栏目编辑小友，现在为大家讲解详解linux内核VFS问题。
虚拟文件系统(VFS)
在我看来，“虚”字主要有两层意思：
1、在同一个目录结构中，可以挂载几个不同的文件系统。VFS隐藏了它们的实现细节，并为用户提供了统一的界面。
2.目录结构本身不是绝对的，每个进程可能会看到不同的目录结构。目录结构用“地址空间”来描述。不同的进程可能有不同的名称空间，不同的名称空间可能有不同的目录结构(因为它们可能挂载不同的文件系统)。
操作打开的文件。
VFS的用户就是进程(用户总是需要启动进程才能访问文件系统)。描述进程的task_struct结构中的files指针指向files_struct结构，该结构描述进程的打开文件集合。
files_struct结构维护一个与打开的文件对应的文件结构的指针数组，数组的索引用作用户程序操作打开的文件的句柄(通常称为fd)。Files_struct还会维护已使用的fd位图，以便在需要打开文件时为其分配一个未使用的fd。
文件结构是一个打开的文件实例。用户通过fd操作打开的文件的过程相对简单。fd索引到相应的文件结构，然后在文件结构的f_op中执行相应的操作(如读、写)。
不同的文件结构可能有不同的f_op，因为它们的文件类型不同(例如，普通文件、套接字、fifo等)。).
并且在文件打开时会分配相应的f_op。对于打开的文件，只需要使用f_op中的函数，不需要判断文件是什么类型。然而，本文没有描述如何在f_op中实现具体的功能(实际上，这部分也非常复杂，参见《linux内核文件读写浅析》)。
当用户操作打开的文件时，f_op中的函数可能不会被调用，有些操作只涉及文件结构本身。例如，文件的当前位置(f_pos)保持在文件结构中，lseek系统调用只负责移动这个pos值。
f_pos和f_mode(文件访问模式)等属性存储在文件结构中，这意味着这些属性都与打开的文件的实例相关。一个文件可以打开多个实例(在一个或多个进程中)，每个实例中的这些值可能不同。
例如，两个进程同时打开同一个文件进行读取。因为对应于两个实例(文件结构)的f_pos不同，所以这两个读取操作不会相互影响。
有时，多个进程会共享同一个打开的文件实例。使用clone系统调用创建子进程时，如果设置了CLONE_FILES标志，父进程和子进程将共享files_struct结构，从而共享所有打开的文件实例。多线程就是一个典型的例子。
打开文件
与打开文件的简单操作相比，打开文件的过程非常复杂。从上图可以看出，操作打开的文件只占用少量空间，而其他内容都与打开文件有关。
要打开一个文件，首先需要文件路径，比如“dir0/dir1/file”。此路径被“/”分成多个级别，每个级别都是一个文件(目录也是文件，如dir0和dir1)。
在开始寻找这个文件路径时，我们需要一个起点。如果文件路径以“/”开头，则从根目录开始。否则，以当前路径为起点。
这两个可能的起始点存储在与进程的task_struct相对应的fs_struct结构中。每个文件在目录结构中用一个dentry结构表示，而“起点”本身也是一个dentry结构。
当我们在shell中执行cd命令时，我们实际上改变了表示fs_struct结构中当前路径的dentry。
你也可以用ch。
root系统调用来改变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
标签：
版权声明：转载此文是出于传递更多信息之目的。若有来源标注错误或侵犯了您的合法权益，请作者持权属证明与本网联系，我们将及时更正、删除，谢谢您的支持与理解。