转自：https://blog.csdn.net/juS3Ve/article/details/79890688
前言
网上关于BIO和块设备读写流程的文章何止千万，但是能够让你彻底读懂读明白的文章实在难找，可以说是越读越糊涂！
我曾经跨过山和大海 也穿过人山人海
我曾经问遍整个世界 从来没得到答案
本文用一个最简单的read(fd, buf, 4096)的代码，分析它从开始读到读结束，在整个Linux系统里面波澜壮阔的一生。本文涉及到的代码如下：
#include <unistd.h>
#include <fcntl.h>
main()
{
int fd;
char buf[4096];
sleep(30); //run ./funtion.sh to trace vfs_read of this process
fd = open("file", O_RDONLY);
read(fd, buf, 4096);
read(fd, buf, 4096);
}
本文的写作宗旨是：绝不装逼，一定要简单，简单，再简单！
本文适合：已经读了很多乱七八糟的block资料，但是没打通脉络的读者；
本文不适合：完全不知道block子系统是什么的读者，和完全知道block子系统是什么的读者
Page cache与预读
在Linux中，内存充当硬盘的page cache，所以，每次读的时候，会先check你读的那一部分硬盘文件数据是否在内存命中，如果没有命中，才会去硬盘；如果已经命中了，就直接从内存里面读出来。如果是写的话，应用如果是以非SYNC方式写的话，写的数据也只是进内存，然后由内核帮忙在适当的时机writeback进硬盘。
代码中有2行read(fd, buf, 4096)，第1行read(fd, buf, 4096)发生的时候，显然”file”文件中的数据都不在内存，这个时候，要执行真正的硬盘读，app只想读4096个字节（一页），但是内核不会只是读一页，而是要多读，提前读，把用户现在不读的也先读，因为内核怀疑你读了一页，接着要连续读，怀疑你想读后面的。与其等你发指令，不如提前先斩后奏（存储介质执行大块读比多个小块读要快），这个时候，它会执行预读，直接比如读4页，这样当你后面接着读第2-4页的硬盘数据的时候，其实是直接命中了。
所以这个代码路径现在是 ：
当你执行完第一个read(fd, buf, 4096)后，”file”文件的0~16KB都进入了pagecache，同时内核会给第2页标识一个PageReadahead标记，意思就是如果app接着读第2页，就可以预判app在做顺序读，这样我们在app读第2页的时候，内核可以进一步异步预读。
第一个read(fd,buf, 4096)之前，page cache命中情况（都不命中）：
第一个read(fd,buf, 4096)之后，page cache命中情况：
我们紧接着又碰到第二个read(fd, buf, 4096)，它要读硬盘文件的第2页内容，这个时候，第2页是page cache命中的，这一次的读，由于第2页有PageReadahead标记，让内核觉得app就是在顺序读文件，内核会执行更加激进的异步预读，比如读文件的第16KB~48KB。
所以第二个read(fd,buf, 4096)的代码路径现在是 ：
第二个read(fd,buf, 4096)之前，page cache命中情况：
第二个read(fd,buf, 4096)之后，page cache命中情况：
内存到硬盘的转换
刚才我们提到，第一次的read(fd, buf, 4096)，变成了读硬盘里面的16KB数据，到内存的4个页面(对应硬盘里面文件数据的第0~16KB)。但是我们还是不知道，硬盘里面文件数据的第0~16KB在硬盘的哪些位置？我们必须把内存的页，转化为硬盘里面真实要读的位置。
在Linux里面，用于描述硬盘里面要真实操作的位置与page cache的页映射关系的数据结构是bio。相信大家已经见到bio一万次了，但是就是和真实的案例对不上。
bio的定义如下(include/linux/blk_types.h)：
struct bio_vec {
struct page *bv_page;
unsigned int bv_len;
unsigned int bv_offset;
};
struct bio {
struct bio *bi_next; /* request queue link */
struct block_device *bi_bdev;
…
struct bvec_iter bi_iter;
/* Number of segments in this BIO after
* physical address coalescing is performed.
*/
unsigned int bi_phys_segments;
…
bio_end_io_t *bi_end_io;
void *bi_private;
unsigned short bi_vcnt; /* how many bio_vec's */
atomic_t bi_cnt; /* pin count */
struct bio_vec *bi_io_vec; /* the actual vec list */
…
};
它是一个描述硬盘里面的位置与page cache的页对应关系的数据结构，每个bio对应的硬盘里面一块连续的位置，每一块硬盘里面连续的位置，可能对应着page cache的多页，或者一页，所以它里面会有一个bio_vec *bi_io_vec的表。
我们现在假设2种情况
第1种情况是page_cache_sync_readahead()要读的0~16KB数据，在硬盘里面正好是顺序排列的(是否顺序排列，要查文件系统，如ext3、ext4)，Linux会为这一次4页的读，分配1个bio就足够了，并且让这个bio里面分配4个bi_io_vec，指向4个不同的内存页：
第2种情况是page_cache_sync_readahead()要读的0~16KB数据，在硬盘里面正好是完全不连续的4块 (是否顺序排列，要查文件系统，如ext3、ext4)，Linux会为这一次4页的读，分配4个bio，并且让这4个bio里面，每个分配1个bi_io_vec，指向4个不同的内存页面：
当然你还可以有第3种情况，比如0~8KB在硬盘里面连续，8~16KB不连续，那可以是这样的：
其他的情况请类似推理…完成这项工作的史诗级的代码就是mpage_readpages()。
mpage_readpages()会间接调用ext4_get_block()，真的搞清楚0~16KB的数据，在硬盘里面的摆列位置，并依据这个信息，转化出来一个个的bio。
bio和request的三进三出
人生，说到最后，简单得只有生死两个字。但由于有了命运的浮沉，由于有了人世的冷暖，简单的过程才变得跌宕起伏，纷繁复杂。小平三落三起，最终建立了不朽的功勋。曼德拉受非人待遇在监狱服刑数十年，终成世界公认的领袖。走向自由之路不会平坦，斗争就是生活。与天斗，其乐无穷；与地斗，其乐无穷；与Linux斗，痛苦无穷！
bio产生后，到最终的完成，同样经历了三进三出的队列，这个过程的艰辛和痛苦，让人欲罢不能，欲说还休，求生不得求死不能。
这三步是：
1.原地蓄势
把bio转化为request，把request放入进程本地的plug队列；蓄势多个request后，再进行泄洪。
2.电梯排序
进程本地的plug队列的request进入到电梯，进行再次的合并、排序，执行QoS的排队，之后按照QoS的结果，分发给块设备驱动。电梯内部的实现，可以有各种各样的队列。
3.分发执行
电梯分发的request，被设备驱动的request_fn()挨个取出来，派发真正的硬件读写命令到硬盘。这个分发的队列，一般就是我们在块设备驱动里面见到的request_queue了。
下面我们再一一呈现，这三进三出。
原地蓄势
在Linux中，每个task_struct（对应一个进程，或轻量级进程——线程），会有一个plug的list。什么叫plug呢？类似于葛洲坝和三峡，先蓄水，当app需要发多个bio请求的时候，比较好的办法是先蓄势，而不是一个个单独发给最终的硬盘。
这个类似你现在有10个老师，这10个老师开学的时候都接受学生报名。然后有一个大的学生队列，如果每个老师有一个学生报名的时候，都访问这个唯一的学生队列，那么这个队列的操作会变成一个重要的锁瓶颈：
如果我们换一个方法，让每个老师有学生报名的时候，每天的报名的学生挂在老师自己的队列上面，老师的队列上面挂了很多学生后，一天之后再泄洪，挂到最终的学生队列，则可以避免这个问题，最终小队列融合进大队列的时候控制住时序就好。
你会发现，代码路径是这样的：
read_pages()函数先把闸门拉上，然后发起一系列bio后，再通过blk_finish_plug()的调用来泄洪。
在这个蓄势的过程中，还要完成一项重要的工作，就是make request（造请求）。这个完成“造请求”的史诗级的函数，一般是void blk_queue_bio(struct request_queue *q, struct bio *bio)，位于block/blk-core.c。
它会尝试把bio合并进入一个进程本地plug list里面的一个request，如果无法合并，则造一个新的request。request里面包含一个bio的list，这个list的bio对应的硬盘位置，最终在硬盘上是连续存放的。
下面我们假设"file"的第0~16KB在硬盘的存放位置为：
根据我们前面"内存到硬盘的转换"一节举的例子，这属于在硬盘里面完全不连续的"情况2"，于是这4块数据，会被史诗级的mpage_readpages()转化为4个bio。
当他们进入进程本地的plug list的时候，由于最开始plug list为空，100显然无法与谁合并，这样形成一个新的request0。
Bio1也无法合并进request0，于是得到新的request1。
Bio2正好可以合并进request1，于是Bio1合并进request1。
Bio3对应硬盘的200块，无法合并，于是得到新的request2。
现在进程本地plug list上的request排列如下：
泄洪的时候，进程本地的plug list的request，会通过调用elevator调度算法的elevator_add_req_fn() callback函数，被加入电梯的队列。
电梯排序
当各个进程本地的plug list里面的request被泄洪，以排山倒海之势进入的，不是最终的设备驱动（不会直接被拍死在沙滩上的）,而是一个电梯排队算法，进行再一次的排队。这个电梯调度，其实目的3个：
-
进一步的合并request
-
把request对硬盘的访问变得顺序化
-
执行QoS
电梯的内部实现可以非常灵活，但是入口是elevator_add_req_fn()，出口是elevator_dispatch_fn()。
合并和排序都好理解，下面我们重点解释QoS(服务质量)。想象你家里的宽带，有迅雷，有在线电影，有机顶盒看电视。
当你只用迅雷下电影的时候，你当然可以全速的下电影，但是当你还看电视，在线看电影，这个时候，你可能会对迅雷限流，以保证相关电视盒电影的服务质量。
电梯调度里面也执行同样的逻辑，比如CFQ调度算法，可以根据进程的ionice，调整不同进程访问硬盘的时候的优先级。比如，如下2个优先级不同的dd
# ionice-c 2 -n 0 cat /dev/sda > /dev/null&
# ionice -c 2 -n 7 cat /dev/sda >/dev/null&
最终访问硬盘的速度是不一样的，一个371M，一个只有72M。
所以当泄洪开始，漫江碧透,百舸争流，谁能到中流击水,浪遏飞舟?QoS是一个关于一将功成万骨枯的故事。
目前常用的IO电梯调度算法有：cfq, noop, deadline。详细的区别不是本文的重点，建议阅读《刘正元:Linux 通用块层之DeadLine IO调度器》从了解deadline的实现开始。
分发执行
到了最后要交差的时刻了，设备驱动的request_fn()通过调用电梯调度算法的elevator_dispatch_fn()取出经过QoS排序后的request并发命令给最终的存储设备执行I/O动作。
static void xxx_request_fn(struct request_queue *q)
{
struct request *req;
struct bio *bio;
while ((req = blk_peek_request(q)) != NULL) {
struct xxx_disk_dev *dev = req->rq_disk->private_data;
if (req->cmd_type != REQ_TYPE_FS) {
printk (KERN_NOTICE "Skip non-fs request ");
blk_start_request(req);
__blk_end_request_all(req, -EIO);
continue;
}
blk_start_request(req);
__rq_for_each_bio(bio, req)
xxx_xfer_bio(dev, bio);
}
}
request_fn()只是派发读写事件和命令，最终的完成一般是在另外一个上下文，而不是发起IO的进程。request处理完成后，探知到IO完成的上下文会以blk_end_request()的形式，通知等待IO请求完成的本进程。主动发起IO的进程的代码序列一般是：
-
submit_bio()
-
io_schedule()，放弃CPU。
blk_end_request()一般把io_schedule()后放弃CPU的进程唤醒。io_schedule()的这段等待时间，会计算到进程的iowait时间上，详见：《朱辉(茶水)： Linux Kernel iowait 时间的代码原理》。
用Ftrace抓所有流程
本文所涉及到的所有流程，都可以用ftrace跟踪到。这样可以了解更多更深刻的细节。
char buf[4096];
sleep(30); //run ./funtion.sh to trace vfs_read of this process
fd = open("file", O_RDONLY);
read(fd, buf, 4096);
在上述代码的中间，我特意留下了30秒的延时，在这个延时的空挡，你可以启动如下的脚本，来对整个过程进行function graph的trace，抓取进程对vfs_read()开始后的调用栈：
#!/bin/bash
debugfs=/sys/kernel/debug
echo nop > $debugfs/tracing/current_tracer
echo 0 > $debugfs/tracing/tracing_on
echo `pidof read` > $debugfs/tracing/set_ftrace_pid
echo function_graph > $debugfs/tracing/current_tracer
echo vfs_read > $debugfs/tracing/set_graph_function
echo 1 > $debugfs/tracing/tracing_on
笔者也是通过ftrace的结果，用vim打开，逐句分析的。关于ftrace使用的详细方法，可以阅读《宋宝华：关于Ftrace的一个完整案例》。
最后的话
本文描述的是主干，许多的细节和代码分支没有涉及，因为在本文描述太多的分支，会让读者抓不住主干。很多分支都没有介绍，比如unplug的泄洪，除了可以人为的blk_finish_plug()泄洪外，也会发生plug队列较满的时候，以及进程睡眠schedule()的时候的自动泄洪。另外，关于写，后面的三进三出的过程，基本与读类似，但是写有个page cache堆积和writeback的启动机制，是read所没有的。
充电宝
更多的细节欢迎大家进一步在阅读本文的基础上自学，或者参加我们的微课：
报名: 《Linux文件系统与I/O流程和模型》微课(4.15-4.18)
相关阅读
朱辉(茶水)： Linux Kernel iowait 时间的代码原理