iostat无法直接显示单次寻道时间，因该物理参数由HDD固件控制且不通过ATA/SCSI接口上报；await是端到端响应时间（含队列等待、寻道、旋转延迟、传输），svctm在现代内核已弃用不可信，真正反映寻道压力的是%util>80%且avgqu-sz>2的组合。
iostat 不能直接显示单次寻道时间，Linux 内核不向用户空间暴露硬件级的寻道时间（单位毫秒）测量值。你看到的 await 是 I/O 请求在队列中等待 + 实际服务时间的总和，不是纯寻道时间。
为什么无法直接查到寻道时间？
寻道时间是机械硬盘（HDD）内部物理动作，由磁盘固件控制，厂商不通过标准 ATA/SCSI 接口向操作系统报告该值。Linux 只能观测到 I/O 层面的延迟统计，无法拆解出其中多少是磁头移动、多少是旋转等待。
iostat -x 中哪些字段接近但不等于寻道时间？
await（平均每次 I/O 的响应时间）和 svctm（平均服务时间）常被误认为是寻道时间，但它们都包含多个成分：
-
await = avgqu-sz / (r/s + w/s)，反映的是“请求从发出到完成”的端到端耗时，含队列等待、寻道、旋转延迟、传输时间 -
svctm在现代内核（2.6.25+）已弃用，iostat输出中该值常为 0 或严重失真，不可信 - 真正能间接反映寻道压力的是
avgqu-sz（平均队列长度）和%util：若%util长期 >80% 且avgqu-sz>2，说明磁盘持续满负荷，随机 I/O 下寻道开销大概率已成为瓶颈
怎么估算典型寻道时间？
只能查厂商规格或用经验公式反推，不是实时测量：
- 查
hdparm -I /dev/sda | grep "Average"—— 多数消费级 HDD 不提供该字段，企业盘（如 Seagate Exos、WD Ultrastar）可能在 IDENTIFY DEVICE 数据中带AVG READ/WRITE SEEK TIME - 查硬盘型号官网 PDF 规格书，搜索 “average seek time”，例如：
ST4000NM0035标称 7.8ms（读），ST12000NM0007标称 4.2ms - 用
iostat -x 1观察高随机读场景下的await：若r/s很高（>100）、rkB/s很低（await 稳定在 8–15ms 区间，基本可判断寻道是主要延迟来源
想验证寻道是否瓶颈，该看什么？
不要盯着“查数值”，要看行为特征：
- 运行
iostat -x 1，观察rrqm/s和wrqm/s：如果远高于 0（比如 >50），说明内核已在合并请求，试图减少寻道次数 - 对比顺序 vs 随机负载：
fio --name=randread --ioengine=libaio --rw=randread --bs=4k --numjobs=1 --size=1G的lat值，若比--rw=read高 5–10 倍，就是寻道拖慢了 - 注意
await和svctm差距：若await≫svctm（比如 await=12ms, svctm=0.3ms），差值部分基本就是排队 + 寻道 + 旋转延迟
iostat + fio + 厂商文档交叉印证，判断它是不是当前 I/O 慢的根因。真要量化，得用磁盘底层日志（如 SMART 的 Load_Cycle_Count 或 Seek_Error_Rate），但那也不是时间值。 
