dmesg 不停刷 I/O error，磁盘还能读该先做哪一步

同类问题我见过几次，现场表现一样但根因不同，所以第一步是把范围缩小。 系统整体变慢，dmesg -T 里每隔几分钟就出现 blk_update_request 的 I/O error，还带着设备名和一串扇区号，业务侧偶发超时。

拖得越久，排查成本越高，因为现场状态会被后续操作覆盖。

先分清是哪一类原因

1. 云盘底层介质出现坏块，重试之后只有部分读请求能够成功
2. 文件系统已经标记了坏块，每次访问到那片区域都会报错
3. 磁盘队列被打满导致请求超时，被内核统一判定成 I/O 错误

按顺序处理

1. 统计报错频率和涉及的扇区

dmesg -T | grep -c 'I/O error'

2. 查文件系统自身记录的错误次数

dumpe2fs -h /dev/vdb1 | grep -i error

3. 先把重要数据同步出去

rsync -a --inplace /data/ /mnt/backup/data/

4. 联系云厂商换盘并核对阵列状态

mdadm --detail /dev/md0

怎么确认已经恢复

dmesg 不再新增 I/O error，比对目标目录的文件数量与大小和原盘一致，业务超时也随之消失。

容易忽略的地方

I/O error 会越拖越多，先拷贝再做 fsck，顺序反了可能把还能读的块彻底弄坏；换盘之前别急着重启机器，现场状态很有用。 涉及改配置的操作，改完记得做一次完整的回归，别只看当前这个报错有没有消失。