Linux的文件IO子系统是Linux中最复杂的一个子系统(没有之一)。读者可以参考以下这个图:

https://www.thomas-krenn.com/de/wikiDE/images/2/2d/Linux-storage-stack-diagram_v4.0.pdf
数据从 Page Cache 同步到磁盘上,发出的请求称为一个request,一个request包含一组 bio,每个bio包含要同步的数据pages,你要把Page和磁盘的数据进行同步。

和网络子系统不同,磁盘的调度是有要求的,不是说你发一个page,我就帮你写进去,你再发一个page,我就给你再写一个进去。你要写磁盘的一个地方,磁盘要先把磁头物理上移动到那个轨道上,然后才能写,你让磁头这样移来移去的,磁盘的性能就很难看了。
Linux的IO调度器称为evelator(电梯),因为Linus开始实现这个系统的时候,使用的就是电梯算法。
坐过电梯很容易理解什么是电梯算法,电梯的算法是:电梯总是从一个方向,把人送到有需要的最高的位置,然后反过来,把人送到有需要的最低一个位置。这样效率是最高的,因为电梯不用根据先后顺序,不断调整方向,走更多的冤枉路。
为了实现这个算法,我们需要一个plug的概念。这个概念类似马桶的冲水器,你先把冲水器用塞子堵住,然后开始接水,等水满了,你一次把塞子拔掉,冲水器中的水就一次冲出去了。在真正冲水之前,你就有机会把数据进行合并,排序,保证你的“电梯”可以从一头走到另一头,然后从另一头回来。
我们前面讲IO系统的时候就提过磁盘调度子系统的ftrace跟踪,这里我们深入看看blktrace跟踪到的事件的含义:
请求相关
Q - queued:bio请求进入调度 G - get request:分配request I - inserted:request进入io调度器
调度相关
B - bounced:硬件无法访问内存,需要把内存降低到硬件可访问 M - back merge:请求和前一个从后面合并 F - front merge:请求和前一个从前面合并 X - split:请求分析为多个request(很可能是因为硬件不支持太大的请求) A - remap:基于分区等,重新映射request的位置 R - requeue: Request重新回到调度队列 S - sleep:调度器进入休眠P - plug:调度队列插入设备(准备合并) U - unplug:调度队列离开设备(全部一次写入设备中) T - unplug due to timer超时,而不是数据足够发起的unplug
发出相关
C - complete:完成一个request的调度(无论成功还是失败) D - issued:发送到设备,这个是从下层硬件驱动发起的
我们通过对这些事件的跟踪,对照硬件的特性大概就可以知道运行的模型是否正常了。




首先来看一下一般的IO调用。在传统的文件IO操作中,我们都是调用操作系统提供的底层标准IO系统调用函数 read()、write() ,此时调用此函数的进程(在JAVA中即java进程)由当前的用户态切换到内核态,然后OS的内核代码负责将相应的文件数据读取到内核的IO缓冲区,然后再把数据从内核IO缓冲区拷贝到进程的私有地址空间中去,这样便完成了一次IO操作。如下图所示:

注意两点: