最近一个项目做了一个模拟u盘的设备，但是在read虚拟u盘的内容时必须每次都从磁盘内读取，而不是从系统的cache中读取，由于这个问题，就查资料看了下read的系统调用，以及文件系统的一些内容。由于文件系统涉及面较广，例如虚拟文件系统（VFS），页缓存，块缓存，数据同步等内容，不可能全部分析到位，这里只记录和read有关的两种使用方式。cached IO和direct IO。
首先系统调用能做那些事呢？概括来说，大概有下面这些事需要系统调用来实现。
那为什么一定要用系统调用来访问操作系统的内容呢，其实这可以看做对内核的保护，linux分为用户空间和内核空间，而用户空间是不允许访问内核空间的数据的。那么在用户空间的程序需要访问内核空间的资源时就必须通过系统调用这个中间人来实现。这样可以对用户空间的行为进行限制，只有特定的得到许可的（事先规定的）用户空间行为才能进入内核空间。一句话，系统调用是内核给用户空间提供的一个可以访问内核资源的一个接口。
另外多说一句，从用户进程切换到内核进程只有两种方式，一种就是系统调用，另一种是中断。
要实现系统调用，首先要能从用户空间切换到内核空间，这个切换在IA-32系统上是用汇编指令int $0x80来引发软件中断实现的。这部分内容一般是在C标准库中实现的。进入内核空间后，系统调用中枢处理代码（所有的系统调用都由一处中枢代码处理）根据传递的参数（参数是有寄存器传递的包括唯一的系统调用号）和一个静态表分别执行不同的函数。例如read系统调用，0x80 中断处理程序接管执行后，先检查其系统调用号，然后根据系统调用号查找系统调用表，并从系统调用表中得到处理 read 系统调用的内核函数 sys_read ，最后传递参数并运行 sys_read 函数。至此，内核真正开始处理 read 系统调用（sys_read 是 read 系统调用的内核入口）。
如图所示为read 系统调用在核心空间中所要经历的层次模型。从图中看出：对于磁盘的一次读请求，首先经过虚拟文件系统层（vfs layer），其次是具体的文件系统层（例如 ext2），接下来是 cache 层（page cache 层）、通用块层（generic block layer）、IO 调度层（I/O scheduler layer）、块设备驱动层（block device driver layer），最后是物理块设备层（block device layer）。
以上结构的定义可参考VFS文件系统以及内核源码。
数据结构之间的关系如下图所示：
上图展示了上述各个数据结构（除了 bio）之间的关系。可以看出：由 dentry 对象可以找到 inode 对象，从 inode 对象中可以取出 address_space 对象，再由 address_space 对象找到 address_space_operations 对象。File 对象可以根据当前进程描述符中提供的信息取得，进而可以找到 dentry 对象、 address_space 对象和 file_operations 对象。
对于具体的一次 read 调用，内核中可能遇到的处理情况很多。这里举例其中的一种情况：
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;
}
其中主要代码的解释：
函数最后返回该文件的文件描述符。
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;
}
代码解析：
if (file->f_op->read)
ret = file->f_op->read(file, buf, count, pos);
到此，虚拟文件系统层所做的处理就完成了，控制权交给了 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）：
在 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结构体描述页高速缓存中的页面。
do_generic_file_read做的工作：
到此，我们知道：当页上的数据不是最新的时候，该函数调用 mapping->a_ops->readpage 所指向的函数（变量 mapping 为 inode 对象中的 address_space 对象），那么这个函数到底是什么呢？在Ext2文件系统中，readpage指向ext2_readpage。
从上文得知：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 层的处理结束。
generic_make_request 函数是该层的入口点，该层只有这一个函数处理请求。函数的代码参见blk-core.c。
主要操作：
根据 bio 中保存的块设备号取得请求队列 q
检测当前 IO 调度器是否可用，如果可用，则继续；否则等待调度器可用
调用 q->make_request_fn 所指向的函数将该请求（bio）加入到请求队列中
到此为止，通用块层的操作结束。
对 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 函数的主要工作为：
将请求放入到请求队列中后，何时被处理就由 IO 调度器的调度算法决定了（有关 IO 调度器的算法内容请参见参考资料）。一旦该请求能够被处理，便调用请求队列中成员 request_fn 所指向的函数处理。这个成员的初始化也是在创建请求队列时设置的：
q->request_fn = rfn;
blk_queue_make_request(q, __make_request);
第一行是将请求处理函数 rfn 指针赋给了请求队列的 request_fn 成员。而 rfn 则是在创建请求队列时通过参数传入的。
对请求处理函数 request_fn 的调用意味着 IO 调度层的处理结束了。
request_fn 函数是块设备驱动层的入口。它是在驱动程序创建请求队列时由驱动程序传递给 IO 调度层的。
IO 调度层通过回调 request_fn 函数的方式，把请求交给了驱动程序。而驱动程序从该函数的参数中获得上层发出的 IO 请求，并根据请求中指定的信息操作设备控制器（这一请求的发出需要依据物理设备指定的规范进行）。
到此为止，块设备驱动层的操作结束。
接受来自驱动层的请求，完成实际的数据拷贝工作等等。同时规定了一系列规范，驱动程序必须按照这个规范操作硬件。
当设备完成了 IO 请求之后，通过中断的方式通知 cpu ，而中断处理程序又会调用 request_fn 函数进行处理。
当驱动再次处理该请求时，会根据本次数据传输的结果通知上层函数本次 IO 操作是否成功，如果成功，上层函数解锁 IO 操作所涉及的页面。
该页被解锁后， 就可以再次成功获得该锁（数据的同步点），并继续执行程序了。之后，函数 sys_read 可以返回了。最终 read 系统调用也可以返回了。
至此， read 系统调用从发出到结束的整个处理过程就全部结束了。
来自：http://www.coderonline.net/?p=711
关注微信公众平台:程序员互动联盟(coder_online)，你可以第一时间获取原创技术文章，和（java/C/C++/Android/Windows/Linux）技术大牛做朋友，在线交流编程经验，获取编程基础知识，解决编程问题。程序员互动联盟，开发人员自己的家。
原文地址：http://blog.csdn.net/haomcu/article/details/46558553
