必须用 iostat -x 查看 rrqm/s 和 wrqm/s，它们反映内核对读/写请求的合并效率；rrqm/s 高说明随机读密集，wrqm/s 接近 w/s 一半以上表明写碎片化严重；r/s 与 r_ios 差异体现内核合并强度，差值越大越说明是小块随机 IO。
看 rrqm/s 和 wrqm/s 字段必须用 iostat -x
这两个值直接告诉你内核对读/写请求的合并效率，但只在 iostat -x 模式下输出。默认 iostat 或加 -d 参数时完全不显示它们。
执行命令：iostat -x 1（每秒刷新），重点关注输出中的 rrqm/s（每秒被合并的读请求数）和 wrqm/s（每秒被合并的写请求数）两列。
-
rrqm/s高 ≠ 好：说明上层发来大量小读请求，内核被迫频繁合并，往往意味着随机读密集、IO模式低效 -
wrqm/s接近w/s一半以上：写请求碎片化严重，可能是日志类应用未批量刷盘，或文件系统未启用 writeback 缓存 - SSD 上
rrqm/s通常远低于 HDD：因为 SSD 随机读延迟低，应用更倾向发小请求，合并动力弱 - 值为 0 不代表没合并：只是“被显式合并”的请求数为 0，底层 block layer 仍可能做隐式合并（比如 NVMe 提交 batch）
r/s 和 r_ios 差异暴露真实下发压力
r/s 是上层合并后提交到队列的请求数，r_ios（需 iostat -dx）才是真正送进 block queue 的次数。两者差距就是“内核级合并强度”的量化体现。
例如某 NVMe 盘：r/s 显示 120，但 r_ios 是 4800 —— 说明平均每个 r/s 请求背后有 40 个小 IO 被内核打包提交。
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 这个差值越大，越说明 workload 是小块随机型（如数据库 redo log、小文件元数据操作）
- 如果
r_ios≈r/s，但rkB/s很低，大概率是应用层发了大量 512B/4K 对齐不良的请求，触发了额外切分 -
r_ios不能直接等同于物理完成数：驱动或设备固件可能再合并（比如 NVMe 多队列中一个 request 包含多个 cmd），要验证得查/sys/block/nvme0n1/stat第 1 列
别信 avgrq-sz，它只反映逻辑请求大小
avgrq-sz 单位是扇区（512B），看起来是“平均请求大小”，但它统计的是提交到 queue 前的逻辑请求尺寸，不包含合并后的真实物理 I/O 大小。
- 即使
avgrq-sz显示 128（即 64KB），r_ios仍可能高达r/s的 10 倍——因为内核把 10 个 64KB 请求合并成 1 个 640KB request 下发 - 该值受文件系统块大小、应用 writev() 调用粒度、page cache 回写策略共同影响，单独看意义有限
- 真正关心吞吐效率时，应交叉比对：
rkB/s ÷ r_ios≈ 实际下发的平均物理 IO 大小（单位 KB）
合并效率异常时的典型错误现象
当请求合并失常，你不会看到“合并失败”报错，但会观察到一系列间接症状：
-
%util很高（>90%），但rkB/s很低：说明设备忙于处理海量小请求，而非传输数据 -
r_await显著高于w_await：小读请求无法有效合并，排队时间拉长；而写请求常被 buffer/cache 暂存，实际下发节奏平滑 -
avgqu-sz突增但r/s没涨：队列里塞满待合并的小请求，内核还没来得及打包就又来了新请求 - 用
fio --rw=randread --bs=4k测出 IOPS 极低，但换--bs=128k瞬间翻倍：证实小块场景下合并机制未起效或路径阻塞
真正容易被忽略的是：合并行为发生在 VFS → block layer → driver 多个层级，iostat 只能捕获 block layer 入口处的状态，驱动内部是否进一步拆分/重组，得靠 blktrace 或设备厂商工具确认。
