dmesg | grep -i "ext4\|xfs\|btrfs\|error\|corrupt\|io"可快速定位内核上报的文件系统异常，如ext4-fs error、xfs: log i/o error等第一手错误信息，配合journalctl和fsck -n可精准诊断根因。
直接看 dmesg 里带文件系统关键词的错误
内核在检测到 ext4、xfs 或 btrfs 等文件系统异常时，会立刻往内核日志里写入明确提示，比如 EXT4-fs error、XFS: log I/O error、btrfs: failed to read chunk tree。这些不是猜测，是内核主动上报的“第一手病历”。
执行这条命令就能快速筛出来：
dmesg | grep -i "ext4\|xfs\|btrfs\|error\|corrupt\|io"
注意要点：
-
dmesg输出的是环形缓冲区内容，重启后旧记录可能丢失；若已重启，得结合journalctl -k - 不要只搜
error，很多关键线索藏在failed、bad、invalid、journal这类词里 - 如果输出为空但怀疑有问题，先运行
dmesg -T（带时间戳）再人工扫一遍，有时错误没触发 grep 模式但肉眼可见
查 journalctl 里 systemd 捕获的挂载/IO 错误
systemd 会在服务启动失败或设备异常时记录更结构化的上下文，比如 Failed to start File System Check on /dev/sda2 或 Mount unit for /home failed，这类日志比 dmesg 更贴近用户态行为。
推荐组合命令：
journalctl -p err -t kernel | grep -i "fs\|mount\|block"
或者查最近 1 小时内所有与存储相关的报错：
journalctl --since "1 hour ago" | grep -E "(fsck|mount|block|sd[a-z]|nvme|failed.*filesystem)"
关键区别：
-
journalctl -p err只取错误级别，但会漏掉 warn 级别的早期预警（如ext4: warning: maximal mount count reached），必要时换成-p warning - 如果系统用了 XFS，
xfs_repair运行失败时通常不会进journalctl，但会在dmesg留下XFS: failed to initialize the log类信息 - 某些发行版（如 RHEL/CentOS）把 fsck 日志单独记在
/run/initramfs/rdsosreport.txt，得手动翻
用 fsck -n 模拟检查，看它具体卡在哪一步
当 dmesg 和 journalctl 都只显示“挂载失败”但没说原因时，fsck -n 是最准的诊断探针——它不改数据，只报告问题位置和类型。
操作前必须确保分区已卸载（umount /dev/sdXN），然后运行：
fsck -n -t ext4 /dev/sda1
常见返回含义：
-
/dev/sda1: clean, 123456/2097152 files, 789012/8388608 blocks→ 表面正常，但可能掩盖 journal 损坏（需加-f强制检查） -
Inode 123456 has invalid mode (0)→ inode 元数据损坏，大概率要丢这个文件 -
UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.→ 文件系统标记为 dirty，但上次 fsck 没跑完 -
Group descriptors look bad...→ 超级块或组描述符损坏，可能要用e2fsck -b 32768指定备份超级块
注意：fsck -n 对 XFS 无效（它不支持只读检查），得换 xfs_repair -n /dev/sda1；Btrfs 则用 btrfs check --readonly /dev/sda1。
别忽略 /var/log/fsck/ 下的残留日志
有些发行版（如 Debian/Ubuntu）会在每次开机自动 fsck 后，把详细结果存进 /var/log/fsck/ 目录，文件名通常是 checkroot 或 checkfs。这些日志里常有被 dmesg 截断的完整路径和 inode 编号。
检查方式很简单：
ls -lt /var/log/fsck/ && tail -n 20 /var/log/fsck/checkroot
容易踩的坑：
- 该目录默认只有 root 可读，普通用户得加
sudo - 日志只保留最近几次，老记录会被轮转走，
zcat /var/log/fsck/checkroot.1.gz可能挖出线索 - 如果系统根本没生成这个目录，说明 fsck 没被触发过——那问题大概率出在硬件层（SMART 报错、
dmesg | grep "ata.*error"才是下一步）
真正难定位的不是报错本身，而是报错发生前 5 分钟内有没有 ata timeout、end_request: I/O error 这类底层 IO 故障。它们才是文件系统出错的根因，但常被后续的 ext4 error 掩盖。
