struct file {

struct list_head f_list;

struct dentry *f_dentry;

struct vfsmount         *f_vfsmnt;

struct file_operations *f_op;

atomic_t f_count;

unsigned int f_flags;

mode_t f_mode;

loff_t f_pos;

unsigned long f_reada, f_ramax, f_raend, f_ralen, f_rawin;

struct fown_struct f_owner;

unsigned int f_uid, f_gid;

int f_error;

unsigned long f_version;

void *private_data;

}

 

struct fs_struct {

    atomic_t count;

    rwlock_t lock;

    int umask;

    struct dentry * root, * pwd, * altroot;

    struct vfsmount * rootmnt, * pwdmnt, * altrootmnt;

};

结构中有六个指针。前三个是dentry 结构指针，就是 root  pwd altroot; 这些指针各自指向代表着一个"目录项"的dentry 数据结构，里面记录着文件的各项属性，如文件名、访问权限等等。其中pwd 则指向进程当前所在的目录；而root所指向的dentry 结构代表着本进程的"根目录"，那就是当用户登录进入系统时所"看到"的根目录；至于altroot则为用户设置的"替换根目录"，我们以后还会讲到。实际运行时这三个目录不一定都在同一个文件系统中，例如进程的根目录通常是安装于“\”节点上的ext2文件系统中，而当前工作目录则可能安装于/dos的一个DOS文件系统中。在文件系统的操作中这些安装点起着重要的作用而常常要用到，所以后三个指针就各自指向代表着这些"安装" 的vfsmount数据结构。注意，fs_struct 结构中的信息都是与文件系统和进程有关的，带有全局性的（对具体的进程而言），而与具体的已打开文件没有什么关系。例如进程的根目录在ext2文件系统中，当前工作目录在DOS文件系统中，而一个具体的已打开文件却可能是设备文件。

struct files_struct {

    atomic_t count;

    rwlock_t file_lock;

    int max_fds;

    int max_fdset;

    int next_fd;

    struct file ** fd;

    fd_set *close_on_exec;

    fd_set *open_fds;

    fd_set close_on_exec_init;

    fd_set open_fds_init;

    struct file * fd_array[NR_OPEN_DEFAULT];

};

struct dentry_operations {

int (*d_revalidate)(struct dentry *, int);

int (*d_hash) (struct dentry *, struct qstr *);

int (*d_compare) (struct dentry *, struct qstr *, struct qstr *);

int (*d_delete)(struct dentry *);

void (*d_release)(struct dentry *);

void (*d_iput)(struct dentry *, struct inode *);

};

这里d_delete是指向具体文件系统的"删除文件"操作的入口函数，d_release则用于"关闭文件" 操作。还有个函数指针d_compare很有意思，它用于文件名的比对。读者可能感到奇怪，文件名的比对就是字符串的比对，这难道也是因文件系统而异？ 其实不足为奇，想一想：有的文件系统中文件名的长度限于8个字符，有的则可以有255个字符；有的文件系统容许在文件名里有空格，有的则不容许；有的支持汉字，有的则不支持。所以，文件名的比对确实因文件系统而异。

总之，具体文件系统与虚拟文件系统VFS间的界面是一组数据结构，包括file_operations  dentry_operations inode_operations_；还有其它（此处暂从略). 原则上每种文件系统都必须在内核中提供这些数据结构，后面我们还要深入讨论。

在file结构体中维护File Status Flag（file结构体的成员f_flags）和当前读写位置（file结构体的成员f_pos）。

在上图中，进程1和进程2都打开同一文件，但是对应不同的file结构体【通过该进程的task_struct->files_struct中的数组fd_array[xx] 与 fd(即数组下标)来找到本进程打开的该文件对应的file结构体】，因此可以有不同的File Status Flag和读写位置。

file结构体中比较重要的成员还有f_count，表示引用计数（Reference Count），后面我们会讲到，dup、fork等系统调用会导致多个文件描述符指向同一个file结构体，例如有fd1和fd2都引用同一个file结构体，那么它的引用计数就是2，当close(fd1)时并不会释放file结构体，而只是把引用计数减到1，如果再close(fd2)，引用计数就会减到0同时释放file结构体，这才真的关闭了文件。

每个file结构体都指向一个file_operations结构体，这个结构体的成员都是函数指针，指向实现各种文件操作的内核函数。比如在用户程序中read一个文件描述符，read通过系统调用进入内核，然后找到这个文件描述符所指向的file结构体，找到file结构体所指向的file_operations结构体，调用它的read成员所指向的内核函数以完成用户请求。在用户程序中调用lseek、read、write、ioctl、open等函数，最终都由内核调用file_operations的各成员所指向的内核函数完成用户请求。file_operations结构体中的release成员用于完成用户程序的close请求，之所以叫release而不叫close是因为它不一定真的关闭文件，而是减少引用计数，只有引用计数减到0才关闭文件。对于同一个文件系统上打开的常规文件来说，read、write等文件操作的步骤和方法应该是一样的，调用的函数应该是相同的，所以图中的三个打开文件的file结构体指向同一个file_operations结构体。如果打开一个字符设备文件，那么它的read、write操作肯定和常规文件不一样，不是读写磁盘的数据块而是读写硬件设备，所以file结构体应该指向不同的file_operations结构体，其中的各种文件操作函数由该设备的驱动程序实现。每个file结构体都有一个指向dentry结构体的指针，“dentry”是directory entry（目录项）的缩写。我们传给open、stat等函数的参数的是一个路径，例如/home/akaedu/a，需要根据路径找到文件的inode。为了减少读盘次数，内核缓存了目录的树状结构，称为dentry cache，其中每个节点是一个dentry结构体，只要沿着路径各部分的dentry搜索即可，从根目录/找到home目录，然后找到akaedu目录，然后找到文件a。dentry cache只保存最近访问过的目录项，如果要找的目录项在cache中没有，就要从磁盘读到内存中。

