Linux没有现成的“磁盘物理扇区读写延迟超时记录”日志，需通过iostat -x的r_await/w_await（持续>1ms SSD或>10ms HDD即预警）、/proc/diskstats第9列（aveq）和第11列（await累加值）验证堆积，并结合dmesg中NVMe/ATA timeout、sector=xxx等错误及smartctl坏块指标交叉确认。
Linux 没有“磁盘物理扇区读写延迟造成的 IO 超时记录”这种现成日志——它不是按扇区粒度记录超时事件的，而是靠内核底层计数器 + 链路错误日志交叉推断。
iostat -x 的 await 和 r_await/w_await 是最接近的代理指标
内核不记录“第 123456789 扇区读超时”，但会统计每个 I/O 请求从进队列到完成的耗时：await（总平均）、r_await（读）、w_await（写）。这些值直接反映物理层响应能力：
- 持续
r_await > 10ms（HDD）或> 1ms（SSD/NVMe），说明读请求在设备端已明显变慢，大概率是物理介质响应延迟升高或链路重试增多 -
r_await突然跳升（比如从 0.3ms → 50ms），且avgqu-sz未同步上涨，说明不是排队导致，而是单次服务耗时暴涨——典型如坏扇区重试、NVMe controller timeout 或 SATA link recovery -
iostat -xk 1 /dev/sda比iostat -xk 1更准：避免被其他设备噪声干扰，聚焦目标盘
/proc/diskstats 第 9 列（aveq）和第 11 列（毫秒级 await 累加值）可验证是否真实堆积
/proc/diskstats 是所有工具的数据源，字段含义常被误读。对排查“物理层卡顿”最关键的是：
- 第 9 列
aveq：加权队列长度（单位：毫秒·请求），值越大说明请求在队列中滞留越久；若该列 5 秒内增长剧烈，而await却没同步涨，可能是调度器或驱动层丢弃了部分请求（需结合 dmesg） - 第 11 列：该设备自启动以来的
await总毫秒数（非平均值），除以第 4 列（读完成次数）+ 第 8 列（写完成次数）≈ 实际平均await，比iostat输出更原始、无采样平滑 - 执行
watch -n1 'awk '\''/sda/{print \$9,\$11}\'\'' /proc/diskstats'，盯住数字跳变节奏 —— 匀速涨是常态，突然阶梯式跳变往往对应一次链路 reset 或 firmware timeout
dmesg | grep -i "nvme\|ata\|error\|timeout" 是唯一能抓到扇区级失败的地方
当物理扇区读写失败（如 ECC 校验失败、重映射触发、link down），内核会在 dmesg 记录，但不会存入 syslog 或 /var/log/。关键线索包括：
-
NVMe status: 0x2001（generic timeout）、ata[0-9]: failed command: READ、end_request: I/O error—— 这些直接指向硬件层异常 -
blk_update_request: I/O error后跟sector=123456789：这就是你唯一能拿到的“具体扇区”信息，但仅出现在严重错误时，且不带时间戳 -
nvme nvme0: I/O 12345 timeout, reset controller：说明 NVMe controller 已主动复位，此前所有未完成请求都算作超时，但扇区地址通常丢失 - 运行
dmesg -T | tail -50（带人类时间戳）比dmesg更易定位发生时间；用grep -A5 -B5 "timeout"查上下文，看是否伴随PCIe AER或ACPI错误
别指望 ioping 或 fio 直接输出“超时扇区”，它们只告诉你延迟高或失败
ioping -C -c 10 /dev/sda 和 fio 能复现问题，但无法回溯到哪个扇区出错：
-
ioping默认用 512 字节随机读写，失败时只报timeout，不提供 LBA 地址；加-D参数可 dump raw request，但需配合 blktrace 解析，实操成本极高 -
fio的ioengine=libaio+direct=1可绕过 cache，但错误日志仍是 generic “read/write failed”，除非用--write_iolog记录每条 I/O，再人工比对失败 offset —— 这已超出运维日常范围 - 真正要定位坏扇区，得用
smartctl -a /dev/sda看Reallocated_Sector_Ct、Current_Pending_Sector，或badblocks -v /dev/sda（必须卸载后运行）
复杂点在于：await 高 ≠ 一定有坏扇区；dmesg 无 error ≠ 物理层没问题；smartctl 健康 ≠ 没有瞬时链路抖动。真正要确认“物理扇区级延迟导致超时”，必须三者同时满足：await 异常上升 + dmesg 出现 sector-level error + smartctl 显示 pending/reallocated sectors 上升。缺一不可。
