一、概述

　　【许久之前就用过blktrace，现整理如下】

　　 从linux 一个完整的IO入手分析：

　　

　　　　

　　一个I/O请求进入block layer之后，可能会经历下面的过程：

• • Remap: 可能被DM(Device Mapper)或MD(Multiple Device, Software RAID) remap到其它设备
  • Split: 可能会因为I/O请求与扇区边界未对齐、或者size太大而被分拆(split)成多个物理I/O
  • Merge: 可能会因为与其它I/O请求的物理位置相邻而合并(merge)成一个I/O
  • 被IO Scheduler依照调度策略发送给driver
  • 被driver提交给硬件，经过HBA、电缆（光纤、网线等）、交换机（SAN或网络）、最后到达存储设备，设备完成IO请求之后再把结果发回。

　blktrace 能够记录下IO所经历的各个步骤:　

　　　　　一起看下blktrace的输出长什么样子：

• 第一个字段：8,0 这个字段是设备号 major device ID和minor device ID。
• 第二个字段：3 表示CPU
• 第三个字段：11 序列号
• 第四个字段：0.009507758 Time Stamp是时间偏移
• 第五个字段：PID 本次IO对应的进程ID
• 第六个字段：Event，这个字段非常重要，反映了IO进行到了那一步
• 第七个字段：R表示 Read， W是Write，D表示block，B表示Barrier Operation
• 第八个字段：223490+56，表示的是起始block number 和 number of blocks，即我们常说的Offset 和 Size
• 第九个字段： 进程名

　　　　其中第六个字段非常有用：每一个字母都代表了IO请求所经历的某个阶段。

1 Q – 即将生成IO请求2 |3 G – IO请求生成4 |5 I – IO请求进入IO Scheduler队列6 |7 D – IO请求进入driver8 |9 C – IO请求执行完毕

　　注意，整个IO路径，分成很多段，每一段开始的时候，都会有一个时间戳，根据上一段开始的时间和下一段开始的时间，就可以得到IO 路径各段花费的时间。

　　注意，我们心心念念的service time，也就是反应块设备处理能力的指标，就是从D到C所花费的时间，简称D2C。

　　而iostat输出中的await，即整个IO从生成请求到IO请求执行完毕，即从Q到C所花费的时间，我们简称Q2C。

　　我们知道Linux 有I/O scheduler，调度器的效率如何，I2D是重要的指标。

　　　　注意，这只是blktrace输出的一个部分，很明显，我们还能拿到offset和size，根据offset，我们能拿到某一段时间里，应用程序都访问了整个块设备的那些block，从而绘制出块设备访问轨迹图。

　　　　另外还有size和第七个字段（Read or Write），我们可以知道IO size的分布直方图。对于本文来讲，我们就是要根据blktrace来获取这些信息。