Linux下的文件系统2

2017-03-13

_{^{上文针对VFS的基本信息做了介绍，并简单介绍了VFS涉及的几个数据机构，本节结合LInux源码，对各个结构之间的关系进行分析。}}

---

一、总体架构图

总体架构图如上图所示，结合进程访问文件的实际情况，根据上图进行细节化的描述。进程通过其结构中的files_struct结构和文件建立联系，看戏files_struct结构

struct files_struct {
  /*
   * read mostly part
   */
    atomic_t count;
    struct fdtable __rcu *fdt;
    struct fdtable fdtab;
  /*
   * written part on a separate cache line in SMP
   */
    spinlock_t file_lock ____cacheline_aligned_in_smp;
    int next_fd;
    unsigned long close_on_exec_init[];
    unsigned long open_fds_init[];
    struct file __rcu * fd_array[NR_OPEN_DEFAULT];
};

首先是一个原子变量，记录打开文件的个数，注意这里不只是普通文件，还包括设备文件等其他文件。next_fd记录当前下一个可用的文件描述符，用于在下次进程打开文件时快速分配。而close_on_exec_init和open_fds_init是位图。fd_array是初始化状态的文件描述符数组，而fdtab是真正管理文件描述符的结构。看下fdtable结构

struct fdtable {
    unsigned int max_fds;
    struct file __rcu **fd;      /* current fd array */
    unsigned long *close_on_exec;
    unsigned long *open_fds;
    struct rcu_head rcu;
};

max_fds表示最大的打开文件数，可以更改。fd是一个指向文件描述符数组的指针，初始化为files_struct结构中fd_array数组的地址，close_on_exec指向files_struct结构中的位域。open_fds是一个指向位域的指针，管理着当前打开的所有描述符，如果位域中的对应位被置位表示该描述符在使用中。

关于描述符表扩展的情况，最后进行解释。上面的描述符表中，都是指向file结构的指针。进程每打开一个文件，就会有一个file结构与之对应。换句话说，file结构记录的某次进程对文件的某一次操作信息。看下file结构

struct file {
    /*
     * fu_list becomes invalid after file_free is called and queued via
     * fu_rcuhead for RCU freeing
     */
    union {
        struct list_head    fu_list;
        struct rcu_head     fu_rcuhead;
    } f_u;
    struct path        f_path;
#define f_dentry    f_path.dentry
    struct inode        *f_inode;    /* cached value */
    const struct file_operations    *f_op;
 
    /*
     * Protects f_ep_links, f_flags, f_pos vs i_size in lseek SEEK_CUR.
     * Must not be taken from IRQ context.
     */
    spinlock_t        f_lock;
#ifdef CONFIG_SMP
    int            f_sb_list_cpu;
#endif
    atomic_long_t        f_count;
    unsigned int         f_flags;
    fmode_t            f_mode;
    loff_t            f_pos;
    struct fown_struct    f_owner;
    const struct cred    *f_cred;
    struct file_ra_state    f_ra;
 
    u64            f_version;
#ifdef CONFIG_SECURITY
    void            *f_security;
#endif
    /* needed for tty driver, and maybe others */
    void            *private_data;
 
#ifdef CONFIG_EPOLL
    /* Used by fs/eventpoll.c to link all the hooks to this file */
    struct list_head    f_ep_links;
    struct list_head    f_tfile_llink;
#endif /* #ifdef CONFIG_EPOLL */
    struct address_space    *f_mapping;
#ifdef CONFIG_DEBUG_WRITECOUNT
    unsigned long f_mnt_write_state;
#endif
};

同一个超级块下打开的所有文件都会通过双链表连接起来。另外，file结构中主要由对应文件的inode缓存，在下次访问不需要通过dentry查找inode了。还有一个path结构，该结构记录当前文件的emulation项和vfsmount结构。其余记录文件的权限模式、读写位置等信息，还有一个重要的函数表，保存操作文件的一些函数的指针。关键是一个进程在这里可以根据dentry查找到inode。究竟是如何查找的呢？看下dentry的结构:

