本文共 10996 字,大约阅读时间需要 36 分钟。
目录
前言
打开文件描述符表
文件表项
inode节点
总结
前言
本文中涉及到的Linux源码来源于linux 2.6.39.4。就像windows中的句柄一样,学习linux经常会碰到文件描述符,我们都知道文件描述符是一个非负整数,每一个文件描述符都唯一对应了一个打开的文件,那么文件描述符在内核中到底是以什么形式存在的呢?
这个问题是我在读《UNIX环境高级编程》的时候感到疑惑的,在该书的3.10章节中,关于文件共享有以下一段描述:
从这段文字中,可以得出一个结论:在内核中每一个打开的文件都需要由3种数据结构来进行维护。
根据文中内容,这三种数据结构分别为:
1.每个进程对应一张打开文件描述符表,这是进程级数据结构,也就是每一个进程都各自有这样一个数据结构;
2.内核维持一张打开文件表,文件表由多个文件表项组成,这是系统级数据结构,也就是说这样的数据结构是针对于整个内核而言的,每个进程都可共享的;
3.每个打开的文件对应一个i节点(i-node)数据结构(Linux下只有i节点没有v节点),由于这是每一个打开的文件与之对应的,因此这也是一个系统级数据结构,存在于内核中,非进程所独有。
那么,这三种数据结构到底是什么呢?
打开文件描述符表
首先来看第一个数据结构—— 打开文件描述符表。在Linux中,对于每一个进程,都会分配一个PCB数据结构,它其中包含了该进程的所有信息,而在代码实现上,这个数据结构名为task_struct,在linux源码的include/linux/sched.h中可以找到其定义,它是一个很庞大的结构体,部分定义如下:
struct task_struct {
...... /* CPU-specific state of this task */ struct thread_struct thread; /* filesystem information */ struct fs_struct *fs; /* open file information */ struct files_struct *files; /* namespaces */ struct nsproxy *nsproxy; /* signal handlers */ struct signal_struct *signal; struct sighand_struct *sighand; ...... }; 在task_struct中,有一个成员变量名为files,注释中提到这是一个描述打开文件信息的变量,其类型为struct files_struct *,那么现在再接着看files_struct,在linux源码的include/linux/fdtable.h中可以找到其定义,定义如下: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; struct embedded_fd_set close_on_exec_init; struct embedded_fd_set open_fds_init; struct file __rcu * fd_array[NR_OPEN_DEFAULT]; //进程级打开文件描述符表 }; 而这里所要找到的打开文件描述符表,实际上就是files_struct 中的成员struct file * fd_array[NR_OPEN_DEFAULT]它是一个指针数组,数组每一个元素都是一个指向file类型的指针,可想而知,这些指针都会指向一个打开的文件,并且file这一数据结构就是用来描述一个打开的文件的,而我们所说的文件描述符,实际上就是这个指针数组的索引。这也是为什么文件描述符是非负整数。再来看第二种数据结构——文件表项。
文件表项
前面说了,每一个打开文件实际上就是用一个file结构体进行描述的,在linux源码的include/linux/fs.h中可以找到其定义,定义如下: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; //文件路径,包括目录项以及i-node #define f_dentry f_path.dentry #define f_vfsmnt f_path.mnt const struct file_operations *f_op; spinlock_t f_lock; /* f_ep_links, f_flags, no IRQ */ #ifdef CONFIG_SMP int f_sb_list_cpu; #endif atomic_long_t f_count; //文件打开次数 unsigned int f_flags; //文件打开时的flag,对应于open函数的flag参数 fmode_t f_mode; //文件打开时的mode,对应于open函数的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; #endif /* #ifdef CONFIG_EPOLL */ struct address_space *f_mapping; #ifdef CONFIG_DEBUG_WRITECOUNT unsigned long f_mnt_write_state; #endif }; 在file结构体中,不得不再说一下它的f_path成员,这是一个struct path类型的变量,该类型定义于include/linux/path.h:struct path {
struct vfsmount *mnt; struct dentry *dentry; }; 这里的dentry实际上就指向文件所在的目录项了,struct dentry的类型定义于include/linux/dcache.h: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 list_head d_alias; /* inode alias list */ }; 在dentry结构体中,描述了根结点、父节点等等信息,尤其还要注意的是struct inode *d_inode这一变量,它则是指向了一个i-node结点。再回到file结构体中,有一个struct file_operations *f_op变量,其类型定义在include/linux/fs.h中:
struct file_operations {
struct module *owner; loff_t (*llseek) (struct file *, loff_t, int); ssize_t (*read) (struct file *, char __user *, size_t, loff_t *); ssize_t (*write) (struct file *, const char __user *, size_t, loff_t *); ssize_t (*aio_read) (struct kiocb *, const struct iovec *, unsigned long, loff_t); ssize_t (*aio_write) (struct kiocb *, const struct iovec *, unsigned long, loff_t); int (*readdir) (struct file *, void *, filldir_t); unsigned int (*poll) (struct file *, struct poll_table_struct *); long (*unlocked_ioctl) (struct file *, unsigned int, unsigned long); long (*compat_ioctl) (struct file *, unsigned int, unsigned long); int (*mmap) (struct file *, struct vm_area_struct *); int (*open) (struct inode *, struct file *); int (*flush) (struct file *, fl_owner_t id); int (*release) (struct inode *, struct file *); int (*fsync) (struct file *, int datasync); int (*aio_fsync) (struct kiocb *, int datasync); int (*fasync) (int, struct file *, int); int (*lock) (struct file *, int, struct file_lock *); 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); int (*check_flags)(int); int (*flock) (struct file *, int, struct file_lock *); ssize_t (*splice_write)(struct pipe_inode_info *, struct file *, loff_t *, size_t, unsigned int); ssize_t (*splice_read)(struct file *, loff_t *, struct pipe_inode_info *, size_t, unsigned int); int (*setlease)(struct file *, long, struct file_lock **); long (*fallocate)(struct file *file, int mode, loff_t offset, loff_t len); }; 可见,在该成员中包含了所有文件操作相关的函数指针。每一个打开的文件都对应于一个file结构体,在该结构体中,f_flags描述了文件标志,f_pos描述了文件的偏移位置,而在f_path中有含有一个指向一个inode结点的指针,这也符合了《UNIX环境高级编程》中的以下描述:
因此可以知道,文件表项的数据结构就是file结构体,而在实际上内核中也并不存在这样一张文件表,只是每个打开的文件都对应一个file结构体,也就是一个文件表项,打开文件描述符表struct file * fd_array[NR_OPEN_DEFAULT]数组中的每一项都会指向这样一个文件表项,如下图所示:
inode节点
第三种数据结构就是inode节点,在include/linux/fs.h中找到其定义如下:struct inode {
/* RCU path lookup touches following: */ umode_t i_mode; //权限 uid_t i_uid; //用户id gid_t i_gid; //组id const struct inode_operations *i_op; struct super_block *i_sb; spinlock_t i_lock; /* i_blocks, i_bytes, maybe i_size */ unsigned int i_flags; struct mutex i_mutex; unsigned long i_state; 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 list_head i_dentry; struct rcu_head i_rcu; }; unsigned long i_ino; //inode节点号 atomic_t i_count; unsigned int i_nlink; dev_t i_rdev; unsigned int i_blkbits; u64 i_version; loff_t i_size; //文件大小 #ifdef __NEED_I_SIZE_ORDERED seqcount_t i_size_seqcount; #endif struct timespec i_atime; //最后一次访问(access)的时间 struct timespec i_mtime; //最后一次修改(modify)的时间 struct timespec i_ctime; //最后一次改变(change)的时间 blkcnt_t i_blocks; //块数 unsigned short i_bytes; struct rw_semaphore i_alloc_sem; const struct file_operations *i_fop; /* former ->i_op->default_file_ops */ struct file_lock *i_flock; struct address_space *i_mapping; //块地址映射 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 atomic_t i_writecount; #ifdef CONFIG_SECURITY void *i_security; #endif #ifdef CONFIG_FS_POSIX_ACL struct posix_acl *i_acl; struct posix_acl *i_default_acl; #endif void *i_private; /* fs or device private pointer */ }; 代码中只注释了一部分,通过inode结构,可以知道文件数据块的在磁盘上的位置以及文件大小等信息,这样才能使得进程能够通过file结构体来找到磁盘上相应文件的位置来进行文件读写。另外补充一点,关于inode结构体中的struct inode_operations *i_op成员,其数据结构定义在include/linux/fs.h中:
struct inode_operations {
struct dentry * (*lookup) (struct inode *,struct dentry *, struct nameidata *); void * (*follow_link) (struct dentry *, struct nameidata *); int (*permission) (struct inode *, int, unsigned int); int (*check_acl)(struct inode *, int, unsigned int); int (*readlink) (struct dentry *, char __user *,int); void (*put_link) (struct dentry *, struct nameidata *, void *); int (*create) (struct inode *,struct dentry *,int, struct nameidata *); int (*link) (struct dentry *,struct inode *,struct dentry *); int (*unlink) (struct inode *,struct dentry *); int (*symlink) (struct inode *,struct dentry *,const char *); int (*mkdir) (struct inode *,struct dentry *,int); int (*rmdir) (struct inode *,struct dentry *); int (*mknod) (struct inode *,struct dentry *,int,dev_t); int (*rename) (struct inode *, struct dentry *, struct inode *, struct dentry *); void (*truncate) (struct inode *); int (*setattr) (struct dentry *, struct iattr *); int (*getattr) (struct vfsmount *mnt, struct dentry *, struct kstat *); int (*setxattr) (struct dentry *, const char *,const void *,size_t,int); ssize_t (*getxattr) (struct dentry *, const char *, void *, size_t); ssize_t (*listxattr) (struct dentry *, char *, size_t); int (*removexattr) (struct dentry *, const char *); void (*truncate_range)(struct inode *, loff_t, loff_t); int (*fiemap)(struct inode *, struct fiemap_extent_info *, u64 start, u64 len); } ____cacheline_aligned; 可见,在该成员变量所指向的数据结构中,包含了许多函数指针,这些函数指针大多针对于目录、文件操作。总结
进程、打开文件描述符表、文件表项和i-node结点关系如图所示。(暂时忽略进程中0、1和2号文件描述符分别默认为标准输入、标准输出和标准错误的情况)通过以上分析,我们可以得出以下结论:
1.每启动一个进程都会为其分配一个task_struct结构体,在task_struct结构体中含有一个file_struct结构体指针,其所指向的file_struct结构体中,含有一个file*的指针数组fd_array,它就是打开文件描述符表,其中每一个元素都指向一个文件表项,这个数组的索引就是文件描述符。此外,file_struct结构体中的next_fd保存的是下一个分配的文件描述符,它会在调用open和close改变,最终使得每次open返回的都是当前可用的最小文件描述符;
2.每次调用open或者create(内部实际上还是调用的open),都会对新打开的文件分配一个file结构体,并且将打开文件的标志、状态、权限等信息填入这个file结构体中。这个file结构体也叫文件表项;
3.磁盘中的每个文件都对应一个i-node,每一个文件表项都会指向一个文件的i-node,但是同一文件的i-node可以对应多个文件表项(当多次调用open打开同一个文件时就会出现这种情况,不管是同一进程多次打开同一文件(如图中A进程的0号和2号文件描述符对应两个文件表项,但是最终指向同一i-node即同一文件),还是不同进程多次打开同一文件(如图中A进程3号文件描述符和B进程的3号文件描述符));
4.同一进程下的不同文件描述符是可以指向同一文件表项,即最终指向同一文件(如图中A进程的0号文件描述符和1号文件描述符,使用dup函数即可实现)。
5.子进程在创建时会拷贝父进程的打开文件描述符表,因此父子进程是共享文件表项的,如图所示:
而相互独立的不同进程的打开文件描述符表是相互独立的,因此相互独立的多个进程之间的文件描述符可以相同,但是不同进程的文件描述符是不能指向同一文件表项的(除非这个文件描述符是从同一个祖先进程中继承得来的),但是这并不妨碍不同进程访问同一文件(如第3点结论);
6.指向同一文件表项的不同文件描述符(不同进程相同数值的文件描述符也看做不同)共享文件标志、文件偏移等信息;
7.每一个文件表项对应的file结构体中的f_count会记录通过该文件表项打开文件的次数,当f_count计数归0时这个文件表项才会被删除,因此,对于指向同一文件表项的两个不同文件描述符(如子进程所继承的父进程的文件描述符,或同一进程中dup的两个文件描述符指向同一个文件表项),即使其中一个文件描述符关闭了,只要仍然有文件描述符指向这个文件表项,那么就依然能通过这个文件表项访问文件,直到所有指向该文件表项的文件描述符都关闭了才不能再进行访问;
最后再加一张图加以理解:
———————————————— 版权声明:本文为CSDN博主「HerofH_」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。 原文链接:https://blog.csdn.net/qq_28114615/article/details/94590598