iostat -x 1中反映寻道排队的是await、r_await、w_await和avgqu-sz四列：await表示请求全程耗时，若显著高于svctm（如45.2ms vs 0.11ms）说明排队主导；r_await/w_await失衡可定位读写密集型排队；avgqu-sz持续>1且与await同步上升则证实队列堆积。
iostat -x 1 里哪几列反映寻道排队？
Linux 没有单独暴露“寻道时间”的字段，因为现代 SSD（尤其是 NVMe）根本不存在机械寻道，而 HDD 的寻道开销已深度融入 await 和 svctm 的统计中。你真正能观察到的，是“请求因设备忙或调度策略被迫排队”的结果——这包括寻道、旋转延迟（HDD）、命令处理、队列竞争等所有环节的总和。
await 是你要盯死的数字：它 = r_await + w_await 的加权平均，单位毫秒，代表一个 I/O 请求从进队列到完成的全程耗时。如果 await 显著高于 svctm（比如 await=45.2ms 而 svctm=0.11ms），说明绝大部分时间花在排队上，而非设备实际干活——这时无论底层是寻道、旋转还是调度串行化，都已表现为队列堆积。
-
aqu-sz（平均队列长度）持续 >1，且与await同步上升 → 排队属实，不是瞬时抖动 -
%util接近或超过 100% → 设备饱和，但 NVMe 下该值失真，得靠aqu-sz和await交叉验证 -
r_await远高于w_await→ 读密集型排队，常见于数据库全表扫描、日志归档读取 -
w_await高但w/s很低 → 少量小写（如 4KB）卡住队列，大概率是日志刷盘或元数据更新阻塞，不是吞吐问题
/proc/diskstats 第9列和第11列怎么看排队累积？
/proc/diskstats 是所有工具的原始数据源，第9列（aveq）和第11列（await_ms 的累加值）比 iostat 更底层、更难解读，但能避开工具自身刷新周期带来的平滑假象。
执行 watch -n1 'cat /proc/diskstats | grep nvme0n1'，重点关注同一设备前后 5 秒的数值跳变：
- 第9列（
aveq）：加权队列长度累计值。差值 ÷ 采样时间 ≈ 实际平均队列长度，比iostat的aqu-sz更接近瞬时状态 - 第11列（
await_ms累加）：I/O 等待毫秒数总和。差值 ÷ 该时段 I/O 完成次数 = 实际await，可验证iostat是否被缓存或采样干扰 - 若第9列飙升但第4/8列（读/写完成次数）几乎不动 → 请求压根没发出去，堵在内核块层或驱动入口，和磁盘物理寻道无关
为什么 blktrace 比 iostat 更适合定位寻道类排队？
blktrace 把 I/O 请求在存储栈每一层（block layer → driver → hardware）的时间戳打出来，能明确区分“排队”发生在哪一环。对 HDD 来说，“寻道”对应的是 Q（入队）到 M（merge）之间的时间差；对 NVMe，则是 Q 到 G（get request）之间的延迟，反映队列调度开销。
实操步骤：
- 先用
blktrace -d /dev/nvme0n1 -o - | blkparse -i -抓取原始事件流 - 过滤出写请求并计算排队时间：
blkparse -i trace.nvme0n1 | awk '$5=="Q" {q[$7]=$6} $5=="G" && $7 in q {print $7, $6-q[$7]}' | sort -k2 -n | tail -10 - 若输出中某次
Q→G耗时 >1ms（NVMe）或 >5ms（SATA SSD），且iostat的await同步升高 → 排队发生在块层或驱动，不是硬件慢 - 注意：
blktrace开销大，别在生产环境长时运行；优先用iostat -x 1快筛，再用blktrace定点抓包
排查时最容易忽略的“伪寻道排队”来源
很多高 await 看似像寻道慢，实际和磁盘物理特性完全无关：
- 文件系统日志模式：ext4 默认
data=ordered，大文件写入会阻塞后续写；journal模式下元数据强制串行落盘，w_await会虚高 - I/O 调度器错配：NVMe 上启用
mq-deadline或bfq，会人为引入串行化，aqu-sz低但await高 → 查/sys/block/nvme0n1/queue/scheduler，必须是none - 脏页回写风暴：
/proc/vmstat中pgpgout突增，内核集中 flush 导致w_await毛刺，iotop却看不到具体进程 - ACPI power state 异常：dmesg 里出现
"nvme 0000:01:00.0: PCIe Bus Error"或"acpi PNP0A08:00: fail to add MMIO resource"，会导致链路重试，await周期性尖峰
真寻道问题只存在于传统 HDD，且必须配合 smartctl -a /dev/sda 看 Reallocated_Sector_Ct 和 Current_Pending_Sector 才能确认。其他情况，别急着换盘——先看调度器、日志模式、dmesg 错误。
