这是我的一篇旧文，发表在 CSDN，现重新进行了整理发表到 JAVAEYE。

Linux 文件系统是相当复杂的，本文只分析虚拟文件系统的实现，对具体的文件系统不涉及。

即使是虚拟文件系统，要在一篇文章中讲清楚也是不可能的，况且我自己的理解也不够透彻。

为什么选择 Linux 2.4.30？因为可以参考《Linux 源码情景分析》一书，减少学习难度。

先介绍一些文件系统的基本概念：

1、一块磁盘（块设备），首先要按照某种文件系统格式（如 NTFS、EXT2）进行格式化，然后才能在其上进行创建目录、保存文件等操作。

2、 在 Linux 中，有“安装”文件系统和“卸载”文件系统的概念。一块经过格式化的“块设备”（不管是刚刚格式化完的，没有创建任何名录和文件；还是已经创建了目录和文件），只有先被“安装”，才能融入 Linux 的文件系统中，用户才可以在它上面进行正常的文件操作。

3、  Linux 把目录或普通文件，统一看成“目录节点”。通常一个“目录节点”具有两个重要属性：名称以及磁盘上实际对应的数据。本文中，“目录节点”有时简称为“节点”

“符号链接”是一种特殊的目录节点，它只有一个名称，没有实际数据。这个名称指向一个实际的目录节点。

