解析Linux中的VFS文件系统机制（下）

　　5. VFS 下目录的建立
　　
　　为了更好地理解 VFS，下面我们用一个实际例子来看看 Linux 是如何在 VFS 的根目录下建立一个新的目录 "/dev" 的。
　　
　　要在 VFS 中建立一个新的目录，首先我们得对该目录进行搜索，搜索的目的是找到将要建立的目录其父目录的相关信息，因为"皮之不存，毛将焉附"。比如要建立目录 /home/ricard，那么首先必须沿目录路径进行逐层搜索，本例中先从根目录找起，然后在根目录下找到目录 home，然后再往下，便是要新建的目录名 ricard，那么前面讲得要先对目录搜索，在该例中便是要找到 ricard 这个新目录的父目录，也就是 home 目录所对应的信息。
　　
　　当然，如果搜索的过程中发现错误，比如要建目录的父目录并不存在，或者当前进程并无相应的权限等等，这种情况系统必然会调用相关过程进行处理，对于此种情况，本文略过不提。
　　
　　Linux 下用系统调用 sys_mkdir 来在 VFS 目录树中增加新的节点。同时为配合路径搜索，引入了下面一个数据结构：
　　
　　struct nameidata {
　　struct dentry *dentry;
　　struct vfsmount *mnt;
　　struct qstr last;
　　unsigned int flags;
　　int last_type;
　　};
　　
　　这个数据结构在路径搜索的过程中用来记录相关信息，起着类似"路标"的作用。其中前两项中的 dentry记录的是要建目录的父目录的信息，mnt 成员接下来会解释到。后三项记录的是所查找路径的最后一个节点(即待建目录或文件)的信息。 现在为建立目录 "/dev" 而调用 sys_mkdir("/dev", 0700)，其中参数 0700 我们不去管它，它只是限定将要建立的目录的某种模式。sys_mkdir 函数首先调用 path_lookup("/dev", LOOKUP_PARENT, &nd)；来对路径进行查找，其中 nd 为 struct nameidata nd 声明的变量。在接下来的叙述中，因为函数调用关系的繁琐，为了突出过程主线，将不再严格按照函数的调用关系来进行描述。
　　
　　path_lookup 发现 "/dev" 是以 "/" 开头，所以它从当前进程的根目录开始往下查找，具体代码如下：
　　
　　nd->mnt = mntget(current->fs->rootmnt);
　　nd->dentry = dget(current->fs->root);
　　
　　记得在 init_mount_tree() 函数的后半段曾经将新建立的 VFS 根目录相关信息记录在了 init_task 进程的进程数据块中，那么在这个场景里，nd->mnt 便指向了图 3 中 mnt 变量，nd->dentry 便指向了图 3 中的 dentry 变量。
　　
　　然后调用函数 path_walk 接着往下查找，找到最后通过变量 nd 返回的信息是 nd.last.name="dev"，nd.last.len=3，nd.last_type=LAST_NORM，至于 nd 中 mnt 和 dentry 成员，在这个场景里还是前面设置的值，并无变化。这样一圈下来，只是用 nd 记录下相关信息，实际的目录建立工作并没有真正展开，但是前面所做的工作却为接下来建立新的节点收集了必要的信息。
　　
　　好，到此为止真正建立新目录节点的工作将会展开，这是由函数 lookup_create 来完成的，调用这个函数时会传入两个参数：lookup_create(&nd, 1)；其中参数 nd 便是前面提到的变量，参数1表明要建立一个新目录。
　　
　　这里的大体过程是：新分配了一个 struct dentry 结构的内存空间，用于记录 dev 目录所对应的信息，该dentry 结构将会挂接到其父目录中，也就是图 3 中 "/" 目录对应的 dentry 结构中，由链表实现这一关系。接下来会再分配一个 struct inode 结构。Inode 中的 i_sb 和 dentry 中的 d_sb 分别都指向图 3 中的 sb，这样看来，在同一文件系统下建立新的目录时并不需要重新分配一个超级块结构，因为毕竟它们都属于同一文件系统，因此一个文件系统只对应一个超级块。
　　
　　这样，当调用 sys_mkdir 成功地在 VFS 的目录树中新建立一个目录 "/dev" 之后，在图 3 的基础上，新的数据结构之间的关系便如图 4 所示。图 4 中颜色较深的两个矩形块 new_inode 和 new_entry 便是在sys_mkdir() 函数中新分配的内存结构，至于图中的 mnt,sb,dentry,inode 等结构，仍为图 3 中相应的数据结构，其相互之间的链接关系不变(图中为避免过多的链接曲线，忽略了一些链接关系，如 mnt 和 sb,dentry之间的链接，读者可在图 3 的基础上参看图 4)。
　　
　　需要强调一点的是，既然 rootfs 文件系统被 mount 到了 VFS 树上，那么它在 sys_mkdir 的过程中必然会参与进来，事实上在整个过程中，rootfs 文件系统中的 ramfs_mkdir、ramfs_lookup 等函数都曾被调用过。
　　

　

