最近一个项目做了一个模拟u盘的设备，但是在read虚拟u盘的内容时必须每次都从磁盘内读取，而不是从系统的cache中读取，由于这个问题，就查资料看了下read的系统调用，以及文件系统的一些内容。由于文件系统涉及面较广，例如虚拟文件系统（VFS），页缓存，块缓存，数据同步等内容，不可能全部分析到位，这里只记录和read有关的两种使用方式。cached IO和direct IO。

1. 什么是系统调用

首先系统调用能做那些事呢？概括来说，大概有下面这些事需要系统调用来实现。

1. 控制硬件：系统调用往往作为硬件资源和用户空间的抽象接口，比如读写文件时用到的write/read调用。
2. 设置系统状态或读取内核数据：因为系统调用是用户空间和内核的唯一通讯手段，所以用户设置系统状态，比如开/关某项内核服务（设置某个内核变量），或读取内核数据都必须通过系统调用。比如getpgid、getpriority、setpriority、sethostname
3. 进程管理：用来保证系统中进程能以多任务在虚拟内存环境下得以运行。比如 fork、clone、execve、exit等

那为什么一定要用系统调用来访问操作系统的内容呢，其实这可以看做对内核的保护，linux分为用户空间和内核空间，而用户空间是不允许访问内核空间的数据的。那么在用户空间的程序需要访问内核空间的资源时就必须通过系统调用这个中间人来实现。这样可以对用户空间的行为进行限制，只有特定的得到许可的（事先规定的）用户空间行为才能进入内核空间。一句话，系统调用是内核给用户空间提供的一个可以访问内核资源的一个接口。

另外多说一句，从用户进程切换到内核进程只有两种方式，一种就是系统调用，另一种是中断。

要实现系统调用，首先要能从用户空间切换到内核空间，这个切换在IA-32系统上是用汇编指令int $0x80来引发软件中断实现的。这部分内容一般是在C标准库中实现的。进入内核空间后，系统调用中枢处理代码（所有的系统调用都由一处中枢代码处理）根据传递的参数（参数是有寄存器传递的包括唯一的系统调用号）和一个静态表分别执行不同的函数。例如read系统调用，0x80 中断处理程序接管执行后，先检查其系统调用号，然后根据系统调用号查找系统调用表，并从系统调用表中得到处理 read 系统调用的内核函数 sys_read ，最后传递参数并运行 sys_read 函数。至此，内核真正开始处理 read 系统调用（sys_read 是 read 系统调用的内核入口）。

2. read系统调用在内核空间的处理层次模型

如图所示为read 系统调用在核心空间中所要经历的层次模型。从图中看出：对于磁盘的一次读请求，首先经过虚拟文件系统层（vfs layer），其次是具体的文件系统层（例如 ext2），接下来是 cache 层（page cache 层）、通用块层（generic block layer）、IO 调度层（I/O scheduler layer）、块设备驱动层（block device driver layer），最后是物理块设备层（block device layer）。

• 虚拟文件系统层的作用：屏蔽下层具体文件系统操作的差异，为上层的操作提供一个统一的接口。正是因为有了这个层次，所以可以把设备抽象成文件，使得操作设备就像操作文件一样简单。
• 在具体的文件系统层中，不同的文件系统（例如 ext2 和 NTFS）具体的操作过程也是不同的。每种文件系统定义了自己的操作集合。关于文件系统的更多内容，请参见参考资料。
• 引入 cache 层的目的是为了提高 linux 操作系统对磁盘访问的性能。 Cache 层在内存中缓存了磁盘上的部分数据。当数据的请求到达时，如果在 cache 中存在该数据且是最新的，则直接将数据传递给用户程序，免除了对底层磁盘的操作，提高了性能。
• 通用块层的主要工作是：接收上层发出的磁盘请求，并最终发出 IO 请求。该层隐藏了底层硬件块设备的特性，为块设备提供了一个通用的抽象视图。
• IO 调度层的功能：接收通用块层发出的 IO 请求，缓存请求并试图合并相邻的请求（如果这两个请求的数据在磁盘上是相邻的）。并根据设置好的调度算法，回调驱动层提供的请求处理函数，以处理具体的 IO 请求。
• 驱动层中的驱动程序对应具体的物理块设备。它从上层中取出 IO 请求，并根据该 IO 请求中指定的信息，通过向具体块设备的设备控制器发送命令的方式，来操纵设备传输数据。
• 设备层中都是具体的物理设备。定义了操作具体设备的规范。

 3. 相关的内核数据结构