每个dentry结构体都有一个指针指向inode结构体。inode结构体保存着从磁盘inode读上来的信息。在上图的例子中，有两个dentry，分别表示/home/akaedu/a和/home/akaedu/b，它们都指向同一个inode，说明这两个文件互为硬链接。inode结构体中保存着从磁盘分区的inode读上来信息，例如所有者、文件大小、文件类型和权限位等。每个inode结构体都有一个指向inode_operations结构体的指针，后者也是一组函数指针指向一些完成文件目录操作的内核函数。和file_operations不同，inode_operations所指向的不是针对某一个文件进行操作的函数，而是影响文件和目录布局的函数，例如添加删除文件和目录、跟踪符号链接等等，属于同一文件系统的各inode结构体可以指向同一个inode_operations结构体。

    file、dentry、inode、super_block这几个结构体组成了VFS的核心概念。对于ext2文件系统来说，在磁盘存储布局上也有inode和超级块的概念，所以很容易和VFS中的概念建立对应关系。而另外一些文件系统格式来自非UNIX系统（例如Windows的FAT32、NTFS），可能没有inode或超级块这样的概念，但为了能mount到Linux系统，也只好在驱动程序中硬凑一下，在Linux下看FAT32和NTFS分区会发现权限位是错的，所有文件都是rwxrwxrwx，因为它们本来就没有inode和权限位的概念，这是硬凑出来的。

补充:

     在这个图上没有反应file_operations与inode的关系,特去查看了源码(/usr/include/fs.h)知

Inode分为内存中的inode和文件系统中的inode，我们这里说的是文件系统中的inode。

Directory，他不是我们通常说的目录，而是一个列表，记录了一个文件/目录名称对应的Inode number

磁盘上的inode 与 内存中(VFS)的 inode 的区别

在容易引起混淆的地方我将把把内存中的inode结构称为VFS inode，而文件系统以EXT2为代表，把Ext2 inode作为磁盘上的inode代表。首先需要分别对内存中的inode与磁盘上的inode做一下简单的描述：

<内存中的inode结构：>VFS inode包含文件访问权限、属主、组、大小、生成时间、访问时间、最后修改时间等信息。它是linux管理文件系统的最基本单位，也是文件系统连接任何子目录、文件的桥梁。inode结构中的静态信息取自物理设备上的文件系统，由文件系统指定的函数填写，它只存在于内存中，可以通过inode缓存访问。虽然每个文件都有相应的inode结点，但是只有在需要的时候系统才会在内存中为其建立相应的inode数据结构，建立的inode结构将形成一个链表，我们可以通过遍历这个链表去得到我们需要的文件结点,VFS也为已分配的inode构造缓存和hash table，以提高系统性能。inode结构中的struct inode_operations *iop为我们提供了一个inode操作列表，通过这个列表提供的函数我们可以对VFS inode结点进行各种操作。每个inode结构都

有一个i结点号i_ino，在同一个文件系统中每个i结点号是唯一的。

<磁盘上的inode：>

EXT2通过使用inode来定义文件系统的结构以及描述系统中每个文件的管理信息，每个文件都有一个inode且只有一个，即使文件中没有数据，其索引结点也是存在的。每个文件用一个单独的Ext2 inode结构来描述，而且每一个inode都有唯一的标志号。Ext2 inode为内存中的inode结构提供了文件的基本信息，随着内存中inode结构的变化，系统也将更新Ext2 inode中

相应的内容。Ext2 inode对应的是Ext2_inode结构。

从上面的描述，我们可以对内存中inode与磁盘中inode做出比较：

位置：VFS inode结构位于内存中，而Ext2_inode位于磁盘。

生存期：VFS inode在需要时才会被建立，如果系统断电，此结构也随之消失。

而Ext2_inode的存在与系统是否上电无关，而且无论文件是否包含

数据，Ext2_inode都是存在的。

唯一性：两者在自己的作用域中都是唯一的。

关系：VFS inode是Ext2 inode的抽象、映射与扩充，而后者是前者的静态

信息部分，也是对前者的具体化、实例化和持久化。

操作：对VFS inode的操作具有通用性，对文件系统inode的操作则是文件系

统相关的，依赖于特定的实现。

组织管理：系统通过VFS inode链表来对其进行组织，并且为了提高访问效率

