断电后文件系统损坏，e2fsck 是 ext4 的首选修复工具，但必须在分区未挂载时运行；强行对已挂载的根分区执行 fsck 会大概率导致数据二次损坏。
直接说结论：断电后文件系统损坏，e2fsck 是 ext4 的首选修复工具，但必须在分区未挂载时运行；强行对已挂载的根分区执行 fsck 会大概率导致数据二次损坏。
怎么确认是 ext4 损坏而不是硬件故障
先别急着修，先排除硬盘本身问题。断电后常见症状（如 ls: reading directory '/data': Input/output error 或 dmesg 里反复出现 EIO）容易误判为文件系统损坏，其实是磁盘物理层出问题。
- 运行
smartctl -a /dev/sdX查看Reallocated_Sector_Ct和Current_Pending_Sector，非零值说明有坏道，此时修复文件系统意义不大 - 用
lsblk和blkid /dev/sdX1确认分区确实是ext4类型，避免对 XFS 分区误用e2fsck - 检查
dmesg | grep -i "EXT4-fs error"—— 如果有这类日志，基本可锁定是 ext4 元数据损坏，不是驱动或 I/O 调度问题
为什么不能直接在正常系统里运行 fsck /dev/sda1
fsck 是个“外科医生”，但它要求手术部位完全静止。Linux 内核一旦挂载了 ext4 分区，就会持续读写日志、更新位图、缓存元数据——此时运行 fsck 相当于在心脏跳动时做开胸手术。
- 对已挂载的分区执行
fsck -y /dev/sda1，内核可能返回busy device错误，也可能静默失败，更糟的是它真改了某些结构而内核还按旧状态运行，导致后续panic - 根分区尤其危险：
fsck /dev/sda2在多用户模式下运行，几乎必然引发不可逆损坏；必须进recovery mode或从 Live USB 启动 - 即使你看到
UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY提示，那也是 initramfs 阶段检测到的，此时系统尚未挂载根，fsck是安全的
e2fsck 常见参数组合的实际效果
e2fsck 不是“一键修复”按钮，不同参数对应完全不同的风险等级和修复深度：
-
e2fsck -n /dev/sdX1：只读扫描，输出所有错误但不修改。适合首次评估损坏程度，比如看到大量Inode bitmap differences就说明位图错乱严重 -
e2fsck -y /dev/sdX1：自动应答所有修复请求。仅适用于非关键数据分区（如临时存储盘），对数据库目录慎用 -
e2fsck -f -y /dev/sdX1：强制完整检查（绕过 “clean” 标记）。断电后必须加-f，否则可能跳过实际损坏区域 -
e2fsck -b 32768 /dev/sdX1：指定备份超级块位置修复。当主超级块损坏时有效，但需先用dumpe2fs /dev/sdX1 | grep "Backup superblock"查准位置
修复后挂载失败或仍报 I/O 错误怎么办
修复完成不代表万事大吉。常见后续问题往往被忽略：
- 修复后立即
mount /dev/sdX1 /mnt失败？检查/etc/fstab中该分区的fs_passno字段（第三个字段）是否为0，若为0，fsck不会在启动时自动检查，下次断电还会重蹈覆辙 - 挂载成功但
ls仍卡住？可能是底层块设备响应异常，运行hdparm -I /dev/sdX看是否识别为“ATA device”，再试dd if=/dev/sdX1 of=/dev/null bs=1M count=100测读取稳定性 -
lost+found里出现大量数字命名文件？说明修复过程中回收了孤儿 inode，这些文件内容可能残缺，需人工比对时间戳和大小判断是否可用
真正容易被忽略的点是：修复操作本身不恢复已丢失的文件内容，只重建目录结构和元数据。如果断电时正在写入一个大文件，e2fsck 可能把它截断成前半部分，或者干脆丢进 lost+found —— 这时候得靠备份，而不是指望工具“变出来”。
