定位磁盘I/O错误应聚焦dmesg报错源头，执行dmesg | grep -i "error|fail|timeout|i/o|buffer"筛选关键线索，如"Buffer I/O error on device sda1"、"end_request: I/O error"、"ata1.00: failed command"或"nvme controller is down"，再联动smartctl检查SMART属性、/var/log/messages确认持续性，并结合iotop、lsof定位阻塞进程与业务文件。
磁盘 I/O 长期过高会引发内核频繁报错，典型表现是 dmesg 或系统日志中持续出现 Buffer I/O error、lost async page write、Medium Error、end_request: I/O error 等记录。这类日志不是偶发警告，而是硬件异常或驱动/文件系统层问题的直接信号，需立即结合 I/O 负载与设备状态综合判断。
查内核错误日志定位具体设备和错误类型
执行以下命令提取最近的磁盘相关错误：
-
dmesg -T | grep -i "error\|fail\|warn" | grep -E "(sd|nvme|vd)"—— 带时间戳过滤磁盘设备错误 -
journalctl -b -p err | grep -i "buffer\|io\|sector\|medium\|hostbyte"—— 查看本次启动以来的系统级 I/O 错误 - 重点关注关键词：
dev sda（设备名）、logical block 123456（坏块位置）、Sense Key: Medium Error（介质故障）、hostbyte=DID_OK driverbyte=DRIVER_SENSE（底层通信异常）
确认是否为长期高 I/O 引发的连锁反应
仅看错误日志不够，必须验证 I/O 压力是否持续存在：
linux-sysadmin
下载
Linux系统管理专家，覆盖12大模块：用户权限、SSH、存储、网络、systemd、防火墙、日志监控、备份恢复、TLS证书、Ansible、容器、IaC。提供配置、验证、加固、监控、备份、自动化、故障排查、回滚闭环。关键词：useradd、sudo、sshd_config、chmod、SEL...
- 运行
iostat -dx 2 5，观察目标设备（如sda）的%util是否长期 ≥85%，await是否稳定 >50ms；若符合，说明设备已饱和，错误很可能是排队超时或重试失败导致 - 用
vmstat 1 10查看bi（块输入）和bo（块输出）是否持续高位，同时检查wa（iowait）是否长期 >20% —— 这表示 CPU 大量时间在等磁盘，内核调度压力增大，易触发日志刷写异常 - 对比
cat /proc/diskstats中对应设备的io_ticks和time_in_queue：数值持续线性增长，说明 I/O 队列长期积压，内核日志中出现“queue full”、“timeout”类提示的概率显著上升
区分硬件故障与软件负载过载
同一类日志可能源于完全不同的根因，需交叉验证：
- 若
dmesg中反复出现Medium Error、UNCORRECT、failed command: READ，且smartctl -a /dev/sdX显示Reallocated_Sector_Ct、Current_Pending_Sector或UDMA_CRC_Error_Count非零，基本可判定是硬盘物理损坏 - 若错误集中在某类操作（如大量
write后报lost async page write），但smartctl健康，iotop又显示某个进程（如数据库、日志服务）持续写入，更可能是软件层资源争抢或缓冲区配置不当，而非硬件问题 - 特别注意：当磁盘空间使用率 >95% 时，ext4/xfs 文件系统可能因无空闲块而拒绝写入，内核会记录
EXT4-fs error或XFS: error，这类错误本质是空间耗尽，不是 I/O 故障本身，但会加剧日志刷写失败
避免误操作加重内核日志污染
排查过程中某些操作反而会触发更多错误日志，务必谨慎：
- 不要在系统响应缓慢或已有 I/O 错误时执行
fsck—— 尤其未卸载分区就强制检查，极易造成二次损坏并刷出大量corruption日志 - 禁用
echo 1 > /proc/sys/vm/drop_caches类命令清理缓存，这会强制回写脏页，在高 I/O 下极易触发 timeout 和 error 日志 - 暂停所有备份、压缩、日志轮转等周期性 I/O 任务，防止干扰判断；可用
systemctl list-timers --all快速识别定时作业
