深刻解析Linux内核I/O剖析（open,write实现）
Linux内核将一切视为文件，那么Linux的文件是什么呢？其既能够是事实上的真正的物理文件，也能够是设备、管道，甚至还能够是一块内存。狭义的文件是指文件系统中的物理文件，而广义的文件则能够是Linux管理的全部对象。这些广义的文件利用VFS机制，以文件系统的形式挂载在Linux内核中，对外提供一致的文件操做接口。
从数值上看，文件描述符是一个非负整数，其本质就是一个句柄，因此也能够认为文件描述符就是一个文件句柄。那么何为句柄呢？一切对于用户透明的返回值，便可视为句柄。用户空间利用文件描述符与内核进行交互；而内核拿到文件描述符后，能够经过它获得用于管理文件的真正的数据结构。
使用文件描述符即句柄，有两个好处：一是增长了安全性，句柄类型对用户彻底透明，用户没法经过任何hacking的方式，更改句柄对应的内部结果，好比Linux内核的文件描述符，只有内核才能经过该值获得对
应的文件结构；二是增长了可扩展性，用户的代码只依赖于句柄的值，这样实际结构的类型就能够随时发生变化，与句柄的映射关系也能够随时改变，这些变化都不会影响任何现有的用户代码。
Linux的每一个进程都会维护一个文件表，以便维护（并非指包含，其中有指针指向file结构（偏移量，引用计数，文件信息））该进程打开文件的信息，包括打开的文件个数、每一个打开文件的偏移量等信息，
内核中进程对应的结构是PCB(task_struct)pcb中的一个指针此进程独有的文件表结构（包含文件描述符表）(struct files_struct)
struct files_struct {
- 大多数状况, 避免动
/* count为文件表files_struct的引用计数 *//* count为文件表files_struct的引用计数 */
atomic_t count;
/* 文件描述符表 */
/*
为何有两个fdtable呢?这是内核的一种优化策略。fdt为指针, 而fdtab为普通变量。通常状况下,
fdt是指向fdtab的, 当须要它的时候, 才会真正动态申请内存。由于默认大小的文件表足以应付大多数
状况, 所以这样就能够避免频繁的内存申请。
这也是内核的经常使用技巧之一。在建立时, 使用普通的变量或者数组, 而后让指针指向它, 做为默认状况使
用。只有当进程使用量超过默认值时, 才会动态申请内存。
*//*
struct fdtable __rcu *fdt;
struct fdtable fdtab;
* written part on a separate cache line in SMP
*/
/* 使用____cacheline_aligned_in_smp能够保证file_lock是以cache
line 对齐的, 避免了false sharing */
spinlock_t file_lock ____cacheline_aligned_in_smp;
/* 用于查找下一个空闲的fd */
int next_fd;
/* 保存执行exec须要关闭的文件描述符的位图 */
struct embedded_fd_set close_on_exec_init;
/* 保存打开的文件描述符的位图 */
struct embedded_fd_set open_fds_init;
/* fd_array为一个固定大小的file结构数组。struct file是内核用于文
件管理的结构。这里使用默认大小的数组, 就是为了能够涵盖
atomic_t count;
/* 文件描述符表 */
/*
为何有两个fdtable呢?这是内核的一种优化策略。fdt为指针, 而fdtab为普通变量。通常状况下,
fdt是指向fdtab的, 当须要它的时候, 才会真正动态申请内存。由于默认大小的文件表足以应付大多数
状况, 所以这样就能够避免频繁的内存申请。
这也是内核的经常使用技巧之一。在建立时, 使用普通的变量或者数组, 而后让指针指向它, 做为默认状况使
用。只有当进程使用量超过默认值时, 才会动态申请内存。
*//*
struct fdtable __rcu *fdt;
struct fdtable fdtab;
* written part on a separate cache line in SMP
*/
/* 使用____cacheline_aligned_in_smp能够保证file_lock是以cache
line 对齐的, 避免了false sharing */
spinlock_t file_lock ____cacheline_aligned_in_smp;
/* 用于查找下一个空闲的fd */
int next_fd;
/* 保存执行exec须要关闭的文件描述符的位图 */
struct embedded_fd_set close_on_exec_init;
/* 保存打开的文件描述符的位图 */
struct embedded_fd_set open_fds_init;
/* fd_array为一个固定大小的file结构数组。struct file是内核用于文
件管理的结构。这里使用默认大小的数组, 就是为了能够涵盖态分配 */
struct file __rcu * fd_array[NR_OPEN_DEFAULT];
};
态分配 */
struct file __rcu * fd_array[NR_OPEN_DEFAULT];
};
每一个文件都有一个32位的数字来表示下一个读写的字节位置，这个数字叫作文件位置。每次打开一个文件，除非明确要求，不然文件位置都被置为0，即文件的开始处，此后的读或写操做都将从文件的开始处执行，但你能够经过执行系统调用LSEEK（随机存储）对这个文件位置进行修改。Linux中专门用了一个数据 结构file来保存打开文件的文件位置，这个结构称为
打开的文件描述（open file description）。这个数据结构的设置是煞费苦心的，由于它与进程的联系很是紧密，能够说这是
VFS中一个比较难于理解的数据结构，
file结构中主要保存了文件位置，此外，还把指向该文件索引节点的指针也放在其中。file结构造成一个双链表，称为系统打开文件表，其最大长度是NR_FILE，在fs.h中定义为8192。
struct file struct list_head f_list; /*全部打开的文件造成一个链表*/ struct dentry *f_dentry; /*指向相关目录项的指针*/ struct vfsmount *f_vfsmnt; /*指向VFS安装点的指针*/ struct file_operations *f_op; /*指向文件操做表的指针*/ mode_t f_mode; /*文件的打开模式*/ loff_t f_pos; /*文件的当前位置*/ unsigned short f_flags; /*打开文件时所指定的标志*/ unsigned short f_count; /*使用该结构的进程数*/ unsigned long f_reada, f_ramax, f_raend, f_ralen, f_rawin; /*预读标志、要预读的最多页面数、上次预读后的文件指针、预读的字节数以及预读的页面数*/ int f_owner; /* 经过信号进行异步I/O数据的传送*/ unsigned int f_uid, f_gid; /*用户的UID和GID*/ int f_error; /*网络写操做的错误码*/ unsigned long f_version; /*版本号*/ void *private_data; /* tty驱动程序所需 */};
- {
内核中，对应于每一个进程都有一个文件描述符表，表示这个进程打开的全部文件。文件描述表中每一项都是一个指针，指向一个用于 描述打开的文件的数据块———file对象，file对象中描述了文件的打开模式，读写位置等重要信息，当进程打开一个文件时，内核就会建立一个新的 file对象。须要注意的是，file对象不是专属于某个进程的，不一样进程的文件描述符表中的指针能够指向相同的file对象，从而共享这个打开的文件。 file对象有引用计数，记录了引用这个对象的文件描述符个数，只有当引用计数为0时，内核才销毁file对象，所以某个进程关闭文件，不影响与之共享同 一个file对象的进程.html
file对象中包含一个指针，指向dentry对象。dentry对象表明一个独立的文件路径，若是一个文件路径被打开屡次，那么会创建多个file对象，但它们都指向同一个dentry对象。
dentry对象中又包含一个指向inode对象的指针。inode对象表明一个独立文件。由于存在硬连接与符号连接，所以不一样的dentry 对象能够指向相同的inode对象.inode 对象包含了最终对文件进行操做所需的全部信息，如文件系统类型、文件的操做方法、文件的权限、访问日期等。
打开文件后，进程获得的文件描述符实质上就是文件描述符表的下标，内核根据这个下标值去访问相应的文件对象，从而实现对文件的操做。
注意，同一个进程屡次打开同一个文件时，内核会建立多个file对象。
当进程使用fork系统调用建立一个子进程后，子进程将继承父进程的文件描述符表，所以在父进程中打开的文件能够在子进程中用同一个描述符访问。
---------------------------------------------------------------open解析---------------------------------------------------
int open(const char *pathname, int flags);int open(const char *pathname, int flags, mode_t mode);
前一个是glibc封装的函数，后一个是系统调用
open源码追踪:
long do_sys_open(int dfd, const char __user *filename, int flags, int mode){ struct open_flags op; /* flags为用户层传递的参数, 内核会对flags进行合法性检查, 并根据mode生成新的flags值赋给 lookup */ int lookup = build_open_flags(flags, mode, &op); /* 将用户空间的文件名参数复制到内核空间 */ char *tmp = getname(filename); int fd = PTR_ERR(tmp); if (!IS_ERR(tmp)) { /* 未出错则申请 fd = get_unused_fd_flags(flags); if (fd >= 0) { struct file *f = do_filp_open(dfd, tmp, &op, lookup); if (IS_ERR(f)) { put_unused_fd(fd); fd = PTR_ERR(f); } else { /* 产生文件打开的通知事件 */ fsnotify_open(f); /* 将文件描述符fd与文件管理结构file对应起来, 即安装 */ fd_install(fd, f); } } putname(tmp); } return fd;}
- 新的文件描述符 */
- /* 申请新的文件管理结构file */
从上面来看，打开文件，内核消耗了2种资源：文件描述符跟内核管理文件结构file
根据POSIX标准，当获取一个新的文件描述符时，要返回最低的未使用的文件描述符。Linux是如何实现这一标准的呢？
在Linux中，经过do_sys_open->get_unused_fd_flags->alloc_fd（0，（flags））来选择文件描述符，代码以下
int alloc_fd(unsigned start, unsigned flags){ struct files_struct *files = current->files;//获取当前进程的对应包含文件描述符表的结构 unsigned int fd; int error; struct fdtable *fdt; /* files为进程的文件表, 下面须要更改文件表, 因此须要先锁文件表 */ spin_lock(&files->file_lock);repeat: /* 获得文件描述符表 */ fdt = files_fdtable(files); /* 从start开始, 查找未用的文件描述符。在打开文件时, start为0 */ fd = start; /* files->next_fd为上一次成功找到的fd的下一个描述符。使用next_fd, 能够快速找到未用的文件描述符；*/ if (fd < files->next_fd) fd = files->next_fd; /* 当小于当前文件表支持的最大文件描述符个数时, 利用位图找到未用的文件描述符。 若是大于max_fds怎么办呢?若是大于当前支持的最大文件描述符, 那它确定是未 用的, 就不须要用位图来确认了。 */ if (fd < fdt->max_fds) fd = find_next_zero_bit(fdt->open_fds->fds_bits, fdt->max_fds, fd); /* expand_files用于在必要时扩展文件表。什么时候是必要的时候呢?好比当前文件描述符已经超过了当 前文件表支持的最大值的时候。 */ error = expand_files(files, fd); if (error < 0) goto out; /* * If we needed to expand the fs array we * might have blocked - try again. */ if (error) goto repeat; /* 只有在start小于next_fd时, 才须要更新next_fd, 以尽可能保证文件描述符的连续性。*/ if (start <= files->next_fd) files->next_fd = fd + 1; /* 将打开文件位图open_fds对应fd的位置置位 */ FD_SET(fd, fdt->open_fds);/* 根据flags是否设置了O_CLOEXEC, 设置或清除fdt->close_on_exec */ if (flags & O_CLOEXEC) FD_SET(fd, fdt->close_on_exec); else FD_CLR(fd, fdt->close_on_exec); error = fd;#if 1 /* Sanity check */ if (rcu_dereference_raw(fdt->fd[fd]) != NULL) { printk(KERN_WARNING "alloc_fd: slot %d not NULL!\n", fd); rcu_assign_pointer(fdt->fd[fd], NULL); }#endifout: spin_unlock(&files->file_lock); return error;}
下面内核使用fd_install将文件管理结构file与fd组合起来，具体操做请看以下代码：
void fd_install(unsigned int fd, struct file *file){ struct files_struct *files = current->files;//得到进程文件表（包含文件描述符表） struct fdtable *fdt; spin_lock(&files->file_lock); /* 获得文件描述符表 */ fdt = files_fdtable(files); BUG_ON(fdt->fd[fd] != NULL); /* 将文件描述符表中的file类型的指针数组中对应fd的项指向file。 这样文件描述符fd与file就创建了对应关系 */ rcu_assign_pointer(fdt->fd[fd], file); spin_unlock(&files->file_lock);}
当用户使用fd与内核交互时，内核能够用fd从fdt->fd[fd]中获得内部管理文件的结构struct file。
-------------------------------------------close(关闭文件）------------------------------
close用于关闭文件描述符。而文件描述符能够是普通文件，也能够是设备，还能够是socket。在关闭时，VFS会根据不一样的文件类型，执行不一样的操做。
下面将经过跟踪close的内核源码来了解内核如何针对不一样的文件类型执行不一样的操做。
1. 分析close源码跟踪
首先，来看一下close的源码实现，代码以下
SYSCALL_DEFINE1(close, unsigned int, fd){ struct file * filp; /* 获得当前进程的文件表 */ struct files_struct *files = current->files; struct fdtable *fdt; int retval; spin_lock(&files->file_lock); /* 经过文件表, 取得文件描述符表 */ fdt = files_fdtable(files); /* 参数fd大于文件描述符表记录的最大描述符, 那么它必定是非法的描述符 */ if (fd >= fdt->max_fds) goto out_unlock; /* 利用fd做为索引, 获得file结构指针 */ filp = fdt->fd[fd]; /* 检查filp是否为NULL。正常状况下, filp必定不为NULL。 */ if (!filp) goto out_unlock; /* 将对应的filp置为0*/ rcu_assign_pointer(fdt->fd[fd], NULL); /* 清除fd在close_on_exec位图中的位 */ FD_CLR(fd, fdt->close_on_exec); /* 释放该fd, 或者说将其置为unused。*/ __put_unused_fd(files, fd); spin_unlock(&files->file_lock); /* 关闭file结构 */ retval = filp_close(filp, files); //这里将引用计数 /* can't restart close syscall because file table entry was cleared */ if (unlikely(retval == -ERESTARTSYS || retval == -ERESTARTNOINTR || retval == -ERESTARTNOHAND || retval == -ERESTART_RESTARTBLOCK)) retval = -EINTR; return retval;out_unlock: spin_unlock(&files->file_lock); return -EBADF;}EXPORT_SYMBOL(sys_close);
请注意26行的__put_unused_fd,源码以下所示：
static void __put_unused_fd(struct files_struct *files, unsigned int fd){ /* 取得文件描述符表 */ struct fdtable *fdt = files_fdtable(files); /* 清除fd在open_fds位图的位 */ __FD_CLR(fd, fdt->open_fds); /* 若是fd小于next_fd, 重置next_fd为释放的fd */ if (fd < files->next_fd) files->next_fd = fd;}
看到这里，咱们来回顾一下以前分析过的alloc_fd函数，就能够总结出完整的Linux文件描述符选择计划：
·Linux选择文件描述符是按从小到大的顺序进行寻找的，文件表中next_fd用于记录下一次开始寻找的起点。当有空闲的描述符时，便可分配。
·当某个文件描述符关闭时，若是其小于next_fd，则next_fd就重置为这个描述符，这样下一次分配就会马上重用这个文件描述符。
以上的策略，总结成一句话就是“Linux文件描述符策略永远选择最小的可用的文件描述符”。——这也是POSIX标准规定的。
从__put_unused_fd退出后，close会接着调用filp_close，其调用路径为filp_close->fput。在fput中，会对当前文件struct file的引用计数减一并检查其值是否为0。当引用计数为0时，表示该struct file没有被其余人使用，则能够调用__fput执行真正的文件释放操做，而后调用要关闭文件所属文件系统的release函数，从而实现针对不一样的文件类型来执行不一样的关闭操做。
下一节让咱们来看看Linux如何针对不一样的文件类型，挂载不一样的文件操做函数files_operations。
每一个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结构体，其中的各类文件操做函数由该设备的驱动程序实现。node
每一个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结构体。缓存
inode结构体有一个指向super_block结构体的指针。super_block结构体保存着从磁盘分区的超级块读上来的信息，例如文件系统类型、块大小等。super_block结构体的s_root成员是一个指向dentry的指针，表示这个文件系统的根目录被mount到哪里，在上图的例子中这个分区被mount到/home目录下。安全
file、dentry、inode、super_block这 几个结构体组成了VFS的核心概念。对于ext2文件系统来讲，在磁盘存储布局上也有inode和超级块的概念，因此很容易和VFS中的概念创建对应关 系。而另一些文件系统格式来自非UNIX系统（例如Windows的FAT3二、NTFS），可能没有inode或超级块这样的概念，但为了能mount到Linux系统，也只好在驱动程序中硬凑一下，在Linux下看FAT32和NTFS分区会发现权限位是错的，全部文件都是rwxrwxrwx，由于它们原本就没有inode和权限位的概念，这是硬凑出来的网络
----------------------------------------------------如下来看自定义的files_operations，以socket举例，有一个struct file_operations结构体定义了不少函数指针，对应不一样的读写关之类的操做，socket的读写关闭等操做分别对应不一样的内核函数
static const struct file_operations socket_file_ops = { .owner = THIS_MODULE, .llseek = no_llseek, .aio_read = sock_aio_read, .aio_write = sock_aio_write, .poll = sock_poll, .unlocked_ioctl = sock_ioctl,#ifdef CONFIG_COMPAT .compat_ioctl = compat_sock_ioctl,#endif .mmap = sock_mmap, .open = sock_no_open, /* special open code to disallow open via /proc */ .release = sock_close, .fasync = sock_fasync, .sendpage = sock_sendpage, .splice_write = generic_splice_sendpage, .splice_read = sock_splice_read,};
在socket中，底层的函数sock_alloc_file用于申请socket文件描述符及文件管理结构file结构。它调用alloc_file来申请管理结构file，并将socket_file_ops这个结构体做为参数，以下所示：
file = alloc_file(&path, FMODE_READ | FMODE_WRITE, &socket_file_ops);
struct file *alloc_file(struct path *path, fmode_t mode, const struct file_operations *fop){ struct file *file; /* 申请一个file */ file = get_empty_filp(); if (!file) return NULL; file->f_path = *path; file->f_mapping = path->dentry->d_inode->i_mapping; file->f_mode = mode; /* 将自定义的文件操做函数指针结构体赋给file->f_op */ file->f_op = fop; ……}
在初始化file结构的时候，socket文件系统将其自定义的文件操做赋给了file->f_op，从而实现了在VFS中能够调用socket文件系统自定义的操做。
----------------------------------遗忘close形成的后果---------------------------
文件描述符没有被释放。
用于文件管理的某些内存结构也没有被释放
对于普通进程来讲，即便应用忘记了关闭文件，当进程退出时，Linux内核也会自动关闭文件，释放内存（详细过程见后文）。可是对于一个常驻进程来讲，问题就变得严重了。
先看第一种状况，若是文件描述符没有被释放，那么再次申请新的描述符时，就不得不扩展当前的文件描述符表，若是文件描述发表始终不释放，个数早晚会达到上限，返回EMFILE错误
-----------------------如何查看文件资源泄露--------------
使用lsof工具
---------------------------------读取文件
Linux中读取文件操做时，最经常使用的就是read函数，其原型以下
ssize_t
read
(
int
fd
,
void
*
buf
,
size_t
count
);
read尝试从fd中读取count个字节到buf中，并返回成功读取的字节数，同时将文件偏移向前移动相同的字节数。返回0的时候则表示已经到了“文件尾”。read还有可能读取比count小的字节数。
使用read进行数据读取时，要注意正确地处理错误，也是说read返回-1时，若是errno为EAGAIN、EWOULDBLOCK或EINTR，通常状况下都不能将其视为错误。由于前二者是因为当前fd为非阻塞且没有可读数据时返回的，后者是因为read被信号中断所形成的。这两种状况基本上均可以视为正常状况。
SYSCALL_DEFINE3(read, unsigned int, fd, char __user *, buf, size_t, count){ struct file *file; ssize_t ret = -EBADF; int fput_needed; /* 经过文件描述符fd获得管理结构file */ file = fget_light(fd, &fput_needed); if (file) { /* 获得文件的当前偏移量 */ loff_t pos = file_pos_read(file); /* 利用vfs进行真正的read */ ret = vfs_read(file, buf, count, &pos); /* 更新文件偏移量 */ file_pos_write(file, pos); /* 归还管理结构file, 若有必要, 就进行引用计数操做*/ fput_light(file, fput_needed); } return ret;}
查看VFS_read代码：
ssize_t vfs_read(struct file *file, char __user *buf, size_t count, loff_t *pos){ ssize_t ret; /* 检查文件是否为读取打开 */ if (!(file->f_mode & FMODE_READ)) return -EBADF; /* 检查文件是否支持读取操做 */ if (!file->f_op || (!file->f_op->read && !file->f_op->aio_read)) return -EINVAL; /* 检查用户传递的参数buf的地址是否可写 */ if (unlikely(!access_ok(VERIFY_WRITE, buf, count))) return -EFAULT; /* 检查要读取的文件范围实际可读取的字节数 */ ret = rw_verify_area(READ, file, pos, count); if (ret >= 0) { /* 根据上面的结构, 调整要读取的字节数 */ count = ret; /* 若是定义read操做, 则执行定义的read操做 若是没有定义read操做, 则调用do_sync_read—其利用异步aio_read来完成同步的read操做。 */ if (file->f_op->read) ret = file->f_op->read(file, buf, count, pos); else ret = do_sync_read(file, buf, count, pos); if (ret > 0) { /* 读取了必定的字节数, 进行通知操做 */ fsnotify_access(file); /* 增长进程读取字节的统计计数 */ add_rchar(current, ret); } /* 增长进程系统调用的统计计数 */ inc_syscr(current); } return ret;}
上面的代码为read公共部分的源码分析，具体的读取动做是由实际的文件系统决定的。
1.6.2 部分读取
前文中介绍read能够返回比指定count少的字节数，那么何时会发生这种状况呢？最直接的想法是在fd中没有指定count大小的数据时。但这种状况下，系统是否是也能够阻塞到知足count个字节的数据呢？那么内核到底采起的是哪一种策略呢？
让咱们来看看socket文件系统中UDP协议的read实现：socket文件系统只定义了aio_read操做，没有定义普通的read函数。根据前文，在这种状况下
do_sync_read会利用aio_read实现同步读操做。
其调用链为sock_aio_read->do_sock_read->__sock_recvmsg->__sock_recvmsg_nose->udp_recvmsg，代码以下所示：
int udp_recvmsg(struct kiocb *iocb, struct sock *sk, struct msghdr *msg, size_t len, int noblock, int flags, int *addr_len) …… ulen = skb->len - sizeof(struct udphdr); copied = len; if (copied > ulen) copied = ulen; ……
当UDP报文的数据长度小于参数len时，就会只复制真正的数据长度，那么对于read操做来讲，返回的读取字节数天然就小于参数count了。
看到这里，是否已经获得本小节开头部分问题的答案了呢？当fd中的数据不够count大小时，read会返回当前能够读取的字节数？很惋惜，答案是否认的。这种行为彻底由具体实现来决定。即便同为socket文件系统，TCP套接字的读取操做也会与UDP不一样。当TCP的fd的数据不足时，read操做很可能会阻塞，而不是直接返回。注：TCP是否阻塞，取决于当前缓存区可用数据多少，要读取的字节数，以及套接字设置的接收低水位大小。
所以在调用read的时候，只能根据read接口的说明，当心处理全部的状况，而不能主观臆测内核的实现。好比本文中的部分读取状况，阻塞和直接返回两种策略同时存在。
------------------------------------write跟read的实现差很少，这里就不列出来了，主要讨论多个文件同时写-------------
前面说过，文件的读写操做都是从当前文件的偏移处开始的。这个文件偏移量保存在文件表中，而每一个进程都有一个文件表。那么当多个进程同时写一个文件时，即便对write进行了锁保护，在进行串行写操做时，文件依然不可避免地会被写乱。根本缘由就在于文件偏移量是进程级别的。
当使用O_APPEND以追加的形式来打开文件时，每次写操做都会先定位到文件末尾，而后再执行写操做。
Linux下大多数文件系统都是调用generic_file_aio_write来实现写操做的。在generic_file_aio_write中，有以下代码：
mutex_lock(&inode->i_mutex);//加锁 blk_start_plug(&plug); ret = __generic_file_aio_write(iocb, iov, nr_segs, &iocb->ki_pos);//发现文件是追加打开，直接从inode读取最新文件大小做为偏移量mutex_unlock(&inode->i_mutex); //解锁
这里有一个关键的语句，就是使用mutex_lock对该文件对应的inode进行保护，而后调用__generic_file_aio_write->generic_write_check。其部分代码以下：
if (file->f_flags & O_APPEND) *pos = i_size_read(inode);
上面的代码中，若是发现文件是以追加方式打开的，则将从inode中读取到的最新文件大小做为偏移量，而后经过__generic_file_aio_write再进行写操做，这样就能保证写操做是在文件末尾追加的。
----------------------------------文件描述符的复制----------------------------
int dup(int oldfd);int dup2(int oldfd, int newfd);
·dup会使用一个最小的未用文件描述符做为复制后的文件描述符。
·dup2是使用用户指定的文件描述符newfd来复制oldfd的。若是newfd已是打开的文件描述符，Linux会先关闭newfd，而后再复制oldfd。
dup的实现
SYSCALL_DEFINE1(dup, unsigned int, fildes){ int ret = -EBADF; /* 必须先获得文件管理结构file, 同时也是对描述符fildes的检查 */ struct file *file = fget_raw(fildes); if (file) { /* 获得一个未使用的文件描述符 */ ret = get_unused_fd(); if (ret >= 0) { /* 将文件描述符与file指针关联起来 */ fd_install(ret, file); } else fput(file); } return ret;}
在dup中调用get_unused_fd，只是获得一个未用的文件描述符，那么如何实如今dup接口中使用最小的未用文件描述符呢？这就须要回顾1.4.2节中总结过的Linux文件描述符的选择策略了。
Linux老是尝试给用户最小的未用文件描述符，因此get_unused_fd获得的文件描述符始终是最小的可用文件描述符。
查看dup代码实现的第11行
void fd_install(unsigned int fd, struct file *file){ struct files_struct *files = current->files; struct fdtable *fdt; /* 对文件表进行保护 */ spin_lock(&files->file_lock); /* 获得文件表 */ fdt = files_fdtable(files); BUG_ON(fdt->fd[fd] != NULL); /* 让文件表中fd对应的指针等于该文件关联结构file */ rcu_assign_pointer(fdt->fd[fd], file); spin_unlock(&files->file_lock);}
在fd_install中，fd与file的关联是利用fd来做为指针数组的索引的，从而让对应的指针指向file。对于dup来讲，这意味着数组中两个指针都指向了同一个file。而file是进程中真正的管理文件的结构，文件偏移等信息都是保存在file中的。这就意味着，当使用oldfd进行读写操做时，不管是oldfd仍是newfd的文件偏移都会发生变化。
---------------------看一下dup2的实现-------------------
SYSCALL_DEFINE2(dup2, unsigned int, oldfd, unsigned int, newfd){ /* 若是oldfd与newfd相等, 这是一种特殊的状况 */ if (unlikely(newfd == oldfd)) { /* corner case */ struct files_struct *files = current->files; int retval = oldfd; /* 检查oldfd的合法性, 若是是合法的fd, 则直接返回oldfd的值； 若是是不合法的, 则返回EBADF */ rcu_read_lock(); if (!fcheck_files(files, oldfd)) retval = -EBADF; rcu_read_unlock(); return retval; } /* 若是oldfd与newfd不一样, 则利用sys_dup3来实现dup2 */
return sys_dup3(oldfd, newfd, 0);}
------------------------------------文件的元数据获取--------------
什么是文件的元数据呢？其包括文件的访问权限、上次访问的时间戳、全部者、全部组、文件大小等信息。
int stat(const char *path, struct stat *buf);int fstat(int fd, struct stat *buf);int lstat(const char *path, struct stat *buf);
这三个函数均可用于获得文件的基本信息，区别在于stat获得路径path所指定的文件基本信息，fstat获得文件描述符fd指定文件的基本信息，而lstat与stat则基本相同，只有当path是一个连接文件时，lstat获得的是连接文件本身自己的基本信息而不是其指向文件的信息。
所获得的文件基本信息的结果struct stat的结构以下：
struct stat { dev_t st_dev; /* ID of device containing file */ ino_t st_ino; /* inode number */ mode_t st_mode; /* protection */ nlink_t st_nlink; /* number of hard links */ uid_t st_uid; /* user ID of owner */ gid_t st_gid; /* group ID of owner */ dev_t st_rdev; /* device ID (if special file) */ off_t st_size; /* total size, in bytes */ blksize_t st_blksize; /* blocksize for file system I/O */ blkcnt_t st_blocks; /* number of 512B blocks allocated */ time_t st_atime; /* time of last access */ time_t st_atime; /* time of last access */
time_t st_mtime; /* time of last modification */
time_t st_ctime; /* time of last status change */
};
time_t st_atime; /* time of last access */
time_t st_mtime; /* time of last modification */
time_t st_ctime; /* time of last status change */
};
st_mode要注意一点的是：st_mode，其注释不只仅是protection,同时也表示文件类型，好比是普通文件仍是目录
stat代码实现：
- {
SYSCALL_DEFINE2(stat, const char __user *, filename,struct __old_kernel_stat __user *, statbuf) struct kstat stat; int error; /* vfs_stat用于读取文件元数据至stat */ error = vfs_stat(filename, &stat); if (error) return error; /* 这里仅是从内核的元数据结构stat复制到用户层的数据结构statbuf中 */ return cp_old_stat(&stat, statbuf);}
第5行，vfs_stat是关键。进入vfs_stat->vfs_fstatat->vfs_getattr，代码以下：
int vfs_getattr(struct vfsmount *mnt, struct dentry *dentry, struct kstat *stat){ struct inode *inode = dentry->d_inode; int retval; /* 对获取inode属性操做进行安全性检查 */ retval = security_inode_getattr(mnt, dentry); if (retval) return retval; /* 若是该文件系统定义了这个inode的自定义操做函数, 就执行它 */ if (inode->i_op->getattr) return inode->i_op->getattr(mnt, dentry, stat); /* 若是文件系统没有定义inode的操做函数, 则执行通用的函数 */ generic_fillattr(inode, stat); return 0;}
不失通常性，也能够经过查看第13行的generic_fillattr来进一步了解，代码以下：
void generic_fillattr(struct inode *inode, struct kstat *stat){ stat->dev = inode->i_sb->s_dev; stat->ino = inode->i_ino; stat->mode = inode->i_mode; stat->nlink = inode->i_nlink; stat->uid = inode->i_uid; stat->gid = inode->i_gid; stat->rdev = inode->i_rdev; stat->size = i_size_read(inode); stat->atime = inode->i_atime; stat->mtime = inode->i_mtime; stat->ctime = inode->i_ctime; stat->blksize = (1 << inode->i_blkbits); stat->blocks = inode->i_blocks;}
从这里能够看出，全部的文件元数据均保存在inode中，而inode是Linux也是全部类Unix文件系统中的一个概念。这样的文件系统通常将存储区域分为两类，一类是保存文件对象的元信息数据，即inode表；另外一类是真正保存文件数据内容的块，全部inode彻底由文件系统来维护。可是Linux也能够挂载非类Unix的文件系统，这些文件系统自己没有inode的概念，怎么办？Linux为了让VFS有统一的处理流程和方法，就必需要求那些没有inode概念的文件系统，根据本身系统的特色——如何维护文件元数据，生成“虚拟的”inode以供Linux内核使用。
相关文章
- 1. Linux 内核深度剖析与实践
- 2. Linux 内核剖析
- 3. linux 内核poll/select/epoll实现剖析
- 4. Linux内核剖析-----IO复用函数poll内核源码剖析
- 5. HBase 内核深度剖析
- 6. 深刻剖析Nodejs的异步IO
- 7. LINUX内核研究----IO复用函数epoll内核源代码深度剖析
- 8. yii2深刻理解以内核解析
- 9. linux 内核宏container_of剖析
- 10. 深刻剖析HashMap实现原理
- 更多相关文章...
- • XML DOM 解析器 - XML DOM 教程
- • TCP滑动窗口机制深度剖析 - TCP/IP教程
- • 互联网组织的未来：剖析GitHub员工的任性之源
- • ☆基于Java Instrument的Agent实现
相关标签/搜索
每日一句
-
每一个你不满意的现在，都有一个你没有努力的曾经。
欢迎关注本站公众号,获取更多信息
