dmesg是排查磁盘i/o错误的第一手线索，因其记录内核捕获的硬件级失败快照，如“end_request: i/o error”“unc”等关键词指向物理坏块或链路异常，配合smartctl和badblocks交叉验证才能准确定位故障层级。

Linux 无法直接查看“数据块校验错误”的原始记录，因为 ext4/xfs 等主流文件系统本身不默认开启端到端校验（E2E checksum），也就没有这类日志。真正能查到的，是底层 I/O 失败后由内核或硬件上报的错误事件。

为什么 dmesg 是第一手线索

当磁盘读写时发生 CRC 校验失败、ECC 修正失败或扇区不可读，驱动层会向内核报告，最终落进内核环缓冲区。这些不是“文件系统日志”，而是硬件交互失败的快照。

• 典型错误关键词：end_request: I/O error、sector=、ata[0-9] E\(.*\)failed、Aborting journal on device
• 必须用 sudo dmesg -T | grep -i "error\|fail\|ata\|nvme"，否则时间戳无意义，且默认只显示最近部分
• 注意区分：buffer I/O error 多为上层缓存问题；media error 或 UNC（uncorrectable）才指向物理坏块

smartctl -a 显示的是固件级累计计数，不是实时错误记录

S.M.A.R.T. 不记录每次错误发生的时间和 LBA，只维护几个关键属性的累计值。它告诉你“可能出过问题”，但不告诉你“哪一秒在哪个扇区出了错”。

Zynq Linux Hardware Debug

Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。

下载

• 重点关注三项：Reallocated_Sector_Ct（已重映射扇区）、Current_Pending_Sector（待重映射，最危险）、Offline_Uncorrect（离线校验失败）
• 值为 0 不代表绝对健康；值 >0 也不等于立刻宕机，但 Current_Pending_Sector 持续非零，说明硬盘正在挣扎，应尽快备份并替换
• NVMe 盘要用 sudo smartctl -a -d nvme /dev/nvme0n1，缺 -d nvme 会读不到正确信息

/var/log/kern.log 可能保留更久的错误快照，但需确认日志服务配置

dmesg 缓冲区会滚动覆盖，而 kern.log 是否长期保存取决于 rsyslog 或 journald 的设置。很多生产环境默认只保留最近几天。

• 检查是否启用：grep -q "kern\.log" /etc/rsyslog.conf && echo "enabled"
• 查找磁盘相关错误：sudo grep -i "sd[a-z]\|nvme\|ata" /var/log/kern.log | grep -i "error\|fail\|sector"
• 如果用 systemd-journald，等效命令是：sudo journalctl -k --since "2 weeks ago" | grep -i "error.*sd\|nvme"

badblocks 扫描结果不是“错误记录”，而是当前可复现的故障点

badblocks 不读取历史日志，它主动发起读/写操作去触发并定位失效扇区。输出的数字是逻辑块地址（LBA），不是时间戳或错误类型。

• 只读扫描（sudo badblocks -sv /dev/sdb1）发现的坏块，大概率已在 dmesg 中出现过多次
• 若 badblocks 未报错，但 dmesg 频繁出现 I/O error，说明问题可能是间歇性的（供电不稳、线缆松动、控制器 bug），而非固定坏扇区
• 输出文件（如 badsectors.txt）格式就是纯数字每行一个，可直接喂给 e2fsck -l 让文件系统避开——这才是它的实际用途

真正难的不是“怎么查”，而是判断错误来源层级：是电缆接触不良导致的偶发传输错误，还是 NAND 颗粒老化引起的持续校验失败？dmesg 里的错误上下文、smartctl 的属性趋势、加上 badblocks 的可复现性，三者交叉比对才能下结论。单看某一项，容易误判。