坏道会直接破坏I/O可靠性，导致内核反复重试、降级调度甚至触发错误路径，表现为I/O延迟飙升、吞吐骤降、进程卡死；其核心影响是使磁盘“又忙又废”：%util近100%但r/s极低、await高达数百毫秒、avgqu-sz持续>10，同时dmesg中可见重复sector报错、timeout与hung_task警告。
磁盘坏道会直接破坏 I/O 请求的底层可靠性，不是“慢一点”，而是让内核反复重试、降级调度、甚至触发错误路径，最终表现为 I/O 延迟飙升、吞吐骤降、进程卡死。分析它的恶劣影响，关键不是等故障爆发后再查，而是把坏道当作一个“正在恶化的 I/O 故障源”，从现象反推它如何撕裂整个 I/O 路径。
看内核日志里的 I/O 错误模式
坏道最原始的信号藏在 dmesg 里，不是零星几条，而是一组有规律的报错：
-
重复出现的 sector number：比如连续几条
end_request: I/O error, dev sda, sector 123456789，说明同一个物理扇区反复失败； -
request timeout + abort sequence：
timeout while waiting for device后跟着resetting host或recovery failed，代表驱动已放弃该请求，转为重置链路； -
__blk_mq_complete_request hang 或
hung_task报警：说明上层进程（如数据库线程）被卡在等待这个扇区的读写完成，已超时 120 秒。
这些日志不是“警告”，是 I/O 路径正在断裂的实时快照。用 dmesg -T | grep -i "error\|sector\|timeout\|hang" 滚动盯几分钟，就能确认坏道是否活跃参与当前 I/O 堵塞。
linux-sysadmin
下载
Linux系统管理专家，覆盖12大模块：用户权限、SSH、存储、网络、systemd、防火墙、日志监控、备份恢复、TLS证书、Ansible、容器、IaC。提供配置、验证、加固、监控、备份、自动化、故障排查、回滚闭环。关键词：useradd、sudo、sshd_config、chmod、SEL...
用 iostat 看坏道引发的调度畸变
坏道会让磁盘表现得“又忙又废”——%util 接近 100%，但 r/s、w/s 极低，await 却高达几百毫秒甚至秒级。这不是负载高，是设备在反复 retry 和 reset。
- 正常高负载：r/s 高 + await 低（比如 5–15ms），说明磁盘在高效吞吐；
- 坏道干扰下：r/s 可能只有个位数，await 却飙到 800ms，
avgqu-sz（平均队列长度）持续 >10，说明请求全堆在队列里等那个坏扇区重试； - 更危险的是
svctm显著高于await（已废弃但仍有参考价值），或r_await/w_await不对称暴涨（比如读 await 2s，写正常），暗示坏道集中在某类访问区域（如文件系统元数据区）。
用 iotop 定位“无辜受害者”
坏道本身不主动发起 I/O，但它会让所有访问坏区的进程变成“受害者”。iotop 能帮你发现谁在替坏道背锅：
- 打开
sudo iotop -oP，关注那些 DISK WRITE 列数值不大（比如 200KB/s），但 IO> 列显示BE（Best-effort）且 %IO 却长期 >90% 的进程； - 这类进程往往没在大量写，却长时间卡在 I/O 等待——它可能只是想
fsync()一个日志文件，而那个文件恰好落在坏块附近； - 特别留意
swapper或kswapd出现在 iotop 里：说明内核正在为回收内存疯狂刷脏页，而某些脏页映射到了坏扇区，导致页面回写无限阻塞。
结合 SMART 与 badblocks 定位恶化节奏
坏道的影响是动态加剧的。SMART 只告诉你“有没有风险”，而 real-time I/O 表现告诉你“正在恶化到哪一步”：
- 如果
smartctl -a /dev/sda | grep -E "(Reallocated|Pending|UDMA_CRC)"中 Reallocated_Sector_Ct 在缓慢上升，同时 iostat 的 await 也在逐小时变长，说明坏道在蔓延； - 对 HDD 运行
sudo badblocks -v -s /dev/sda1（只读扫描）可验证是否存在不可读扇区，若中途卡住或报错，基本可判定当前 I/O 卡顿就源于此处； - 注意：SSD 上不要跑
badblocks -w（写模式），它会触发大量写入，加速磨损，应改用smartctl -a查看 Media_Wearout_Indicator 和 Available_Reserve_Space。