struct dentry {
    /* RCU lookup touched fields */
    unsigned int d_flags;        /* protected by d_lock */
    seqcount_t d_seq;        /* per dentry seqlock */
    struct hlist_bl_node d_hash;    /* lookup hash list */
    struct dentry *d_parent;    /* parent directory */
    struct qstr d_name;
    struct inode *d_inode;        /* Where the name belongs to - NULL is
                     * negative */
    unsigned char d_iname[DNAME_INLINE_LEN];    /* small names */
 
    /* Ref lookup also touches following */
    unsigned int d_count;        /* protected by d_lock */
    spinlock_t d_lock;        /* per dentry lock */
    const struct dentry_operations *d_op;
    struct super_block *d_sb;    /* The root of the dentry tree */
    unsigned long d_time;        /* used by d_revalidate */
    void *d_fsdata;            /* fs-specific data */
 
    struct list_head d_lru;        /* LRU list */
    /*
     * d_child and d_rcu can share memory
     */
    union {
        struct list_head d_child;    /* child of parent list */
         struct rcu_head d_rcu;
    } d_u;
    struct list_head d_subdirs;    /* our children */
    struct hlist_node d_alias;    /* inode alias list */
};

dentry结构中有指向当前操作文件的inode指针，父目录的dentry，,当然还包括文件名信息。注意这里文件名并没有作为属性保存在inode节点中，而是保存在dentry结构中。因为文件名对于系统来讲主要来查找inode，而通过dentry可以查找到inode，所以这里其实dentry之后就不需要文件名了。通过dentry还可以定位所属 的超级块。该结构中也有个函数表dentry_operations，主要是针对dentry的操作，如增加、删除dentry。一个目录下的所有子目录会形成一个链表，d_subdirs是链表头。而d_child作为一个节点，连接到父目录的子链表中。上节已经提到，系统中所有的dentry通过一个hash表维护起来，以便于查找。表头是全局变量dentry_hashtable.而对于未使用的dentry，内核使用dentry_unused全局链表来组织。因为每个父目录均会有一条自己子目录的链表，所以系统中还存在一个dentry树。

到目前为止已经找到了具体的inode，inode记录文件的真实属性信息，修改时间，是否是脏，以及在内存中的映射信息。看下inode结构

struct inode {
    umode_t            i_mode;
    unsigned short        i_opflags;
    kuid_t            i_uid;
    kgid_t            i_gid;
    unsigned int        i_flags;
 
#ifdef CONFIG_FS_POSIX_ACL
    struct posix_acl    *i_acl;
    struct posix_acl    *i_default_acl;
#endif
 
    const struct inode_operations    *i_op;
    struct super_block    *i_sb;
    struct address_space    *i_mapping;
 
#ifdef CONFIG_SECURITY
    void            *i_security;
#endif
 
    /* Stat data, not accessed from path walking */
    unsigned long        i_ino;
    /*
     * Filesystems may only read i_nlink directly.  They shall use the
     * following functions for modification:
     *
     *    (set|clear|inc|drop)_nlink
     *    inode_(inc|dec)_link_count
     */
    union {
        const unsigned int i_nlink;
        unsigned int __i_nlink;
    };
    dev_t            i_rdev;
    loff_t            i_size;
    struct timespec        i_atime;
    struct timespec        i_mtime;
    struct timespec        i_ctime;
    spinlock_t        i_lock;    /* i_blocks, i_bytes, maybe i_size */
    unsigned short          i_bytes;
    unsigned int        i_blkbits;
    blkcnt_t        i_blocks;
 
#ifdef __NEED_I_SIZE_ORDERED
    seqcount_t        i_size_seqcount;
#endif
 
    /* Misc */
    unsigned long        i_state;
    struct mutex        i_mutex;
 
    unsigned long        dirtied_when;    /* jiffies of first dirtying */
 