• dentry（目录项） ： 联系了文件名和文件的 i 节点
• inode（索引节点） ： 文件 i 节点，保存文件标识、权限和内容等信息
• file ： 保存文件的相关信息和各种操作文件的函数指针集合
• file_operations ：操作文件的函数接口集合
• address_space ：描述文件的 page cache 结构以及相关信息，并包含有操作 page cache 的函数指针集合
• address_space_operations ：操作 page cache 的函数接口集合
• bio ： IO 请求的描述

以上结构的定义可参考VFS文件系统以及内核源码。

数据结构之间的关系如下图所示：

上图展示了上述各个数据结构（除了 bio）之间的关系。可以看出：由 dentry 对象可以找到 inode 对象，从 inode 对象中可以取出 address_space 对象，再由 address_space 对象找到 address_space_operations 对象。File 对象可以根据当前进程描述符中提供的信息取得，进而可以找到 dentry 对象、 address_space 对象和 file_operations 对象。

4. read系统调用的过程

4.1. 前提条件

对于具体的一次 read 调用，内核中可能遇到的处理情况很多。这里举例其中的一种情况：

• 要读取的文件已经存在
• 文件经过 page cache
• 要读的是普通文件
• 磁盘上文件系统为 ext2 文件系统，有关 ext2 文件系统的相关内容，参见参考资料

4.2. read前的open

open系统调用对应的内核函数是sys_open。sys_open调用do_sys_open：

long do_sys_open(int dfd, const char __user *filename, int flags, int mode)
{
struct open_flags op;
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_install(fd, f);
}
}
putname(tmp);
}
return fd;
}

其中主要代码的解释：

• get_unused_fd_flags：取回一个未被使用的文件描述符（每次都会选取最小的未被使用的文件描述符）。
• do_filp_open：调用 open_namei() 函数取出和该文件相关的 dentry 和 inode （因为前提指明了文件已经存在，所以 dentry 和 inode 能够查找到，不用创建），然后调用 dentry_open() 函数创建新的 file 对象，并用 dentry 和 inode 中的信息初始化 file 对象（文件当前的读写位置在 file 对象中保存）。注意到 dentry_open() 中有一条语句：f->f_op = fops_get(inode->i_fop);
  这个赋值语句把和具体文件系统相关的，操作文件的函数指针集合赋给了 file 对象的 f _op 变量（这个指针集合是保存在 inode 对象中的），在接下来的 sys_read 函数中将会调用 file->f_op 中的成员 read 。
• fd_install：以文件描述符为索引，关联当前进程描述符和上述的 file 对象，为之后的 read 和 write 等操作作准备。

函数最后返回该文件的文件描述符。

4.3. 虚拟文件系统层的处理

read系统调用对应的内核函数是sys_read。实现如下（read_write.c）：

SYSCALL_DEFINE3(read, unsigned int, fd, char __user *, buf, size_t, count)
{
 struct file *file;
 ssize_t ret = -EBADF;
 int fput_needed;

file = fget_light(fd, &fput_needed);
 if (file) {
 loff_t pos = file_pos_read(file);
 ret = vfs_read(file, buf, count, &pos);
 file_pos_write(file, pos);
 fput_light(file, fput_needed);
 }

return ret;
}

代码解析：

• fget_light() ：根据 fd 指定的索引，从当前进程描述符中取出相应的 file 对象。
• 调用 file_pos_read() 函数取出此次读写文件的当前位置。
• 调用 vfs_read() 执行文件读取操作，而这个函数最终调用 file->f_op.read() 指向的函数，代码如下：

if (file->f_op->read)

ret = file->f_op->read(file, buf, count, pos);

• 调用 file_pos_write() 更新文件的当前读写位置。
• 调用 fput_light() 更新文件的引用计数。
• 最后返回读取数据的字节数。

到此，虚拟文件系统层所做的处理就完成了，控制权交给了 ext2 文件系统层。

4.4. ext2层及后续的处理

查看ext2_file_operations的初始化，我们可以看到，ext2的read指向do_sync_read，而在do_sync_read中又调用了ext2的aio_read函数，而aio_read指向generic_file_aio_read，所以generic_file_aio_read就是ext2层的入口。

generic_file_aio_read的大致走向（filemap.c）：

4.4.1. 文件的page cache结构

