1.概述
根据以前学习内核源码的经验，在学习文件系统实现之前，我大概定了个目标：
1、建立一个清晰的全局概念。为将来需要研究代码细节打下坚实基础。
2、只研究虚拟文件系统VFS的实现，不研究具体文件系统。
为什么选择Linux 2.4.30？因为可以参考《Linux源码情景分析》一书，减少学习难度。
1.1.基本概念
1、一块磁盘(块设备)，首先要按照某种文件系统(如NTFS)格式进行格式化，然后才能在其上进行创建目录、保存文件等操作。
在Linux中，有“安装”文件系统和“卸载”文件系统的概念。
一块经过格式化的“块设备”(不管是刚刚格式化完的，没有创建任何名录和文件；还是已经创建了目录和文件)，只有先被“安装”，才能融入Linux的文件系统中，用户才可以在它上面进行正常的文件操作。
2、Linux把目录或普通文件，统一看成“目录节点”。通常一个“目录节点”具有两个重要属性：名称以及磁盘上实际对应的数据。本文中，“目录节点”有时简称为“节点”
“符号链接”是一种特殊的目录节点，它只有一个名称，没有实际数据。这个名称指向一个实际的目录节点。
3、“接口结构”：在内核代码中，经常可以看到一种结构，其成员全部是函数指针，例如：
struct file_operations {
struct module *owner;
loff_t (*llseek) (struct file *, loff_t, int);
ssize_t (*read) (struct file *, char *, size_t, loff_t *);
ssize_t (*write) (struct file *, const char *, size_t, loff_t *);
int (*readdir) (struct file *, void *, filldir_t);
unsigned int (*poll) (struct file *, struct poll_table_struct *);
int (*ioctl) (struct inode *, struct file *, unsigned int, unsigned long);
int (*mmap) (struct file *, struct vm_area_struct *);
int (*open) (struct inode *, struct file *);
int (*flush) (struct file *);
int (*release) (struct inode *, struct file *);
int (*fsync) (struct file *, struct dentry *, int datasync);
int (*fasync) (int, struct file *, int);
int (*lock) (struct file *, int, struct file_lock *);
ssize_t (*readv) (struct file *, const struct iovec *, unsigned long, loff_t *);
ssize_t (*writev) (struct file *, const struct iovec *, unsigned long, loff_t *);
ssize_t (*sendpage) (struct file *, struct page *, int, size_t, loff_t *, int);
unsigned long (*get_unmapped_area)(struct file *, unsigned long, unsigned long, unsigned long, unsigned long);
};
这种结构的作用类似与C++中的“接口类”，它是用C语言进行软件抽象设计时最重要的工具。通过它，将一组通用的操作抽象出来，核心的代码只针对这种“接口结构”进行操作，而这些函数的具体实现由不同的“子类”去完成。
以这个 file_operations“接口”为例，它是“目录节点”提供的操作接口。不同的文件系统需要提供这些函数的具体实现。
本文中，“接口结构”有时简称“接口”。
1.2.虚拟文件系统
Linux通过虚拟文件系统 (VFS) 来支持不同的具体的文件系统，那么VFS到底是什么？
从程序员的角度看，我认为VFS就是一套代码框架(framework)，它将用户与具体的文件系统隔离开来，使得用户能够通过这套框架，以统一的接口在不同的具体的文件系统上进行操作。
这套框架包括：
1、为用户提供统一的文件和目录的操作接口，如open, read, write
2、抽象出文件系统共有的一些结构，包括“目录节点”inode、“超级块”super_block等。
3、面向具体的文件系统，定义一系列统一的操作“接口”，如file_operations, inode_operations, dentry_operation，具体的文件系统必须提供它们的实现。
4、提供一套机制，让具体的文件系统融入VFS框架中，包括文件系统的“注册”和“安装”
5、实现这套框架逻辑的核心代码
我对文件系统的学习，实际上就是学习虚拟文件系统这套框架是如何实现的。
2.核心数据结构
数据结构是代码的灵魂，要分析一个复杂的系统，关键是掌握那些核心的数据结构，这包括：
1、弄清数据结构的核心功能。一个数据结构通常具有比较复杂的成员，此外，还有一些成员用于建立数据结构之间的关系。如果要一个个去理解，就会陷入细节。
2、弄清数据结构之间的静态关系
3、弄清数据结构之间是如何建立起动态的关系的
本文重点分析文件系统中的关键数据结构以及它们之间的关系。
2.1.inode和 file_operations
1、inode用以描述“目录节点” ，它描述了一个目录节点物理上的属性，例如大小，创建时间，修改时间、uid、gid等
2、file_operations是“目录节点”提供的操作“接口”。它包括open, read, wirte, ioctl, llseek, mmap等操作。
3、一个inode通过成员i_fop对应一个file_operations
4、打开文件的过程就是寻找“目录节点”对应的 inode的过程
5、文件被打开后，inode和file_operation都已经在内存中建立，file_operations的指针也已经指向了具体文件系统提供的函数，此后都文件的操作，都由这些函数来完成。
例如打开了一个普通文件/root/file，其所在文件系统格式是ext2，那么，内存中结构如下：
2.2.目录节点入口dentry
本来，inode中应该包括“目录节点”的名称，但由于符号链接的存在，导致一个物理文件可能有多个文件名，因此把和“目录节点”名称相关的部分从inode中分开，放在一个专门的dentry结构中。这样：
1、一个dentry通过成员d_inode对应到一个inode上，寻找inode的过程变成了寻找dentry的过程。因此，dentry变得更加关键，inode常常被dentry所遮掩。可以说， dentry 是文件系统中最核心的数据结构，它的身影无处不在。
2、由于符号链接的存在，导致多个dentry可能对应到同一个inode上
例如，有一个符号链接/tmp/abc指向一个普通文件/root/file，那么dentry与inode之间的关系大致如下：
2.3.super_block和super_operations
一个存放在磁盘上的文件系统如EXT2等，在它的格式中通常包括一个“超级块”或者“控制块”的部分，用于从整体上描述文件系统，例如文件系统的大小、是否可读可写等等。
虚拟文件系统中也通过“超级块”这种概念来描述文件系统整体的信息，对应的结构是struct super_block。
super_block除了要记录文件大小、访问权限等信息外，更重要的是提供一个操作“接口”super_operations。
structsuper_operations {structinode*(*alloc_inode)(structsuper_block*sb);void(*destroy_inode)(structinode*);void(*read_inode) (structinode*);void(*read_inode2) (structinode*,void*) ;void(*dirty_inode) (structinode*);void(*write_inode) (structinode*,int);void(*put_inode) (structinode*);void(*delete_inode) (structinode*);void(*put_super) (structsuper_block*);void(*write_super) (structsuper_block*);int(*sync_fs) (structsuper_block*);void(*write_super_lockfs) (structsuper_block*);void(*unlockfs) (structsuper_block*);int(*statfs) (structsuper_block*,structstatfs*);int(*remount_fs) (structsuper_block*,int*,char*);void(*clear_inode) (structinode*);void(*umount_begin) (structsuper_block*);structdentry*(*fh_to_dentry)(structsuper_block*sb, __u32*fh,intlen,intfhtype,intparent);int(*dentry_to_fh)(structdentry*, __u32*fh,int*lenp,intneed_parent);int(*show_options)(structseq_file*,structvfsmount*);
};
我们通过分析“获取一个inode”的过程来只理解这个“接口”中两个成员alloc_inode和read_inode的作用。
在文件系统的操作中，经常需要获得一个“目录节点”对应的inode，这个inode有可能已经存在于内存中了，也可能还没有，需要创建一个新的inode，并从磁盘上读取相应的信息来填充。
对应的代码是iget()(inlcude/linux/fs.h)过程如下：
1、通过iget4_locked()获取inode。如果inode在内存中已经存在，则直接返回；否则创建一个新的inode
2、如果是新创建的inode，通过super_block->s_op->read_inode()来填充它。也就是说，如何填充一个新创建的inode，是由具体文件系统提供的函数实现的。
iget4_locked()首先在全局的inode hash table中寻找，如果找不到，则调用get_new_inode()，进而调用alloc_inode()来创建一个新的inode在alloc_inode()中可以看到，如果具体文件系统提供了创建inode的方法，则由具体文件系统来负责创建，否则采用系统默认的的创建方法。
staticstructinode*alloc_inode(structsuper_block*sb)
{staticstructaddress_space_operations empty_aops;staticstructinode_operations empty_iops;staticstructfile_operations empty_fops;structinode*inode;if(sb->s_op->alloc_inode)
inode=sb->s_op->alloc_inode(sb);else{
inode=(structinode*) kmem_cache_alloc(inode_cachep, SLAB_KERNEL);if(inode)
memset(&inode->u,0,sizeof(inode->u));
}if(inode) {structaddress_space*constmapping=&inode->i_data;
inode->i_sb=sb;
inode->i_dev=sb->s_dev;
inode->i_blkbits=sb->s_blocksize_bits;
inode->i_flags=0;
atomic_set(&inode->i_count,1);
inode->i_sock=0;
inode->i_op=&empty_iops;
inode->i_fop=&empty_fops;
inode->i_nlink=1;
atomic_set(&inode->i_writecount,0);
inode->i_size=0;
inode->i_blocks=0;
inode->i_bytes=0;
inode->i_generation=0;
memset(&inode->i_dquot,0,sizeof(inode->i_dquot));
inode->i_pipe=NULL;
inode->i_bdev=NULL;
inode->i_cdev=NULL;
mapping->a_ops=&empty_aops;
mapping->host=inode;
mapping->gfp_mask=GFP_HIGHUSER;
inode->i_mapping=mapping;
}returninode;
}
super_block是在安装文件系统的时候创建的，后面会看到它和其它结构之间的关系。
3.安装文件系统
1、一个经过格式化的块设备，只有安装后，才能融入Linux的VFS之中。
2、安装一个文件系统，必须指定一个目录作为安装点。
3、一个设备可以同时被安装到多个目录上。
4、如果某个目录下原来有一些文件和子目录，一旦将一个设备安装到目录下后，则原有的文件和子目录消失。因为这个目录已经变成了一个安装点。
5、一个目录节点下可以同时安装多个设备。
3.1.“根安装点”、“根设备”和“根文件系统”
安装一个文件系统，除了需要“被安装设备”外，还要指定一个“安装点”。“安装点”是已经存在的一个目录节点。例如把/dev/sda1安装到/mnt/win下，那么/mnt/win就是“安装点”。
可是文件系统要先安装后使用。因此，要使用/mnt/win这个“安装点”，必然要求它所在文件系统已也经被安装。
也就是说，安装一个文件系统，需要另外一个文件系统已经被安装。
这是一个鸡生蛋，蛋生鸡的问题：最顶层的文件系统是如何被安装的？
答案是，最顶层文件系统的时候是被安装在“根安装点”上的，而根安装点不属于任何文件系统，它对应的dentry、inode是由内核在初始化阶段凭空构造出来的。
最顶层的文件系统叫做“根文件系统”。Linux在启动的时候，要求用户必须指定一个“根设备”，内核在初始化阶段，将“根设备”安装到“根安装点”上，从而有了根文件系统。这样，文件系统才算准备就绪。此后，用户就可以通过mount命令来安装新的设备。
3.2.安装连接件vfsmount
“安装”一个文件系统涉及“被安装设备”和“安装点”两个部分，安装的过程就是把“安装点”和“被安装设备”关联起来，这是通过一个“安装连接件”结构vfsmount来完成的。
vfsmount将“安装点”dentry和“被安装设备”的根目录节点dentry关联起来。
每安装一次文件系统，会导致：
1、创建一个 vfsmount
2、为“被安装设备”创建一个 super_block，并由具体的文件系统来设置这个 super_block。(我们在“注册文件系统”一节将再来分析这一步)
3、为被安装设备的根目录节点创建 dentry
4、为被安装设备的根目录节点创建 inode，并由super_operations->read_inode()来设置此inode
5、将super_block与“被安装设备“根目录节点dentry关联起来
6、将 vfsmount 与“被安装设备”的根目录节点 dentry 关联起来
在内核将根设备安装到“根安装点”上后，内存中有如下结构关系：
现在假设我们在/mnt/win下安装了/dev/sda1，/dev/sda1下有 dir1，然后又在dir1下安装了/dev/sda2，那么内存中就有了如下的结构关系
4.注册文件系统
前面说了，在安装一个文件系统的时候，需要为“被安装设备”创建一个 super_block，并设置它。
如果从源码追寻这个创建和设置 super_block 的过程，就引出了“注册文件系统”的概念。
实际上，在安装一个文件系统之前，还需要有一个注册文件系统的步骤，否则内核就因为不认识该文件系统而无法完成安装。
通过register_filesystem() ，将一个“文件系统类型”结构file_system_type注册到内核中一个全局的链表file_systems 上。
structfile_system_type {constchar*name;intfs_flags;structsuper_block*(*read_super) (structsuper_block*,void*,int);structmodule*owner;structfile_system_type*next;structlist_head fs_supers;
};intregister_filesystem(structfile_system_type*fs)
{intres=0;structfile_system_type**p;if(!fs)return-EINVAL;if(fs->next)return-EBUSY;
INIT_LIST_HEAD(&fs->fs_supers);
write_lock(&file_systems_lock);
p=find_filesystem(fs->name);if(*p)
res=-EBUSY;else*p=fs;
write_unlock(&file_systems_lock);returnres;
}
这个结构中最关键的就是 read_super() 这个函数指针，它就是用于创建并设置 super_block 的目的的。
因为安装一个文件系统的关键一步就是要为“被安装设备”创建和设置一个 super_block，而不同的具体的文件系统的 super_block 有自己特定的信息，因此要求具体的文件系统首先向内核注册，并提供 read_super() 的实现。
5.根据路径名寻找目标节点的dentry
下面来研究文件系统中的一个非常关键的操作：根据路径名寻找目标节点的dentry。
例如要打开/mnt/win/dir1/abc这个文件，就是根据这个路径，找到目标节点 ‘abc’对应的dentry，进而得到inode的过程。
5.1.寻找过程
寻找过程大致如下：
1、首先找到根文件系统的根目录节点dentry和inode
2、由这个inode提供的操作接口i_op->lookup()，找到下一层节点 ‘mnt’的dentry和 inode
3、由 ‘mnt’的inode找到 ‘win’的dentry和inode
4、由于 ‘win’是个“安装点”，因此需要找到“被安装设备”/dev/sda1根目录节点的dentry和inode，只要找到vfsmount B，就可以完成这个任务。
5、然后由/dev/sda1根目录节点的inode负责找到下一层节点 ‘dir1’的dentry和inode
6、由于dir1是个“安装点”，因此需要借助vfsmount C找到/dev/sda2的根目录节点dentry和inode
7、最后由这个inode负责找到 ‘abc’的dentry和inode
可以看到，整个寻找过程是一个递归的过程。
完成寻找后，内存中结构如下，其中红色线条是寻找目标节点的路径
现在有两个问题：
1、在寻找过程的第一步，如何得到“根文件系统”的根目录节点的dentry？
答案是这个dentry是被保存在进程的task_struct中的。后面分析进程与文件系统关系的时候再说这个。
2、如何寻找vfsmount B和C？
这是接下来要分析的。
5.2.vfsmount之间的关系
我们知道， vfsmount A、B、C之间形成了一种父子关系，为什么不根据A来找到B，根据B找到C了？
这是因为一个文件系统可能同时被安装到不同的“安装点”上。
假设把/dev/sda1同时安装到/mnt/win和/mnt/linux下
现在/mnt/win/dir1和/mnt/linux/dir1对应的是同一个dentry！！！
然后，又把/dev/sda2分别安装到/mnt/win/dir1和/mnt/linux/dir1下
现在，vfsmount与dentry之间的关系大致如下。可以看到：
1、现在有四个vfsmount A, B, C, D
2、A和B对应着不同的安装点 ‘win’和 ‘linux’，但是都指向/dev/sda1根目录的dentry
3、C和D对应着这相同的安装点 ‘dir1’，也都指向/dev/sda2根目录的dentry
4、C是A的child, A是C的parent
5、D是B的child, B是D的parent
5.3.搜索辅助结构nameidata在递归寻找目标节点的过程中，需要借助一个搜索辅助结构nameidata，这是一个临时结构，仅仅用在寻找目标节点的过程中。
在搜索初始化时，创建nameidata，其中mnt指向current->fs->rootmnt，dentry指向current->fs->root
dentry随着目录节点的深入而不断变化；
而mnt则在每进入一个新的文件系统后发生变化
以寻找/mnt/win/dir1/abc为例
开始的时候，mnt指向vfsmount A，dentry指向根设备的根目录
随后，dentry先后指向 ‘mnt’和 ‘win’对应的dentry
然后当寻找到vfsmount B后，mnt指向了它，而dentry则指向了/dev/sda1根目录的dentry
有了这个结构，上一节的问题就可以得到解决了：在寻找/mnt/win/dir1/abc的过程中，首先找到A，接下来在要决定选C还是D，因为是从A搜索下来的，C是A的child，因此选择C而不是D；同样，如果是寻找/mnt/linux/dir1/abc，则会依次选择B和D。这就是为什么nameidata中要带着一个vfsmount的原因。
6.打开文件
6.1.“打开文件”结构 file
一个文件每被打开一次，就对应着一个file结构。
我们知道，每个文件对应着一个dentry和inode，每打开一个文件，只要找到对应的dentry和inode不就可以了么？为什么还要引入这个file结构？
这是因为一个文件可以被同时打开多次，每次打开的方式也可以不一样。
而dentry和inode只能描述一个物理的文件，无法描述“打开”这个概念。
因此有必要引入file结构，来描述一个“被打开的文件”。每打开一个文件，就创建一个file结构。
file结构中包含以下信息：
打开这个文件的进程的uid,pid
打开的方式
读写的方式
当前在文件中的位置实际上，打开文件的过程正是建立file, dentry, inode之间的关联的过程。
7.文件的读写
文件一旦被打开，数据结构之间的关系已经建立，后面对文件的读写以及其它操作都变得很简单。就是根据fd找到file结构，然后找到dentry和inode，最后通过inode->i_fop中对应的函数进行具体的读写等操作即可。
8.进程与文件系统的关联
8.1.“打开文件”表和 files_struct结构
一个进程可以打开多个文件，每打开一个文件，创建一个 file 结构。所有的 file 结构的指针保存在一个数组中。而文件描述符正是这个数组的下标。
我记得以前刚开始学习编程的时候，怎么都无法理解这个“文件描述符”的概念。现在从内核的角度去看，就很容易明白“文件描述符”是怎么回事了。用户仅仅看到一个“整数”，实际底层对应着的是 file, dentry, inode 等复杂的数据结构。
files_struct 用于管理这个“打开文件”表。
structfiles_struct {
atomic_t count;
rwlock_t file_lock;/*Protects all the below members. Nests inside tsk->alloc_lock*/intmax_fds;intmax_fdset;intnext_fd;structfile**fd;/*current fd array*/fd_set*close_on_exec;
fd_set*open_fds;
fd_set close_on_exec_init;
fd_set open_fds_init;structfile*fd_array[NR_OPEN_DEFAULT];
};
其中的 fd_arrar[] 就是“打开文件”表。
task_struct 中通过成员 files 与 files_struct 关联起来。
8.2.structfs_structtask_struct 中与文件系统相关的还有另外一个成员 fs，它指向一个 fs_struct 。
structfs_struct {
atomic_t count;
rwlock_tlock;intumask;structdentry*root,*pwd,*altroot;structvfsmount*rootmnt,*pwdmnt,*altrootmnt;
};
其中：
root指向此进程的“根目录”，通常就是“根文件系统”的根目录 dentry
pwd指向此进程当前所在目录的 dentry
因此，通过 task_struct->fs->root，就可以找到“根文件系统”的根目录 dentry，这就回答了 5.1 小节的第一个问题。
rootmnt ：指向“安装”根文件系统时创建的那个 vfsmount
pwdmnt：指向“安装”当前工作目录所在文件系统时创建的那个 vfsmount
这两个域用于初始化 nameidata 结构。
8.3.进程与文件系统的结构关系图
下图描述了进程与文件系统之间的结构关系图：
9.参考资料
1、《Linux源码情景分析》上册
2、Linux 2.4.30源码
structnameidata {structdentry*dentry;structvfsmount*mnt;structqstr last;
unsignedintflags;intlast_type;
};
staticinlinestructinode*iget(structsuper_block*sb, unsignedlongino)
{structinode*inode=iget4_locked(sb, ino, NULL, NULL);if(inode&&(inode->i_state&I_NEW)) {
sb->s_op->read_inode(inode);
unlock_new_inode(inode);
}returninode;
}
54
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
