文件系统(5)

奋斗的蕃茄

文件系统(5)
9.2.3 注册文件系统
已注册文件系统
当重新建立Linux核心时安装程序会询问是否需要所有可支持的文件系统。核心重建时文件系统启动代码包含了所有那些编入核心的文件系统的初始化例程。

Linux文件系统可构造成模块, 此时它们会仅在需要时加载或者使用insmod来载入。当文件系统模块被加载时, 它将向核心注册并在卸载时撤除注册。每个文件系统的初始化例程还将向虚拟文件系统注册，它用一个包含文件系统名称和指向其VFS超块读例程的指针的file_system_type结构表示。每个file_system_type结构包含下列信息：

Superblock read routine

此例程载文件系统的一个实例被安装时由VFS调用。

File System name

文件系统的名称如ext2。

Device needed

文件系统是否需要设备支持。并不是所有的文件系统都需要设备来保存它。例如/proc文件系统不需要块设备支持。

你可以通过查阅/proc/filesystems可找出已注册的文件系统，如：

ext2
nodev proc
iso9660
9.2.4 安装文件系统
当超级用户试图安装一个文件系统时，Linux核心首先使系统调用中的参数有效化。尽管mount程序会做一些基本的检查, 但是它并不知道核心构造时已经支持那些文件系统,同时那些建议的安装点的确存在。看如下的一个mount命令：

$ mount -t iso9660 -o ro /dev/cdrom /mnt/cdrom
mount命令将传递三个参数给核心：文件系统名，包含文件系统的物理块设备以及此新文件系统要安装到的已存在的目录名。

虚拟文件系统首先必须做的是找到此文件系统。它将通过由链指针file_systems指向的file_system_type结 构来在所有已知文件系统中搜寻。

如果找到了一个相匹配的文件系统名,那么它就知道核心支持此文件系统并可得到读取此文件系统超块相关例程的指针。如果找不到,但文件系统使用了可动态加载核心模块,则操作仍可继续。此时核心将请求核心后台进程加载相应的文件系统模块。

接下来如果由mount传递的物理设备还没有安装, 则必须找到新文件系统将要安装到的那个目录的VFS inode。 这个VFS inode可能在inode cache中也可能在支撑这个安装点所在文件系统的块设备中。一旦找到这个inode则将对它进行检查以确定在此目录中是否已经安装了其它类型的文件系统。多个文件系统不能使用相同目录作为安装点。

此时VFS安装代码必须分配一个VFS超块并将安装信息传递到此文件系统的超块读例程中。系统中所有的VFS 超块都被保存在由super_block结构构成的super_blocks数组中, 并且对应此安装应有一个这种结构。超块读 例程将基于这些从物理设备中读取的信息来填充这些VFS超块域。对于EXT2文件系统此信息的转化过程十分 简便，仅需要读取EXT2超块并填充VFS超块。但其它文件系统如MS-DOS文件系统就不那么容易了。不管哪种文件系统，对VFS超块的填充意味着文件系统必须从支持它的块设备中读取描叙它的所有信息。如果块设备驱动不能从中读取或不包含这种类型文件系统则mount命令会失败。


图9.6 一个已安装的文件系统

每个文件系统用一个vfsmount结构来描叙。如图9.6所示。它们被排入由vfsmntlist指向的的链表中。

另外一个指针：vfsmnttail指向链表的最后一个入口, 同时mru_vfsmnt指针指向最近使用最多的文件系统。 每个vfsmount结构中由以下部分组成：包含此文件系统的块设备的设备号，此文件系统安装的目录以及文件 系统安装时分配的VFS超块指针。VFS超块指向这种类型文件系统和此文件系统根inode的file_system_type结构。一旦此文件系统被加载, 这个inode将一直驻留在VFS inod cache中。

9.2.5 在虚拟文件系统中搜寻文件
为了在虚拟文件系统中找到某个文件的VFS inode，VFS必须依次解析此文件名字中的间接目录直到找到此VFS inode。每次目录查找包括一个对包含在表示父目录VFS inode中的查找函数的调用。由于我们总是让每个文件系统的根可用并且由此系统的VFS 超块指向它，所以这是一个可行方案。每次在实际文件系统中寻找inode 时，文件系统将在目录cache中寻找相应目录。如果在目录cache中无相应入口则文件系统必须从底层文件系统或inode cache中取得此VFS inode。