在 Linux 操作系统中，当应用程序需要读取文件中的数据时，操作系统先分配一些内存，将数据从存储设备读入到这些内存中，然后再将数据分发给应用程序；当需要往文件 中写数据时，操作系统先分配内存接收用户数据，然后再将数据从内存写到磁盘上。文件 Cache 管理指的就是对这些由操作系统分配，并用来存储文件数据的内存的管理。 Cache 管理的优劣通过两个指标衡量：一是 Cache 命中率，Cache 命中时数据可以直接从内存中获取，不再需要访问低速外设，因而可以显著提高性能；二是有效 Cache 的比率，有效 Cache 是指真正会被访问到的 Cache 项，如果有效 Cache 的比率偏低，则相当部分磁盘带宽会被浪费到读取无用 Cache 上，而且无用 Cache 会间接导致系统内存紧张，最后可能会严重影响性能。

文件 Cache 是文件数据在内存中的副本，因此文件 Cache 管理与内存管理系统和文件系统都相关：一方面文件 Cache 作为物理内存的一部分，需要参与物理内存的分配回收过程，另一方面文件 Cache 中的数据来源于存储设备上的文件，需要通过文件系统与存储设备进行读写交互。从操作系统的角度考虑，文件 Cache 可以看做是内存管理系统与文件系统之间的联系纽带。因此，文件 Cache 管理是操作系统的一个重要组成部分，它的性能直接影响着文件系统和内存管理系统的性能。

Linux内核中文件预读算法的具体过程是这样的：对于每个文件的第一个读请求，系统读入所请求的页面并读入紧随其后的少数几个页面(不少于一 个页面，通常是三个页面)，这时的预读称为同步预读。对于第二次读请求，如果所读页面不在Cache中，即不在前次预读的group中，则表明文件访问不 是顺序访问，系统继续采用同步预读；如果所读页面在Cache中，则表明前次预读命中，操作系统把预读group扩大一倍，并让底层文件系统读入 group中剩下尚不在Cache中的文件数据块，这时的预读称为异步预读。无论第二次读请求是否命中，系统都要更新当前预读group的大小。此外，系 统中定义了一个window，它包括前一次预读的group和本次预读的group。任何接下来的读请求都会处于两种情况之一：第一种情况是所请求的页面 处于预读window中，这时继续进行异步预读并更新相应的window和group；第二种情况是所请求的页面处于预读window之外，这时系统就要 进行同步预读并重置相应的window和group。

文件被分割为一个个以 page 大小为单元的数据块,这些数据块（页）被组织成一个多叉树（称为 radix 树）。树中所有叶子节点为一个个页帧结构（struct page），表示了用于缓存该文件的每一个页。在叶子层最左端的第一个页保存着该文件的前4096个字节（如果页的大小为4096字节），接下来的页保存着文件第二个4096个字节，依次类推。树中的所有中间节点为组织节点，指示某一地址上的数据所在的页。此树的层次可以从0层到6层，所支持的文件大小从0字节到16 T 个字节。树的根节点指针可以从和文件相关的 address_space 对象（该对象保存在和文件关联的 inode 对象中）中取得。

一个物理页可能由多个不连续的物理磁盘块组成。也正是由于页面中映射的磁盘块不一定连续，所以在页高速缓存中检测特定数据是否已被缓存就变得不那么容易了。另外linux页高速缓存对被缓存页的范围定义的非常宽。缓存的目标是任何基于页的对象，这包含各种类型的文件和各种类型的内存映射。为了满足普遍性要求，linux使用定义在linux/fs.h中的结构体address_space结构体描述页高速缓存中的页面。

4.4.2. ext2层的处理

do_generic_file_read做的工作：

• 根据文件当前的读写位置，在 page cache 中找到缓存请求数据的 page
• 如果该页已经最新，将请求的数据拷贝到用户空间
• 否则， Lock 该页
• 调用 readpage 函数向磁盘发出添页请求（当下层完成该 IO 操作时会解锁该页），代码：error = mapping->a_ops->readpage(filp, page);

• 再一次 lock 该页，操作成功时，说明数据已经在 page cache 中了，因为只有 IO 操作完成后才可能解锁该页。此处是一个同步点，用于同步数据从磁盘到内存的过程。
• 解锁该页
• 到此为止数据已经在 page cache 中了，再将其拷贝到用户空间中（之后 read 调用可以在用户空间返回了）

到此，我们知道：当页上的数据不是最新的时候，该函数调用 mapping->a_ops->readpage 所指向的函数（变量 mapping 为 inode 对象中的 address_space 对象），那么这个函数到底是什么呢？在Ext2文件系统中，readpage指向ext2_readpage。

4.4.3. page cache层的处理

