dmesg 是诊断 i/o 错误的第一入口，需重点抓取 buffer i/o error、blk_update_request、ata/nvme/scsi 层错误；结合 smartctl -a 检查重映射扇区、待处理扇区及链路错误；确认是否只读挂载导致假性报错；再用 iotop/lsof 排除进程干扰，警惕老化指标隐性风险。
dmesg 是第一入口，报 Input/output error 不能只看应用层提示，得立刻下钻到内核设备交互现场。硬件故障的线索几乎全藏在 dmesg 里，而不是 journalctl 或 /var/log/messages。
盯住 dmesg 里这几类关键错误模式
执行 dmesg | grep -i "error\|fail\|timeout\|i/o\|buffer"，重点识别以下输出：
-
Buffer I/O error on device sda1, logical block 123456：明确指向分区和扇区，是后续验证物理坏道的坐标 -
end_request: I/O error或blk_update_request: critical target error：块层已无法完成请求，问题大概率在硬件或驱动层 -
ata1.00: failed command: READ FPDMA QUEUED：SATA控制器报错，优先查线缆、电源、固件 -
nvme 0000:01:00.0: controller is down：NVMe控制器掉线，需查 PCIe 链路状态、温度、BIOS NVMe 支持设置 -
sd 0:0:0:0: SCSI error: returncode = 0x08000002：SCSI 层返回介质错误，常伴随Sense Key: Medium Error
注意：如果同一扇区（如反复出现 logical block 123456）持续报错，基本可判定是物理损坏起点；若错误位置完全随机，更可能是链路或调度问题。
用 smartctl 验证硬盘健康，别跳过 -a 参数
smartctl -a /dev/sdx 输出里的字段不是全都要看，只盯这三项：
-
Reallocated_Sector_Ct> 0：已有扇区被重映射，物理坏道已存在 -
Current_Pending_Sector> 0：有扇区读取失败但尚未重映射，硬盘正处在失效临界点 -
UDMA_CRC_Error_Count或Link_Up_Count异常波动：说明数据线接触不良或接口供电不稳，不是盘本身问题
执行前确认设备名准确——lsblk 和 lshw -class disk 比凭经验猜 sda 更可靠。NVMe 盘要用 smartctl -a /dev/nvme0n1，别套用 SATA 命令。
别急着 fsck，先确认是不是只读挂载触发的假性 I/O error
内核检测到 I/O 错误后会自动把文件系统设为只读（ro），此时所有写操作都会报 Input/output error，但磁盘可能还完好。
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 运行
mount | grep sdx查看是否含ro标志 - 检查
dmesg | tail -20是否有Remounting filesystem read-only提示 - 若确认无硬件报错，可尝试
mount -o remount,rw /dev/sdx1测试是否恢复 - 若 remount 失败或立即又变
ro，说明底层错误仍在，必须停止写入并备份
特别注意：ext4 分区在只读状态下仍允许部分元数据更新（如 atime），也可能触发二次错误，所以只要看到 ro 就该默认进入“保护模式”。
交叉验证：用 iotop 和 lsof 排除进程级干扰
硬件故障常被高 IO 进程掩盖，尤其是断电后文件系统元数据混乱时，某些进程会反复重试读写，把偶发错误放大成持续卡死。
- 运行
iotop -oPa看哪些进程在持续刷READ/WRITE，重点关注D状态（不可中断睡眠）进程 - 对疑似进程执行
lsof -p PID，确认它正在访问哪个文件或设备节点 - 若发现某进程在疯狂读一个明显损坏的文件（如日志轮转残留、数据库 WAL 文件），临时 kill 它可能让系统暂时恢复响应，便于你继续诊断
真正棘手的是那些不暴露在 iotop 里的内核线程（如 kblockd、ksmd），它们的阻塞往往意味着底层设备已失联——这时候 dmesg 里一定有未被 grep 到的控制器超时记录，建议加 -T 参数看时间戳对齐。
最易被忽略的一点：很多工程师查完 smartctl 显示 PASSED 就松口气，但没注意到 Power_On_Hours 已超 50000 小时，或 Temperature_Celsius 长期高于 55°C。硬件老化不是突然发生的，是这些“尚可工作”的指标在悄悄滑坡。
