linux无法直接查看扇区读写成功率趋势，因内核不统计单个扇区成败；应依赖smart属性（如reallocated_sector_ct）长期跟踪与dmesg中带扇区号的io错误日志双线验证。
Linux 无法直接查看“扇区读写成功率”趋势——因为内核不统计、不暴露单个扇区的读写成功/失败计数，也没有“扇区级成功率”这个指标。所谓“扇区成功率”是误用概念，实际应关注底层介质健康（SMART）和IO错误日志（I/O error count），二者才是可采集、可趋势化的真实信号。
iostat 和 /proc/diskstats 只能反映设备级吞吐与错误总量
iostat -x 或 /proc/diskstats 中的 rd_sect/wr_sect 是扇区计数，但它们只是累计值，不区分成功/失败；ioerr 字段（如 /proc/diskstats 第12列）仅记录**底层驱动上报的硬件IO错误次数**，且只增不减、无时间戳、不可重置。它不能告诉你“最近1小时失败了多少扇区”，只能说明“自启动以来发生过N次不可恢复的IO错误”。
-
iostat -x不输出任何错误计数字段，avgrq-sz是平均请求大小（单位扇区），不是成功率 -
/proc/diskstats第12列（ioerr）需手动解析，例如：awk '{print $12}' /proc/diskstats | grep -E '^[0-9]+$' - 该计数对NVMe设备可能不可靠（部分驱动不填充），对RAID/虚拟设备（如
dm-0）通常为0——错误被上层拦截或静默重试
SMART 属性才是扇区级健康的真实代理指标
真正接近“扇区可靠性”的数据来自硬盘固件通过 SMART 暴露的属性，比如 Reallocated_Sector_Ct、Current_Pending_Sector、UDMA_CRC_Error_Count。这些值可定期采集并绘制成趋势图，比任何IO工具都更早预警物理介质退化。
- 用
smartctl -A /dev/sda查看全部原始值；重点关注 ID 5（重映射扇区）、ID 197（待重映射扇区）、ID 198（脱机扫描未修复扇区） - 不要依赖
smartctl -H的“PASSED/FAILED”结论——它只做粗略判断，而趋势变化才是关键 - 建议每小时用 cron 抓取一次：
smartctl -A /dev/sda | awk '/Reallocated_Sector_Ct|Current_Pending_Sector/ {print $1,$10}' >> /var/log/smart-trend.log - 注意：NVMe 设备需用
smartctl -a -d nvme /dev/nvme0n1，属性名不同（如Media_Errors、Warning_Temperature_Time）
内核日志（dmesg）是扇区级失败的唯一时间序列证据
当真实扇区读写失败且未被重试掩盖时，内核会在 dmesg 中打印类似这样的行：end_request: I/O error, dev sda, sector 4681512。这是目前唯一带扇区号、时间戳、设备名的原始失败记录，可用于构建“失败扇区时间分布图”。
- 实时监控命令：
dmesg -w | grep -i "sector.*error\|end_request\|I\/O error" - 历史归档建议：
grep -i "sector.*error" /var/log/kern.log | awk '{print $1,$2,$3,$NF}'（提取日期+扇区号） - 注意：默认
kern.log可能不保留足够久，需确认 rsyslog 或 journald 配置中kernel.*日志级别为err或更高 - 大量此类日志往往意味着磁盘已进入故障晚期，不是“趋势诊断”，而是“立即更换”信号
真正的扇区级可靠性诊断，从来不是靠 IO 工具“算出来”的，而是靠 SMART 属性长期跟踪 + dmesg 失败事件回溯双线验证。任何试图从 iostat 或 iotop 推导扇区成功率的做法，都会漏掉最关键的硬件层信号。