9.2.6 Creating a File in the Virtual File System
9.2.7 卸载文件系统
如果已安装文件系统中有些文件还在被系统使用则不能卸载此文件系统。例如有进程使用/mnt/cdrom或其子目录时将不能卸载此文件系统。如果将要卸载的文件系统中有些文件还在被使用，那么在VFS inode cache中有与其对应的VFS inode。通过在inode链表中查找此文件系统占用设备的inode来完成此工作。对应此已安装文件系统的VFS超块为dirty，表示它已被修改过所以必须写回到磁盘的文件系统中。一旦写入磁盘,VFS超块占用的内存将归还到核心的空闲内存池中。最后对应的vfsmount结构将从vfsmntlist中释放。

9.2.8 The VFS Inode Cache
操纵已安装文件系统时，它们的VFS inode将被连续读写。虚拟文件系统通过维护一个inode cache来加速对所有已安装文件系统的访问。每次VFS inode都可从inode cache中读取出来以加速对物理设备的访问。

VFS inode cache以散列表形式实现，其入口时指向具有相同散列值的VFS inode链表。每个inode的散列值可通过包含此文件系统的底层物理设备标志符和inode号计算出来。每当虚拟文件系统访问一个inode时,系统将首先在VFS inode cache中查找。为了在cache中寻找inode，系统先计算出其散列值然后将其作为inode散列表的索引。这样将得到指向一系列相同散列值的inode链表。然后依次读取每个inode直到找到那个具有相同inode号以及设备标志符的inode为止。

如果在cache中找到了此inode则它的count值递增以表示用户增加了一个,同时文件操作将继续进行。否则必须找到一个空闲VFS inode以便文件系统能从内存中读取此inode。VFS有许多种选择来取得空闲inode。如果系统可以分配多个VFS inode则它将按如下步骤进行：首先分配核心页面并将其打碎成新的空闲inode并将其放入inode链表中。系统所有的VFS inode都被放到由first_inode指向的链表和inode散列表中。如果系统已经拥有所有inode, 则它必须找到便于重新使用的inode。那些inode最好count记数为0；因为这种inode没有谁在使用。很重要的VFS inode，如文件系统的根inode，其count 域总是大于0，所以它所使用的inode是不能被重新使用的。一旦找到可重用inode则应清除之: 其VFS inode可能为dirty,必须要写入到文件系统中或者需要加锁，此时系统必须等到解锁时才能继续运行。

找到新的VFS inode后必须调用文件系统相关例程使用从底层实际文件系统中读出的内容填充它。在填充过程 中，此新VFS inode的count记数为1并被加锁以排斥其它进程对它的使用直到此inode包含有效信息为止。

为了取得真正需要的VFS inode，文件系统可能需要存取几类其它inode。我们读取一个目录时虽然只需要最后一级目录但是所有的中间目录也被读了出来。由于使用了VFS inode cache，较少使用的inode将被丢弃而较多使用的inode将保存在cache中。

9.2.9 目录 Cache
为了加速对常用目录的访问，VFS维护着一个目录入口cache。

当在实际文件系统寻找目录时，有关此目录的细节将被存入目录cache中。当再次寻找此目录时，例如在此目录中列文件名或打开文件，则这些信息就可以在目录cache中找到。在实际实现中只有短目录入口（最多15个字 符）被缓存，这是因为那些较短目录名的目录正是使用最频繁的。例如/usr/X11R6/bin这个短目录经常被X server所使用。

目录cache也由散列表组成，每个入口指向具有相同散列值的目录cache人口链表。散列函数使用包含此文件系统的设备号以及目录名称来计算在此散列表中的偏移值或者索引值, 这样能很快找到被缓存的目录。 如果在cache中的搜寻消耗的时间太长或者甚至没有找到则使用此cache用处不大。

为了保证cache的有效性和及时更新，VFS保存着一个最近最少使用（LRU）的目录cache人口链表。当首次查找此目录时其目录入口被首次放入cache中并添加到第一级LRU链表的尾部。在已经充满的cache 中它代替位于LRU链表最前端的现存入口。此目录入口被再次使用时它将被放到第二级LRU cache链表的最后。此时需要将位于第二级LRU cache链表的最前端的那个替换掉。入口在链表前端的唯一原因是它们已经很久没被访问过了。如果被访问过那么它们将位于此链表的尾部附近。位于第二级LRU cache链表中的入口要比位于第一级LRU cache链表中的安全一些。