文件打开过程的细节 获取inode的过程

xiongweixie

调用顺序如下
syscall_define3->do_Sys_open->do_filp_open->path_openat->
path_init, link_path_walk, do_last.

在path_init中就将 dentry 跟 inode 赋值给 nd （nameidata的数据结构）了。

path_init 中有三个大的条件判断:

1. if (flags & LOOKUP_ROOT){     //是否找root
   
2. ...
   
3. }
   
4. ...
   
5. if (*name=='/') {       //是否为根目录
   
6. ...
   
7. }else if (dfd == AT_FDCWD) {   //是否当前目录，cwd current work directory
   
8. ...
   
9. }else {                                    ///应该是进入这里，正常的话
   
10.                 struct dentry *dentry;
    
11. 
    
12.                 file = fget_raw_light(dfd, &fput_needed);      //在这里
    
13.                 retval = -EBADF;
    
14.                 if (!file)
    
15.                         goto out_fail;
    
16. 
    
17.                 dentry = file->f_path.dentry;    // 这里就file里就有文件的dentry了，说明inode也已经找到了，fget_raw_light 这个函数干的这个事情？
    
18. ...
    
19. }

复制代码

1. struct file *fget_raw_light(unsigned int fd, int *fput_needed)
   
2. {
   
3.         struct file *file;
   
4.         struct files_struct *files = current->files;
   
5. 
   
6.         *fput_needed = 0;
   
7.         if (atomic_read(&files->count) == 1) {
   
8.                 file = fcheck_files(files, fd);            
   
9.         } else {
   
10.                 rcu_read_lock();                          ///rcu 是否为 这个 Linux 2.6 内核中新的锁机制 RCU(Read-Copy Update)
    
11.                 file = fcheck_files(files, fd);
    
12.                 if (file) {
    
13.                         if (atomic_long_inc_not_zero(&file->f_count))
    
14.                                 *fput_needed = 1;
    
15.                         else
    
16.                                 /* Didn't get the reference, someone's freed */
    
17.                                 file = NULL;
    
18.                 }
    
19.                 rcu_read_unlock();
    
20.         }
    
21. 
    
22.         return file;
    
23. }

复制代码

这里没有看到文件如何被打开的？

疑问1，请问内核是如何获得文件的dentry跟inode的呢？ 应该是根据文件的路径一层一层的进来的，但是没有看到有循环。

疑问2，inode如果是根据文件路径获得的。为啥没用到inode number呢？根据inode number获取inode的方式，在内核的哪里用到了呢？源码在哪？ 方法如下： 文件系统根据 一个inode table的表格，查到inode number， 然后 inode number 然后获得inode，跟硬盘中的信息对上的。 inode 结构中有 i_rdev, i_size, i_bytes, i_blocks 等磁盘的信息。

谢谢各位~

tempname2

>> }else {                                    ///应该是进入这里，正常的话

非也，这是openat才会进入的地方。此时file的dentry是父目录的dentry。

>> 应该是根据文件的路径一层一层的进来的，但是没有看到有循环。

see link_path_walk()

>> 疑问2，inode如果是根据文件路径获得的。为啥没用到inode number呢？根据inode number获取inode的方式，在内核的哪里用到了呢？

VFS只用inode，文件系统驱动提供inode。

>> 方法如下： 文件系统根据 一个inode table的表格，查到inode number， 然后 inode number 然后获得inode，跟硬盘中的信息对上的。 inode 结构中有 i_rdev, i_size, i_bytes, i_blocks 等磁盘的信息

这是古典文件系统的作法。文件系统驱动一般根据父目录与name找到目标inode的inode number，再根据这个结果读取磁盘上的inode，然后生成inode结构体。这个过程中还可以利用VFS提供的inode cache library加快查找。参考ext4_lookup或者btrfs_lookup。

ext4的第一步是ext4_find_entry， 第二步是ext4_iget。

btrfs的第一步是btrfs_inode_by_name，第二步是btrfs_iget。

古典算法参考ext4的第一步; ext4现在也有hash tree的版本。其实这两步就是"目录的实现"与"文件元数据的实现"。