转自:http://blog.sina.com.cn/s/blog_4a2f24830100l2h4.html
根据路径名寻找目标节点的dentry
下面来研究
文件系统中的一个非常关键的操作:根据路径名寻找目标节点的dentry。
例如要打开/mnt/win/dir1/abc 这个文件,就是根据这个路径,找到目标节点 ‘abc’ 对应的 dentry ,进而得到 inode的过程。
5.1. 寻找过程
寻找过程大致如下:
- 首先找到根文件系统的根目录节点 dentry 和 inode
- 由这个 inode 提供的操作接口 i_op->lookup(),找到下一层节点 ‘mnt’ 的dentry 和 inode
- 由 ‘mnt’ 的 inode 找到 ‘win’ 的 dentry 和 inode
- 由于 ‘win’ 是个“安装点”,因此需要找到“被安装设备”/dev/sda1 根目录节点的 dentry 和inode,只要找到 vfsmount B,就可以完成这个任务。
- 然后由 /dev/sda1 根目录节点的 inode 负责找到下一层节点 ‘dir1’ 的 dentry 和inode
- 由于 dir1 是个“安装点”,因此需要借助 vfsmount C 找到 /dev/sda2 的根目录节点 dentry 和inode
- 最后由这个 inode 负责找到 ‘abc’ 的 dentry 和 inode
可以看到,整个寻找过程是一个递归的过程。
完成寻找后,内存中结构如下,其中红色线条是寻找目标节点的路径
现在有两个问题:
- 在寻找过程的第一步,如何得到“根文件系统”的根目录节点的 dentry?
答案是这个 dentry 是被保存在进程的 task_struct 中的。后面分析进程与文件系统关系的时候再说这个。 - 如何寻找 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 之间的关系大致如下。可以看到:
- 现在有四个 vfsmount A, B, C, D
- A 和B对应着不同的安装点 ‘win’ 和 ‘linux’,但是都指向 /dev/sda1 根目录的 dentry
- C 和D 对应着这相同的安装点 ‘dir1’,也都指向 /dev/sda2 根目录的 dentry
- C 是 A 的 child, A是 C 的 parent
- 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用于管理这个“打开文件”表。
struct files_struct {
atomic_tcount;
rwlock_tfile_lock;
intmax_fds;
intmax_fdset;
intnext_fd;
struct file** fd;
fd_set*close_on_exec;
fd_set*open_fds;
fd_setclose_on_exec_init;
fd_setopen_fds_init;
struct file* fd_array[NR_OPEN_DEFAULT];
};
其中的fd_arrar[] 就是“打开文件”表。
task_struct中通过成员 files 与 files_struct 关联起来。
8.2. struct fs_struct
task_struct 中与文件系统相关的还有另外一个成员 fs,它指向一个 fs_struct 。
struct fs_struct {
atomic_t count;
rwlock_t lock;
int umask;
struct dentry * root, * pwd, * altroot;
struct vfsmount * 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 源码
struct nameidata {
struct dentry *dentry;
struct vfsmount *mnt;
struct qstr last;
unsigned int flags;
int last_type;
};
static inline struct inode *iget(struct super_block *sb, unsignedlong ino)
{
struct inode *inode = iget4_locked(sb, ino, NULL, NULL);
if (inode &&(inode->i_state & I_NEW)) {
sb->s_op->read_inode(inode);
unlock_new_inode(inode);
}
return inode;
}