iostat -x 输出中反映扇区级读写延迟的是 r_await 和 w_await 列，单位毫秒，表示内核发出请求至设备完成中断的全程耗时，不包含文件系统或 page cache 延迟。
iostat -x 输出里哪几列对应扇区级读写延迟
扇区读写延迟和应用层超时可不一样，但它可是底层超时的直接导火索。在iostat -x 1中，真正能反映扇区I/O延迟的是r_await和w_await——它们的单位是毫秒，统计的是从内核发出请求（包括扇区寻址、DMA准备）到设备返回完成中断这一整个过程所花费的时间，而不是文件系统或page cache层面的延迟。
注意：await 是读写混合平均值，掩盖了读/写路径差异；svctm 已被内核弃用（2.6.38+），数值不可信；%util 在 NVMe 上基本失效，不能用来反推扇区延迟。
r_await > 10ms（HDD）、> 1ms（SATA SSD）、> 0.5ms（NVMe）即表明扇区读操作已异常w_await持续高于读延迟，大概率是 journal 刷盘、脏页回写或 RAID 卡 write-back 缓存策略引发的扇区写阻塞- 若
aqu-sz长期 > 1 且w_await高，说明请求在块层队列堆积，还没轮到扇区执行 —— 此时不是扇区慢，是上层压太狠
ioping -C 直打设备测扇区真实响应时间
想绕过所有缓存和文件系统，只测裸设备扇区读写延迟，必须用 ioping 加 -C 参数。它发的是同步 I/O 请求，强制落盘，返回的就是控制器+介质的真实扇区往返时间。
别用默认模式：不加 -C 的 ioping /dev/sda 测的是缓存命中路径，数值虚低；dd 更不行，它只测顺序吞吐，完全不模拟随机扇区访问。
- 运行
ioping -C -c 10 /dev/nvme0n1，看输出里的a vg字段：NVMe 应 < 0.2ms，超 0.5ms 就要怀疑固件、PCIe 链路或电源问题 - 对 HDD 或 SATA SSD，用
ioping -C -c 20 /dev/sdb，a vg > 15ms且mdev > 3ms表明存在坏道或机械臂抖动 - 如果
ioping延迟正常，但iostat的w_await很高，问题一定出在上层：比如 ext4 的data=ordered模式导致大写阻塞，或 btrfs 的 CoW 触发元数据重写
查 /proc/diskstats 看扇区超时是否触发重试
内核遇到扇区读写超时（如 SCSI timeout、NVMe command timeout），会记录重试次数和失败扇区号，这些信息不出现在 iostat 里，得直接扒 /proc/diskstats。
字段顺序是固定的哦，第1列是主设备号，第2列是次设备号，第3列是设备名，第4到11列呢，则是读写统计。这里面关键要关注第10列，也就是“当前正在处理的I/O数”，还有第11列“ I/O处理总耗时，毫秒”。要是第11列的增长速度远远快于第4到7列（r/s、w/s），那就说明大量的请求卡在扇区层没返回，很可能已经超时重试啦。
- 执行
awk '{print $3,$11}' /proc/diskstats | grep sda，持续观察第11列跳变：每秒涨几百毫秒以上，基本确认有扇区级超时 - 配合
dmesg -T | grep -i "timeout|reset|offline"，找类似end_request: I/O error, dev sda, sector 123456789的日志，这才是扇区超时的铁证 - 某些 RAID 卡（如 MegaRAID）需额外查
/proc/megaraid/或用storcli，/proc/diskstats只反映逻辑卷视图，不暴露物理盘扇区错误
fio 测扇区长尾延迟，定位偶发超时根源
日常监控看到的 r_await 是平均值，掩盖了 p99.9 超时事件。一次 500ms 的扇区超时，在 1000 次请求里只拉高平均值 0.5ms，但足以让数据库事务超时。必须用 fio 打百分位分布。
配置要点：必须 direct=1（绕 page cache）、ioengine=libaio（用异步 I/O）、iodepth=32（模拟真实并发），否则测出来全是缓存速度。
- 命令示例：
fio --name=randread --ioengine=libaio --direct=1 --gtod_reduce=1 --filename=/dev/sda --bs=4k --rw=randread --iodepth=32 --runtime=60 --time_based --group_reporting - 重点看输出里的
clat_ns（completion latency）部分：p99.9=500000表示 99.9% 的扇区读在 500μs 内完成，剩下 0.1% 耗时 ≥ 500μs —— 这就是你要抓的超时尾巴 - 若
p99.9突然从 200μs 跳到 10ms，而ioping平均值不变，说明是驱动或固件层面的偶发 hang，不是介质老化
扇区超时不是孤立指标，它总是和调度器、队列深度、硬件健康状态耦合。盯住 r_await 和 ioping -C 的 a vg，再用 fio 扫长尾，最后用 dmesg 和 /proc/diskstats 锁定是否真发生超时 —— 这四步缺一不可。