相应地构造了inode构造缓存和hash table。

Ext2 inode的信息位于EXT2文件系统的划分的块组中，在每个块组

中包含相应的inode位图、inode表指定具体的inode信息，每个

inode对应Ext2_inode结构。

Linux 的 EXT2 文件系统(inode)

*索引节点对象由inode结构体表示，定义文件在linux/fs.h中

*/

struct inode {

        struct hlist_node       i_hash;              

        struct list_head        i_list;              

        struct list_head        i_dentry;            

        unsigned long           i_ino;              

        atomic_t                i_count;            

        umode_t                 i_mode;              

        unsigned int            i_nlink;            

        uid_t                   i_uid;              

        gid_t                   i_gid;              

        kdev_t                  i_rdev;              

        loff_t                  i_size;              

        struct timespec         i_atime;            

        struct timespec         i_mtime;            

        struct timespec         i_ctime;            

        unsigned int            i_blkbits;          

        unsigned long           i_blksize;          

        unsigned long           i_version;          

        unsigned long           i_blocks;            

        unsigned short          i_bytes;            

        spinlock_t              i_lock;              

        struct rw_semaphore     i_alloc_sem;        

        struct inode_operations *i_op;              

        struct file_operations  *i_fop;              

        struct super_block      *i_sb;              

        struct file_lock        *i_flock;            

        struct address_space    *i_mapping;          

        struct address_space    i_data;              

        struct dquot            *i_dquot[MAXQUOTAS];

        struct list_head        i_devices;          

        struct pipe_inode_info  *i_pipe;            

        struct block_device     *i_bdev;            

        unsigned long           i_dnotify_mask;      

        struct dnotify_struct   *i_dnotify;          

        unsigned long           i_state;            

        unsigned long           dirtied_when;        

        unsigned int            i_flags;            

        unsigned char           i_sock;              

        atomic_t                i_writecount;        

        void                    *i_security;        

        __u32                   i_generation;        

        union {

                void            *generic_ip;        

        } u;

};

 

struct inode {

struct list_head i_hash;

struct list_head i_list;

struct list_head i_dentry;

struct list_head i_dirty_buffers;

unsigned long i_ino;

atomic_t i_count;

kdev_t i_dev;

umode_t i_mode;

nlink_t i_nlink;

uid_t i_uid;

gid_t i_gid;

kdev_t i_rdev;

loff_t i_size;

time_t i_atime;

time_t i_mtime;

time_t i_ctime;

unsigned long i_blksize;

unsigned long i_blocks;

unsigned long i_version;

struct semaphore i_sem;

struct semaphore i_zombie;

struct inode_operations *i_op;

struct file_operations *i_fop;

struct super_block *i_sb;

wait_queue_head_t i_wait;

struct file_lock *i_flock;

struct address_space *i_mapping;

struct address_space i_data;

struct dquot *i_dquot[MAXQUOTAS];

struct pipe_inode_info *i_pipe;

struct block_device *i_bdev;

unsigned long i_dnotify_mask;

struct dnotify_struct *i_dnotify;

unsigned long i_state;

unsigned int i_flags;

unsigned char i_sock;

atomic_t i_writecount;

unsigned int i_attr_flags;

__u32 i_generation;

union {

struct minix_inode_info minix_i;

struct ext2_inode_info ext2_i;

struct hpfs_inode_info hpfs_i;

struct ntfs_inode_info ntfs_i;

struct msdos_inode_info msdos_i;

struct umsdos_inode_info umsdos_i;

struct iso_inode_info isofs_i;

struct nfs_inode_info nfs_i;

struct sysv_inode_info sysv_i;

struct affs_inode_info affs_i;

struct ufs_inode_info ufs_i;

struct efs_inode_info efs_i;

struct romfs_inode_info romfs_i;

struct shmem_inode_info shmem_i;

struct coda_inode_info coda_i;

struct smb_inode_info smbfs_i;

struct hfs_inode_info hfs_i;

struct adfs_inode_info adfs_i;

struct qnx4_inode_info qnx4_i;

struct bfs_inode_info bfs_i;

struct udf_inode_info udf_i;

struct ncp_inode_info ncpfs_i;

struct proc_inode_info proc_i;

struct socket socket_i;

struct usbdev_inode_info        usbdev_i;

void *generic_ip;

} u;

}

所以，inode结构中的这个union反映了各种文件系统在部分数据结构上的不同，而file_operations

结构则反应了它们在算法(操作)上的不同。当一个文件系统代表着磁盘(或其它介质)上按特定格式组织的文件时，对每个文件的操作最终都要转化为对某一部分磁盘介质的操作，所以从层次的观点来看，在"文件系统"以下还有一层"设备驱动"。可是，既然设备〔实际上是设备驱动）也是视作文件的，那么作为与文件"平级"的磁盘设备"文件"与作为文件系统"底层"的磁盘"设备"又有什么区别呢？这实际上反映了对磁盘介质上的数据的两种不同观点，一种是把它看成有结构、有组织的数据，而另一种则把它看成线性空间的数据