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 里，而在父目录的数据块中。
实操建议：
- 别指望
e2fsck恢复路径——它不存路径，只存链接关系；debugfs是更底层的选择：debugfs /dev/sda1进入后用ls -l查看 inode 列表，icat提取单个 inode 内容，logdump看日志（如果启用了 journal） - 若启用了 ext4 journal（默认开启），且 journal 未损坏，
debugfs -R "logdump" /dev/sda1 | tail -50有时能翻出最近删除/重命名的文件名线索 - 真正要保路径，得靠外部快照（LVM snapshot）或备份工具（rsync + 时间戳目录），
e2fsck本身不提供路径级恢复能力
SSD 上做 e2fsck 特别慢，甚至卡在 Pass 1: Checking inodes, blocks, and sizes
SSD 的磨损均衡和写放大机制会让 ext4 的块扫描逻辑效率骤降，尤其是当存在大量已 TRIM 却未及时回收的块时，e2fsck 仍会逐块验证，实际是在读取无效扇区。
实操建议：
- 先运行
sudo blkdiscard /dev/sda1（确保分区未挂载！）清空 SSD 无效映射，再e2fsck，速度常提升 3–5 倍 - 避免在 RAID 或 LVM 逻辑卷上直接运行
e2fsck—— 应先停用 RAID/LVM，确认底层物理设备状态，否则可能因层间缓存不一致导致误报 - 对大容量盘（>2TB），加
-C 0实时显示进度，比默认静默强得多；加-j /path/to/journal指定外部 journal（如果原 journal 损坏）可绕过部分阻塞点
fsck -y，把还能抢救的目录结构彻底抹平。 