4、  “接口结构”：在 内核代码中，经常可以看到一种结构，其成员全部是函数指针，例如：

 

 这种结构的作用类似与 C++ 中的“接口类”，它是用 C 语言进行软件抽象设计时最重要的工具。通过它，将一组通用的操作抽象出来，核心的代码只针对这种“接口结构”进行操作，而这些函数的具体实现由不同的“子类”去完成。
 
 

 以这个 file_operations“接口”为例，它是“目录节点”提供的操作接口。不同的文件系统需要提供这些函数的具体实现。
 
 

 
 

 什么是虚拟文件系统（后文简称VFS）？
 
 

 Linux 支持很多种文件系统，如 NTFS、EXT2、EXT3 等等，这些都是某种具体的文件系统的实现。
 
 

 VFS 是一套代码框架（framework），它处于文件系统的使用者与具体的文件系统之间，将两者隔离开来。这种引入一个抽象层次的设计思想，即“上层不依赖于具体实现，而依赖于接口；下层不依赖于具体实现，而依赖于接口”，就是著名的“依赖反转”，它在 Linux内核中随处可见。
 
 

 
 
 

 VFS框架的设计，需要满足如下需求：
 
 

 
 

 
 

 
 

 1、 定义一套文件系统的统一概念
 
 

 2、 在这套概念基础上，实现提供给上层用户的操作接口，如 open, read, write 等
 
 

 3、 提供一套机制，让下层的具体的文件系统可融入 VFS 框架中，如文件系统的“注册”和“安装”
 
 

 本文重点就是学习VFS的重要概念以及在此基础上的重要操作。
 
 

 
 

 1、 VFS 通过树状结构来管理文件系统，树状结构的任何一个节点都是“目录节点”
 
 

 2、 树状结构具有一个“根节点”
 
 

 3、 VFS 通过“超级块”来了解一个具体文件系统的所有需要的信息。具体文件系统必须先向VFS注册，注册后，VFS就可以获得该文件系统的“超级块”。
 
 

 4、 具体文件系统可被安装到某个“目录节点”上，安装后，具体文件系统才可以被使用
 
 

 5、 用户对文件的操作，就是通过VFS 的接口，找到对应文件的“目录节点”，然后调用该“目录节点”对应的操作接口。
 
 

 
 

 1、 绿色代表“根文件系统”
 
 

 2、 黄色代表某一个文件系统 XXFS
 
 

 3、 根文件系统安装到“根目录节点”上
 
 

 4、 XXFS 安装到目录节点B上
 
 

 
 
 

 
 

 
 

 1、  inode 用以描述“目录节点” ，它描述了一个目录节点物理上的属性，例如大小，创建时间，修改时间、uid、gid 等
 
 

 
 

 
 

 4、  打开文件的过程就是寻找 “目录节点”对应的 inode 的过程
 
 

 5、  文件被打开后，inode 和 file_operation 都已经在内存中建立，file_operations 的指针也已经指向了具体文件系统提供的函数，此后都文件的操作，都由这些函数来完成。
 
 

 例如打开了一个普通文件 /root/file，其所在文件系统格式是 ext2，那么，内存中结构如下：
 
 

 
 
 

 
 

 本来，inode 中应该包括“目录节点”的名称，但由于符号链接的存在，导致一个物理文件可能有多个文件名，因此把和“目录节点”名称相关的部分从 inode 结构中分开，放在一个专门的 dentry 结构中。这样：
 
 

 
 

 2、  由于符号链接的存在，导致多个 dentry 可能对应到同一个 inode 上
 
 

 
 

 
 
 

 
 

 
 

 super_block 保存了文件系统的整体信息，如访问权限；
 
 

 
 

 

 
 

 在文件系统的操作中，经常需要获得一个“目录节点”对应的 inode，这个 inode 有可能已经存在于内存中了，也可能还没有，需要创建一个新的 inode，并从磁盘上读取相应的信息来填充。
 
 

 
 

 
 

 
  

 
 

 在 alloc_inode() 中可以看到，如果具体文件系统提供了创建 inode 的方法，则由具体文件系统来负责创建，否则采用系统默认的的创建方法。
 
 

 

 super_block 是在安装文件系统的时候创建的，后面会看到它和其它结构之间的关系。
 
 

 
 

 一个具体的文件系统，必须首先向VFS注册，才能被使用。
 
 

 
 

 文件系统注册的主要目的，就是让 VFS 创建该文件系统的“超级块”结构。
 
 

 
 
 

 这个结构中最关键的就是 read_super() 这个函数指针，它就是用于创建并设置 super_block 的目的的。
 
 

 因为安装一个文件系统的关键一步就是要为“被安装设备”创建和设置一个 super_block，而不同的具体的文件系统的 super_block 有自己特定的信息，因此要求具体的文件系统首先向内核注册，并提供 read_super() 的实现。
 
 

 
 

 1、  一个经过格式化的块设备，只有安装后，才能融入 Linux 的 VFS 之中。
 
 

 2、  安装一个文件系统，必须指定一个目录作为安装点。
 
 

 3、  一个设备可以同时被安装到多个目录上。
 
 

 4、  如果某个目录下原来有一些文件和子目录，一旦将一个设备安装到目录下后，则原有的文件和子目录消失。因为这个目录已经变成了一个安装点。
 
 

 5、  一个目录节点下可以同时安装多个设备。
 
 

 1、“根安装点”、“根设备”和“根文件系统”
 
 

 安装一个文件系统，除了需要“被安装设备”外，还要指定一个“安装点”。“安装点”是已经存在的一个目录节点。例如把 /dev/sda1 安装到 /mnt/win 下，那么 /mnt/win 就是“安装点”。
 
 

 可是文件系统要先安装后使用。因此，要使用 /mnt/win 这个“安装点”，必然要求它所在文件系统已也经被安装。
 
 

 也就是说，安装一个文件系统，需要另外一个文件系统已经被安装。
 
 

 这是一个鸡生蛋，蛋生鸡的问题：最顶层的文件系统是如何被安装的？
 
 

 答案是，最顶层文件系统在内核初始化的时候被安装在“根安装点”上的，而根安装点不属于任何文件系统，它对应的 dentry 、inode 等结构是由内核在初始化阶段凭空构造出来的。
 
 

 最顶层的文件系统叫做“根文件系统”。Linux 在启动的时候，要求用户必须指定一个“根设备”，内核在初始化阶段，将“根设备”安装到“根安装点”上，从而有了根文件系统。这样，文件系统才算准备就绪。此后，用户就可以通过 mount 命令来安装新的设备。
 

 “安装”一个文件系统涉及“被安装设备”和“安装点”两个部分，安装的过程就是把“安装点”和“被安装设备”关联起来，这是通过一个“安装连接件”结构 vfsmount 来完成的。
 
 

 
 

 每安装一次文件系统，会导致：
 
 

 
 

 2、  为“被安装设备”创建一个 super_block，并由具体的文件系统来设置这个 super_block。（我们在“注册文件系统”一节将再来分析这一步）
 
 

 
 

 
 

 
 

 
 

 在内核将根设备安装到“根安装点”上后，内存中有如下结构关系：
 
 

 
 
 

 
 

 
 
 

 
 

 VFS 中一个最关键以及最频繁的操作，就是根据路径名寻找目标节点的 dentry 以及 inode 。
 
 

 
 

 
 

 
 

 
 

 
 

 
 

 4、  由于 ‘win’ 是个“安装点”，因此需要找到“被安装设备”/dev/sda1 根目录节点的 dentry 和 inode，只要找到 vfsmount B，就可以完成这个任务。
 
 

 
 

 
 

 
 

 可以看到，整个寻找过程是一个递归的过程。
 
 

 完成寻找后，内存中结构如下，其中红色线条是寻找目标节点的路径
 
 

 
 
 

 
 

 1、在寻找过程的第一步，如何得到“根文件系统”的根目录节点的 dentry？
 
 

 答案是这个 dentry 是被保存在进程的 task_struct 中的。后面分析进程与文件系统关系的时候再说这个。
 
 

 
 

 
 

 
 

 我们知道， vfsmount A、B、C 之间形成了一种父子关系，为什么不根据 A 来找到 B ，根据 B 找到 C 了？
 
 

 这是因为一个文件系统可能同时被安装到不同的“安装点”上。
 
 

 
 

 
 

 
 

 现在， vfsmount 与 dentry 之间的关系大致如下。可以看到：
 
 

 
 

 
 

 
 

 
 

 
 

 
 
 

 
 

 在递归寻找目标节点的过程中，需要借助一个搜索辅助结构 nameidata，这是一个临时结构，仅仅用在寻找目标节点的过程中。
 
  

 

 
 

 dentry 随着目录节点的深入而不断变化；
 
 

 而 mnt 则在每进入一个新的文件系统后发生变化
 
 

 
 

 
 

 
 

 
 

 有了这个结构，上一节的问题就可以得到解决了：
 
 

 
 

 
 

 1、 “打开文件”结构 file
 
 

 一个文件每被打开一次，就对应着一个 file 结构。
 
 

 我们知道，每个文件对应着一个 dentry 和 inode，每打开一个文件，只要找到对应的 dentry 和 inode 不就可以了么？为什么还要引入这个 file 结构？
 
 

 这是因为一个文件可以被同时打开多次，每次打开的方式也可以不一样。
 
 

 而dentry 和 inode 只能描述一个物理的文件，无法描述“打开”这个概念。
 
 

 因此有必要引入 file 结构，来描述一个“被打开的文件”。每打开一个文件，就创建一个 file 结构。
 
 

 file 结构中包含以下信息：
 
 

 打开这个文件的进程的 uid,pid
 
 

 
 

 
 

 
 

 实际上，打开文件的过程正是建立file, dentry, inode 之间的关联的过程。
 
 

 
 
 

 
 

 文件一旦被打开，数据结构之间的关系已经建立，后面对文件的读写以及其它操作都变得很简单。就是根据 fd 找到 file 结构，然后找到 dentry 和 inode，最后通过 inode->i_fop 中对应的函数进行具体的读写等操作即可。
 