　　　　　　　　　　图 4: 在 VFS 树中新建一目录 "dev"
　　
　　6. 在 VFS 树中挂载文件系统
　　
　　在本节中，将描述在 VFS 的目录树中向其中某个目录(安装点 mount point)上挂载(mount)一个文件系统的过程。
　　
　　这一过程可简单描述为：将某一设备(dev_name)上某一文件系统(file_system_type)安装到VFS目录树上的某一安装点(dir_name)。它要解决的问题是：将对 VFS 目录树中某一目录的操作转化为具体安装到其上的实际文件系统的对应操作。比如说，如果将 hda2 上的根文件系统(假设文件系统类型为 ext2)安装到了前一节中新建立的 "/dev" 目录上(此时，"/dev" 目录就成为了安装点)，那么安装成功之后应达到这样的目的，即：对 VFS 文件系统的 "/dev" 目录执行 "ls" 指令，该条指令应能列出 hda2 上 ext2 文件系统的根目录下所有的目录和文件。很显然，这里的关键是如何将对 VFS 树中 "/dev" 的目录操作指令转化为安装在其上的 ext2 这一实际文件系统中的相应指令。所以，接下来的叙述将抓住如何转化这一核心问题。在叙述之前，读者不妨自己设想一下 Linux 系统会如何解决这一问题。记住：对目录或文件的操作将最终由目录或文件所对应的 inode 结构中的 i_op 和 i_fop 所指向的函数表中对应的函数来执行。所以，不管最终解决方案如何，都可以设想必然要通过将对 "/dev" 目录所对应的 inode 中 i_op 和 i_fop 的调用转换到 hda2 上根文件系统 ext2 中根目录所对应的 inode 中 i_op 和 i_fop 的操作。
　　
　　初始过程由 sys_mount() 系统调用函数发起，该函数原型声明如下：
　　
　　asmlinkage long sys_mount(char * dev_name, char * dir_name, char * type,
　　unsigned long flags, void * data);
　　
　　其中，参数 char *type 为标识将要安装的文件系统类型字符串，对于 ext2 文件系统而言，就是"ext2"。参数 flags 为安装时的模式标识数，和接下来的 data 参数一样，本文不将其做为重点。
　　
　　为了帮助读者更好地理解这一过程，笔者用一个具体的例子来说明：我们准备将来自主硬盘第 2 分区(hda2)上的 ext2 文件系统安装到前面创建的 "/dev" 目录中。那么对于 sys_mount() 函数的调用便具体为：
　　
　　sys_mount("hda2","/dev ","ext2",…)；
　　
　　该函数在将这些来自用户内存空间(user space)的参数拷贝到内核空间后，便调用 do_mount() 函数开始真正的安装文件系统的工作。同样，为了便于叙述和讲清楚主流程，接下来的说明将不严格按照具体的函数调用细节来进行。
　　
　　do_mount() 函数会首先调用 path_lookup() 函数来得到安装点的相关信息，如同创建目录过程中叙述的那样，该安装点的信息最终记录在 struct nameidata 类型的一个变量当中，为叙述方便，记该变量为nd。在本例中当 path_lookup() 函数返回时，nd 中记录的信息如下：nd.entry = new_entry; nd.mnt = mnt; 这里的变量如图 3 和 4 中所示。
　　
　　然后，do_mount() 函数会根据调用参数 flags 来决定调用以下四个函数之一：do_remount()、 do_loopback()、do_move_mount()、do_add_mount()。
　　
　　在我们当前的例子中，系统会调用 do_add_mount() 函数来向 VFS 树中安装点 "/dev " 安装一个实际的文件系统。在 do_add_mount() 中，主要完成了两件重要事情：一是获得一个新的安装区域块，二是将该新的安装区域块加入了安装系统链表。它们分别是调用 do_kern_mount() 函数和 graft_tree() 函数来完成的。这里的描述可能有点抽象，诸如安装区域块、安装系统链表等，不过不用着急，因为它们都是笔者自己定义出来的概念，等一下到后面会有专门的图表解释，到时便会清楚。
　　
　　do_kern_mount() 函数要做的事情，便是建立一新的安装区域块，具体的内容在前面的章节 VFS 目录树的建立中已经叙述过，这里不再赘述。
　　
　　graft_tree() 函数要做的事情便是将 do_kern_mount() 函数返回的一 struct vfsmount 类型的变量加入到安装系统链表中，同时 graft_tree() 还要将新分配的 struct vfsmount 类型的变量加入到一个hash表中，其目的我们将会在以后看到。
　　
　　这样，当 do_kern_mount() 函数返回时，在图 4 的基础上，新的数据结构间的关系将如图 5 所示。其中，红圈区域里面的数据结构便是被称做安装区域块的东西，其中不妨称 e2_mnt 为安装区域块的指针，蓝色箭头曲线即构成了所谓的安装系统链表。
　　
　　在把这些函数调用后形成的数据结构关系理清楚之后，让我们回到本章节开始提到的问题，即将 ext2 文件系统安装到了 "/dev " 上之后，对该目录上的操作如何转化为对 ext2 文件系统相应的操作。从图 5上看到，对 sys_mount() 函数的调用并没有直接改变 "/dev " 目录所对应的 inode (即图中的 new_inode变量)结构中的 i_op 和 i_fop 指针，而且 "/dev " 所对应的 dentry(即图中的 new_dentry 变量)结构仍然在 VFS 的目录树中，并没有被从其中隐藏起来，相应地，来自 hda2 上的 ext2 文件系统的根目录所对应的 e2_entry 也不是如当初笔者所想象地那样将 VFS 目录树中的 new_dentry 取而代之，那么这之间的转化到底是如何