ext4挂载失败因主superblock损坏，应先用e2fsck -n -b指定备份superblock（如8193）检测，确认可用后再修复；遇“UNEXPECTED INCONSISTENCY”需人工介入，优先-p自动修复；SSD上先blkdiscard再fsck可提速；路径恢复需debugfs或外部快照，e2fsck无法还原文件名。
ext4 文件系统挂载失败，dmesg 显示 EXT4-fs (sda1): unable to read superblock
这是最典型的损坏信号：主超级块（superblock）读取失败，文件系统无法识别。ext4 默认只在特定位置写入一个主 superblock（通常是 1024 字节偏移），一旦该区域物理损坏或被覆盖，mount 就会直接报错。
实操建议：
- 别急着
fsck—— 先用e2fsck -n -b 8193 /dev/sda1尝试备份 superblock（ext4 每 8192 个块会存一份备份，常见备份位置有8193、32768、98304等，具体查dumpe2fs -h /dev/sda1 2>/dev/null | grep -i "superblock backup"） - 如果
-b指定备份 superblock 后能成功-n检查（只读模式），说明主 superblock 损坏但数据区尚可读，此时再用e2fsck -b 8193 /dev/sda1强制修复 - 切忌在未确认备份 superblock 可用前直接运行无参数
e2fsck /dev/sda1，它默认用主 superblock，可能触发误判并破坏更多元数据
运行 e2fsck 提示 UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY
这说明文件系统处于非正常卸载状态（比如断电、强制关机），内核标记了“dirty”位，拒绝自动挂载。不是严重损坏，但必须人工介入。
实操建议：
- 先确认设备未被挂载：
mount | grep sda1和lsof +D /mnt/point都得为空；否则e2fsck会拒绝运行 - 优先用
e2fsck -p /dev/sda1自动修复（-p= preen，仅处理可安全自动修复的问题）；若返回非零码，再考虑-y -
-y虽方便，但会跳过所有交互确认——如果 inode 链接数异常或目录项损坏，它可能把孤立文件全丢进lost+found，而你根本不知道哪些是重要数据 - 修复后务必检查
/lost+found下的#编号文件，用file和strings快速判断是否是你需要的配置或日志
恢复出的文件名全是 #12345，原始路径和文件名全丢了
这是因为 ext4 的目录项（directory entry）结构损坏，e2fsck 只能根据 inode 内容重建硬链接，但无法还原目录树和文件名。名字信息不在 inode 里，而在父目录的数据块中。