十一、进程与文件系统的关联
 

 最后，来了解一下一个进程，与文件系统有哪些关联。
 
 

 
 

 一个进程可以打开多个文件，每打开一个文件，创建一个 file 结构。所有的 file 结构的指针保存在一个数组中。而文件描述符正是这个数组的下标。
 
 

 我记得以前刚开始学习编程的时候，怎么都无法理解这个“文件描述符”的概念。现在从内核的角度去看，就很容易明白“文件描述符”是怎么回事了。用户仅仅看到一个“整数”，实际底层对应着的是 file, dentry, inode 等复杂的数据结构。
 
 

 files_struct 用于管理这个“打开文件”表。
 
 

 

 其中的 fd_arrar[] 就是“打开文件”表。
 
 

 
 

 
 

 
  

 

 
 

 root 指向此进程的“根目录”，通常就是“根文件系统”的根目录 dentry
 
 

 pwd 指向此进程当前所在目录的 dentry
 
 

 
 

 rootmnt ：指向“安装”根文件系统时创建的那个 vfsmount
 
 

 pwdmnt：指向“安装”当前工作目录所在文件系统时创建的那个 vfsmount
 
 

 这两个域用于初始化 nameidata 结构。
 
 

 3、 进程与文件系统的结构关系图
 
 

 下图描述了进程与文件系统之间的结构关系图：
 
 

 
 
 

 
 

 1、《Linux 源码情景分析》上册
 
 

 

}一：前言前段时间在编译kernel的时候发现rootfs挂载不上。相同的root选项设置旧版的image却可以。为了彻底解决这个问题。研究了一下rootfs的挂载过程。特总结如下,希望能给这部份知识点比较迷茫的朋友一点帮助。二：rootfs的种类总的来说，rootfs分为两种：虚拟rootfs和真实rootfs.现在kernel的发展趋势是将更多的功能放到用户空间完成。以保持内核的精简。虚拟rootfs也是各linux发行厂商普遍采用的一种方式。可以将一部份的初始化工作放在虚拟的rootfs里完成。然后切换到真实的文件系统.在虚拟rootfs的发展过程中。又有以下几个版本：initramfs:Initramfs是在 2.5中引入的技术，实际上它的含义就是：在内核镜像中附加一个cpio包，这个cpio包中包含了一个小型的文件系统，当内核启动时，内核将这个cpio包解开，并且将其中包含的文件系统释放到rootfs中，内核中的一部分初始化代码会放到这个文件系统中，作为用户层进程来执行。这样带来的明显的好处是精简了内核的初始化代码，而且使得内核的初始化过程更容易定制。这种这种方式的rootfs是包含在kernel cpio格式的rootfsimage-initrd:传统格式的rootfs关于这两种虚拟文件系统的制作请自行参阅其它资料三：rootfs文件系统的挂载过程这里说的rootfs不同于上面分析的rootfs。这里指的是系统初始化时的根结点。即/结点。它是其于内存的rootfs文件系统。这部份之前在>和文件系统中已经分析过。为了知识的连贯性这里再重复一次。Start_kernel()àmnt_init():void &root);}在这里，将rootfs文件系统挂载。它的挂载点默认为”/”.最后切换进程的根目录和当前目录为”/”.这也就是根目录的由来。不过这里只是初始化。等挂载完具体的文件系统之后，一般都会将根目录切换到具体的文件系统。所以在系统启动之后，用mount命令是看不到rootfs的挂载信息的.四：虚拟文件系统的挂载根目录已经挂上去了，可以挂载具体的文件系统了.在start_kernel()àrest_init()àkernel_init():static 0;}unpack_to_rootfs：顾名思义就是解压包，并将其释放至rootfs。它实际上有两个功能，一个是释放包，一个是查看包，看其是否属于cpio结构的包。功能选择是根据最后的一个参数来区分的.在这个函数里，对应我们之前分析的三种虚拟根文件系统的情况。一种是跟kernel融为一体的initramfs.在编译kernel的时候，通过链接脚本将其存放在__initramfs_start至__initramfs_end的区域。这种情况下，直接调用unpack_to_rootfs将其释放到根目录.如果不是属于这种形式的。也就是__initramfs_start和__initramfs_end的值相等，长度为零。不会做任何处理。退出.对应后两种情况。从代码中看到，必须要配制CONFIG_BLK_DEV_RAM才会支持image-initrd。否则全当成cpio-initrd的形式处理。对于是cpio-initrd的情况。直接将其释放到根目录。对于是image-initrd的情况。将其释放到/initrd.image.最后将initrd内存区域归入伙伴系统。这段内存就可以由操作系统来做其它的用途了。接下来，内核对这几种情况又是怎么处理的呢？不要着急。往下看：回到kernel_init()这个函数：static 0;}ramdisk_execute_command:在kernel解析引导参数的时候使用。如果用户指定了init文件路径，即使用了“init=”，就会将这个参数值存放到这里。如果没有指定init文件路径。默认为/init对应于前面一段的分析，我们知道，对于initramdisk和cpio-initrd的情况，都会将虚拟根文件系统释放到根目录。如果这些虚拟文件系统里有/init这个文件。就会转入到init_post()。Init_post()代码如下：static /bin/init,/bin/sh注意的是，run_init_process在调用相应程序运行的时候，用的是kernel_execve。也就是说调用进程会替换当前进程。只要上述任意一个文件调用成功，就不会返回到这个函数。如果上面几个文件都无法执行。打印出没有找到init文件的错误。对于image-hdr或者是虚拟文件系统中没有包含  sys_chroot(".");}这里有几个比较有意思的处理，首先用户可以用root=来指定根文件系统。它的值保存在saved_root_name中。如果用户指定了以mtd开始的字串做为它的根文件系统。就会直接去挂载。这个文件是mtdblock的设备文件。否则将设备结点文件转换为ROOT_DEV即设备节点号然后，转向initrd_load()执行initrd预处理后，再将具体的根文件系统挂载。注意到，在这个函数末尾。会调用sys_mount()来移动当前文件系统挂载点到”/”目录下。然后将根目录切换到当前目录。这样，根文件系统的挂载点就成为了我们在用户空间所看到的”/”了.对于其它根文件系统的情况，会先经过initrd的处理。即int  }}先将/dev/ram0挂载，而后执行/linuxrc.等其执行完后。切换根目录，再挂载具体的根文件系统.到这里。文件系统挂载的全部内容就分析完了.五：小结在本小节里。分析了根文件系统的挂载流程。并对几个虚拟根文件系统的情况做了详细的分析。理解这部份，对我们构建linux嵌入式开发系统是很有帮助的.PS:参考资料：ibm技术论坛的> 

本文来自ChinaUnix博客，如果查看原文请点：

linux内核探秘-深入理解文件系统和驱动框架

详细描述了linux系统的文件系统架构，虚拟文件系统以及ext2文件系统，也详细介绍了驱动的框架，对于linux底层有很好的借鉴作用