关于VFS的通用读，我们不做考虑，本文以如下函数为根，往下分析：
do_generic_mapping_read(*ppos,*mapping,*desc)
本函数的目的是，从磁盘读数据到用户态，
先是从*ppos开始的页，一直读到*ppos+desc->count 为止的，这么多个页，
然后拷贝desc->count字节的数据到用户态。
也即，从磁盘读到内存缓冲区是按页读的，而从内存缓冲区读到用户态是按字节的。
函数核心是调用
mapping->a_ops->readpage(filp, page);
将磁盘数据读到指定page。
这个回调readpage就是各个文件系统相关的了。
以ext2为例，这个值是ext2_readpage，其实就是
mpage_readpage(page, ext2_get_block);
来考察do_mpage_readpage：
mpage_readpage()的主要工作是判断页的缓存块在磁盘上的块是否连续，
如果连续，则此页可以只提交一个bio请求，然后返回。
如果不连续，则调用block_read_full_page对页的每个缓存块提交一个bio请求。
这里备个忘：对于一个bio里的bio_vec数组，每个成员都代表一段磁盘地址连续的数据缓冲段。
也即一个段。
既然要把磁盘数据读到这个page上，那么就要找出这个page应该对应磁盘的哪个位置。
一个page对应着文件的某个固定位置，而文件所在的inode肯定知道数据放在哪里。
所以自然需要先根据page取inode
这个inode用来做什么？当时是要取这个inode文件所在设备dev了，不然怎么去查磁盘里的数据（这个inode主要给get_block函数用）。
struct inode *inode = page->mapping->host;
除此之外，还顺带获取inode所支持的块大小参数，以便后续计算偏移。
我们来看这种通用的情况，假设这个页被划分成4个块缓冲(通常情况下块大小为512字节，页大小是4K，于是每个页面有4个块)。
很重要的一点，就是判断，这4个缓冲，
对应的磁盘上的数据，是否连续。为什么要判断是否连续？我们知道，对于块设备来说，
磁盘上物理地址相近的寻址，肯定效率高的多。所以，这里埋下一个伏笔，我们
每次尽量提交磁盘地址相近的请求，这也是后面要讲的io调度。
判断页内的块缓冲，在磁盘是否相近，是通过page->private是否有值来完成。
那page->private的值在什么时候设置？
大略的讲，是在内核发现第n个块，与第n-1个块的磁盘号不连续时，设置的。
理论说多了，头脑会晕，我们来情景分析2个场景，
在看这两个场景前，先来一段公共操作。
首先，要找出这个页里的第一块，是在文件的哪个块，毕竟磁盘都是以块为单位操作的。
做法是，先算出页在文件里的偏移字节数：
page->index << PAGE_CACHE_SHIFT
其中,page->index是该页在mapping里的index，左移PAGE_CACHE_SHIFT就得到mapping里该page的字节偏移。
接着将该值除以块大小，得到块在文件里的偏移号：
page->index << PAGE_CACHE_SHIFT >> blkbits
即
block_in_file = page->index << (PAGE_CACHE_SHIFT - blkbits);
好，现在分别来看两个场景。
场景1) 初次访问文件。
很明显，这个时候刚刚在mapping的address_space里分配了一块纯净的page。
page的private字段为0，因此代码姑且认为此page里的块缓冲都是磁盘连续的。
于是，依次对页内的所有块进行处理（一般一个页有4个块）
将这些页内块号，传递给文件系统相关的get_block函数，即ext2_get_block，
计算出每个块在磁盘上的块号。假设得到第n个块的磁盘编号s(n)，那么还要与前一个
块比较，是否编号连续，即s(n)是否等于s(n-1)+1
如果不等，则说明此page内的块缓冲在磁盘上不连续，需要额外处理。
1.1) 假如块在磁盘上连续存放
则把这些块号依次保存到局部blocks数组。接着就分配新bio。
关键是把bio->bi_sector设置成这些块的第一个扇区号(因为磁盘连续)，
并分配一个bio_vec，将此bio_vec的page设置为此page，并且offset设置为0(页内偏移)，
长度则设置为PAGE_SIZE(不考虑文件洞)
最后就submit_bio把数据提交给块设备层。
可以看出，对于磁盘连续的情况，该page并没有为其分配块缓冲首部，同时也没有给page->private
置位。
1.2) 假如块在磁盘上非连续存放
则需要给页内的每个块都单独提交bio。
这是靠block_read_full_page来完成的。
先检查此page的private标志，如果没有设置，则说明需要分配新缓冲区首部来指示这个page。
这个是通过create_empty_buffers来完成的。
同样的，根据page在mapping里的index，算出页的第一个块的序号index，接着对从index到
index+3的4个块，分别调用ext2_get_block，算出各自在磁盘上的序号b_blocknr，从而生成最重要的
bh结构(dev,b_blocknr)，接着对这4个bh提交bio，即submit_bh(READ, bh);
submit_bh新生成一个bio，
bio的内存缓冲数据(读文件目的地址)：
bio_vec[0]的page设置为新page，bio_vec[0]的bv_len为块默认大小，
bio_vec[0]的bv_offset(页内偏移)为相应的块在页内偏移。
bio的磁盘地址(读文件源地址)：
bio->bi_sector根据之前get_block的结果bh->b_blocknr计算
bio->bi_bdev设置为文件所在块设备dev，这样有了dev和设备块逻辑号，即可定位块设备磁盘的扇区位置。
场景2) 之前已经访问过文件
根据场景1我们知道，如果文件的这个页page里的块数据，在磁盘中是分散存放的，那么这个page就会对应一个
缓冲区首部链表；如果连续，那么page的private是空。
对于连续存放的情况，每次走到do_mpage_readpage，都会对4个块执行ext2_get_block，
检查相邻的块在磁盘是否连续。也就是说，对于连续存放的情况，代码并没有做优化，而是
仍然每个块都要深入驱动的代码，查找对应的磁盘扇区。
对于非连续存放的情况，由于page的private保存了上次访问时设置的块缓冲区首部
(即bh带BH_Mapped标志，表示缓冲区首部的b_bdev和b_blocknr是有效的)，因此可以
直接根据上次的结果，即保存的bh链表，去查找每个块在磁盘的扇区位置。
如果要优化连续存放的场景，笔者认为，可以给page->flag添加字段，来区分此page对应
的块在磁盘上是否连续，这样可以借助第一次访问得到的块磁盘扇区信息，直接操作磁盘，
这样就少了深入驱动查找磁盘扇区号的操作，也许可以提高性能。
接下来，简单说明一下submit_bio。
可以认为，submit将提交的bio封装为request，然后按一定规则插入与块设备相关的请求队列。
块设备的请求队列，是由块设备驱动分配，并且一个块设备只有一个请求队列。
所以，对于在同一个块设备的操作，需要对请求队列的插入做互斥。但是，如果系统有n块磁盘，
则就算这些磁盘用同一个块设备驱动，也需要n个请求队列，各个磁盘的操作就互不影响
，这样可以提高性能。
插入请求队列的函数是q->make_request_fn，该函数的期望是将上层提交的
bio经过排序、归并后，封装为request结构插入队列q中。这个排序、归并的算法就是
传说中的IO调度。
对于一个request来说，和bio一样，请求区间在磁盘上是连续的，这点很重要。
对于一个块设备来说，有两个队列，一个是驱动提供的队列q，另一个是各IO调度算法内部队列。
IO调度算法收到bio请求后，将其合并成request，然后排序插入IO内部队列，最后将合适的request
转移到驱动队列q，由驱动去自行提取q上的request。
来看合并和排序是怎么个概念：
合并，指的是将磁盘号临接的请求，合并成一个请求。
例如，request队列里，某个request的磁盘请求区间块为
(1024,2048)，
如果某个bio的请求区间为
(2048,2048+512)，
则该bio可以后向合并到
request(1024,2048+512)；
如果bio的请求区间为
(1024-512,1024)，
则可前向合并到
request(1024-512,2048)；
如果bio的请求区间为
(3072,3072+512)，
则此bio无法合并，需要新生成一个request。
如果不能合并，则需要把这个新生成的request，排序插入到IO调度算法队列里的对应位置。
再回到q->make_request_fn，在驱动初始化时可以指定q->make_request_fn的值，如果没有指定，
则默认是__make_request。
__make_request需要进行IO调度，即执行合并或者排序。
合并的代码在elv_merge(q, &req, bio);
如果不能合并，则get_request新生成一个request，将bio的值传递给此request，然后通过
add_request执行插入排序。
__elv_add_request(q, req, ELEVATOR_INSERT_SORT, 0);
对于deadline电梯算法来说，__elv_add_request会根据request->sector，插入到rb-tree，
然后deadline_move_request将rb-tree里的某个entry移动到驱动的q队列。
至于具体怎么选择这个request，就是算法核心相关了，由于笔者走到这里已经半夜12点，
因此不打算继续分析，后续有需求再说。
到最后，设备驱动需要提供一个do_request函数，这个函数遍历驱动的q队列，
挨个取出request，然后遍历request的各个段，将各个段的数据提交给scis层，
数据传输完毕。
那驱动是什么时候被激活去处理这些request呢？答案是定时处理。
定时器超时的时候，唤醒一次kblockd线程，kblockd会执行blk_unplug_work，最终去执行驱动的request。
具体流程代码大体如下：
static void blk_unplug_timeout(unsigned long data)
{
request_queue_t *q = (request_queue_t *)data;
blk_add_trace_pdu_int(q, BLK_TA_UNPLUG_TIMER, NULL,
q->rq.count[READ] + q->rq.count[WRITE]);
kblockd_schedule_work(&q->unplug_work);
}
INIT_WORK(&q->unplug_work, blk_unplug_work);
static void blk_unplug_work(struct work_struct *work)
{
request_queue_t *q = container_of(work, request_queue_t, unplug_work);
blk_add_trace_pdu_int(q, BLK_TA_UNPLUG_IO, NULL,
q->rq.count[READ] + q->rq.count[WRITE]);
q->unplug_fn(q);
}
q->unplug_fn = generic_unplug_device;
void __generic_unplug_device(request_queue_t *q)
{
if (unlikely(blk_queue_stopped(q)))
return;
if (!blk_remove_plug(q))
return;
q->request_fn(q); //驱动的request
}
io调度可以控制plug和unplug的速度，来累计尽可能多的连续磁盘地址的request，以提高磁盘访问效率。