    struct hlist_node    i_hash;
    struct list_head    i_wb_list;    /* backing dev IO list */
    struct list_head    i_lru;        /* inode LRU list */
    struct list_head    i_sb_list;
    union {
        struct hlist_head    i_dentry;
        struct rcu_head        i_rcu;
    };
    u64            i_version;
    atomic_t        i_count;
    atomic_t        i_dio_count;
    atomic_t        i_writecount;
    const struct file_operations    *i_fop;    /* former ->i_op->default_file_ops */
    struct file_lock    *i_flock;
    struct address_space    i_data;
#ifdef CONFIG_QUOTA
    struct dquot        *i_dquot[MAXQUOTAS];
#endif
    struct list_head    i_devices;
    union {
        struct pipe_inode_info    *i_pipe;
        struct block_device    *i_bdev;
        struct cdev        *i_cdev;
    };
 
    __u32            i_generation;
 
#ifdef CONFIG_FSNOTIFY
    __u32            i_fsnotify_mask; /* all events this inode cares about */
    struct hlist_head    i_fsnotify_marks;
#endif
 
#ifdef CONFIG_IMA
    atomic_t        i_readcount; /* struct files open RO */
#endif
    void            *i_private; /* fs or device private pointer */
};

inode是一个比较庞大的结构，开头记录了文件的权限信息，如用户、用户组等。该结构中有个函数表inode_operations，记录针对inode的一些操作。inode中还有指向当前文件所属文件系统的超级块结构。当然一个至关重要的就是address_space 类型的i_mapping指针了。其指向一个address_space 结构，记录当前文件在内存中的映射情况。这点等会在分析。除此之外，记录文件的一些时间信息。前文说过，inode在内存中有三种类型：位于内存中但未使用的；位于内存中正在使用的；位于内存中已经发生变化即需要写会到磁盘的，前两种都是全局链表，第三种特定于超级块结构。除此之外，inode还在一个hash表中出现，表头是inode_hashtable,支持根据inode编号和超级块快速访问inode。

到此进程已经找到了具体的inode节点，后来又是如何把文件映射到内存中呢？一个核心结构就是address_space,先看下该结构

struct address_space {
    struct inode        *host;        /* owner: inode, block_device */
    struct radix_tree_root    page_tree;    /* radix tree of all pages */
    spinlock_t        tree_lock;    /* and lock protecting it */
    unsigned int        i_mmap_writable;/* count VM_SHARED mappings */
    struct rb_root        i_mmap;        /* tree of private and shared mappings */
    struct list_head    i_mmap_nonlinear;/*list VM_NONLINEAR mappings */
    struct mutex        i_mmap_mutex;    /* protect tree, count, list */
    /* Protected by tree_lock together with the radix tree */
    unsigned long        nrpages;    /* number of total pages */
    pgoff_t            writeback_index;/* writeback starts here */
    const struct address_space_operations *a_ops;    /* methods */
    unsigned long        flags;        /* error bits/gfp mask */
    struct backing_dev_info *backing_dev_info; /* device readahead, etc */
    spinlock_t        private_lock;    /* for use by the address_space */
    struct list_head    private_list;    /* ditto */
    void            *private_data;    /* ditto */
} __attribute__((aligned(sizeof(long))));

该结构特定于inode节点存在，多个进程可以共享同一个文件，所以在特定于进程的file结构中，有一个指向该inode address_space的指针f_mapping。具体的访问位置记录在file结构中。address_space仅仅负责对文件的映射，该结构管理了对应文件映射的所有内存区域vm_area_struct实例。上面的i_map作为一个红黑树根，关联所有的vm_area_struct,而i_mmap_nonliner是一个双向链表，关联所有非线性映射的vm_area_struct实例。该结构中还记录了所属inode节点的指针host,区域包含的虚拟页面的数量nrpages,当然还有一组操作函数，用于和设备交互，如读取一个页或者写入一个页，设置页面为脏等。关于进程虚拟内存的管理，参考另一篇文章：