从上文得知：ext2_readpage 函数是该层的入口点。该函数调用 mpage_readpage 函数，如下mpage_readpage 函数的代码。

int mpage_readpage(struct page *page, get_block_t get_block)
{
 struct bio *bio = NULL;
 sector_t last_block_in_bio = 0;
 struct buffer_head map_bh;
 unsigned long first_logical_block = 0;

 map_bh.b_state = 0;
 map_bh.b_size = 0;
 bio = do_mpage_readpage(bio, page, 1, &last_block_in_bio,
 &map_bh, &first_logical_block, get_block);
 if (bio)
 mpage_bio_submit(READ, bio);
 return 0;
}

该函数首先调用函数 do_mpage_readpage 函数创建了一个 bio 请求，该请求指明了要读取的数据块所在磁盘的位置、数据块的数量以及拷贝该数据的目标位置——缓存区中 page 的信息。然后调用 mpage_bio_submit 函数处理请求。 mpage_bio_submit 函数则调用 submit_bio 函数处理该请求，后者最终将请求传递给函数 generic_make_request ，并由 generic_make_request 函数将请求提交给通用块层处理。

到此为止， page cache 层的处理结束。

4.4.4. 通用块层的处理

generic_make_request 函数是该层的入口点，该层只有这一个函数处理请求。函数的代码参见blk-core.c。

主要操作：
根据 bio 中保存的块设备号取得请求队列 q
检测当前 IO 调度器是否可用，如果可用，则继续；否则等待调度器可用
调用 q->make_request_fn 所指向的函数将该请求（bio）加入到请求队列中
到此为止，通用块层的操作结束。

4.4.5. IO调度层的处理

对 make_request_fn 函数的调用可以认为是 IO 调度层的入口，该函数用于向请求队列中添加请求。该函数是在创建请求队列时指定的，代码如下（blk_init_queue 函数中）：
q->request_fn = rfn;
blk_queue_make_request(q, __make_request);
函数 blk_queue_make_request 将函数 __make_request 的地址赋予了请求队列 q 的 make_request_fn 成员，那么， __make_request 函数才是 IO 调度层的真实入口。
__make_request 函数的主要工作为：

1. 检测请求队列是否为空，若是，延缓驱动程序处理当前请求（其目的是想积累更多的请求，这样就有机会对相邻的请求进行合并，从而提高处理的性能），并跳到3，否则跳到2。
2. 试图将当前请求同请求队列中现有的请求合并，如果合并成功，则函数返回，否则跳到3。
3. 该请求是一个新请求，创建新的请求描述符，并初始化相应的域，并将该请求描述符加入到请求队列中，函数返回。

将请求放入到请求队列中后，何时被处理就由 IO 调度器的调度算法决定了（有关 IO 调度器的算法内容请参见参考资料）。一旦该请求能够被处理，便调用请求队列中成员 request_fn 所指向的函数处理。这个成员的初始化也是在创建请求队列时设置的：
q->request_fn = rfn;
blk_queue_make_request(q, __make_request);
第一行是将请求处理函数 rfn 指针赋给了请求队列的 request_fn 成员。而 rfn 则是在创建请求队列时通过参数传入的。
对请求处理函数 request_fn 的调用意味着 IO 调度层的处理结束了。

4.4.6. 块设备驱动层的处理

request_fn 函数是块设备驱动层的入口。它是在驱动程序创建请求队列时由驱动程序传递给 IO 调度层的。

IO 调度层通过回调 request_fn 函数的方式，把请求交给了驱动程序。而驱动程序从该函数的参数中获得上层发出的 IO 请求，并根据请求中指定的信息操作设备控制器（这一请求的发出需要依据物理设备指定的规范进行）。

到此为止，块设备驱动层的操作结束。

4.4.7. 块设备层的处理

接受来自驱动层的请求，完成实际的数据拷贝工作等等。同时规定了一系列规范，驱动程序必须按照这个规范操作硬件。

4.4.8. 后续工作

当设备完成了 IO 请求之后，通过中断的方式通知 cpu ，而中断处理程序又会调用 request_fn 函数进行处理。

当驱动再次处理该请求时，会根据本次数据传输的结果通知上层函数本次 IO 操作是否成功，如果成功，上层函数解锁 IO 操作所涉及的页面。

该页被解锁后， 就可以再次成功获得该锁（数据的同步点），并继续执行程序了。之后，函数 sys_read 可以返回了。最终 read 系统调用也可以返回了。

至此， read 系统调用从发出到结束的整个处理过程就全部结束了。