系统异常关机后必须立即运行e2fsck：需先卸载文件系统，再强制检查修复；不可对已挂载分区操作；须区分e2fsck与fsck；RAID/LVM环境须自底向上检查；云盘需先确认存储健康。
系统异常关机后必须立即运行 e2fsck
当服务器因断电、内核 panic 或强制重启导致未正常卸载 ext4/ext3 文件系统时，日志可能处于不一致状态，此时挂载会自动触发只读模式或拒绝挂载。必须在文件系统未挂载（或以只读方式挂载）的前提下手动执行 e2fsck。常见错误是直接对已挂载的分区运行，这会导致数据损坏风险——e2fsck 会报错 The filesystem is mounted; will not check 并退出。
- 先确认挂载状态：
mount | grep /dev/sda1，若已挂载，用umount /dev/sda1卸载（无法卸载时需确认无进程占用：lsof +D /mnt/data） - 执行检查：
e2fsck -f -y /dev/sda1（-f强制检查，-y自动确认修复） - 若提示“journal is corrupt”，可加
-c尝试恢复日志，或用e2fsck -b 32768指定备份超级块（需提前用dumpe2fs -h /dev/sda1 | grep "Backup superblock"查找）
定期计划检查不能依赖 fs_passno 字段自动触发
/etc/fstab 中的第六列 fs_passno（如设为 1 或 2）仅控制 fsck 在系统启动时的执行顺序和是否跳过，它不会替代人工维护。现代 systemd 系统默认禁用启动时自动检查（除非文件系统标记为“需要检查”），且即使启用，也仅在“挂载次数达阈值”或“上次检查距今超指定天数”时触发，而这两个阈值常被忽略或设得过大（如默认 30 次挂载才检查一次）。
- 查看当前设置：
tune2fs -l /dev/sda1 | grep -E "(Mount count|Maximum mount count|Check interval)" - 建议调低频率：
tune2fs -c 20 -i 30d /dev/sda1（每 20 次挂载或 30 天强制检查一次） - 但注意：生产环境不建议在业务高峰期自动触发
fsck，应改为人工安排维护窗口，并使用e2fsck -n先做只读检测（-n 不修改，仅报告问题）
e2fsck 与 fsck 的本质区别必须分清
fsck 是通用前端命令，实际行为取决于文件系统类型；而 e2fsck 是专用于 ext2/3/4 的底层检查工具。直接调用 fsck /dev/sda1 可能因系统未识别类型而失败，或误调用其他文件系统的检查器（如 xfs_repair），造成严重后果。尤其在多文件系统混用环境中（如 root 是 ext4、/home 是 xfs），混淆命令极易出错。
- 永远优先显式调用
e2fsck检查 ext 系列分区 -
fsck -t ext4 /dev/sda1是安全的等价写法，但不如直接用e2fsck明确 - 切勿对 XFS 分区运行
e2fsck——它会报错Bad magic number in super-block并拒绝操作，但反复尝试可能干扰元数据
RAID 或 LVM 下的检查顺序不能颠倒
在 LVM 或软件 RAID（如 mdadm）上部署 ext4 时，检查必须从底层物理设备开始逐层向上：先确认 RAID 阵列状态正常（cat /proc/mdstat），再检查 LVM 物理卷（pvs/vgs），最后才是逻辑卷对应的设备节点（如 /dev/mapper/vg0-lv_root）。若跳过底层直接检查 LV，e2fsck 可能因底层设备不可靠而误报或漏报坏块。
- RAID 同步中禁止运行
e2fsck，否则可能引发 I/O 冲突，延长同步时间甚至导致阵列降级 - LVM 快照卷（snapshot）不能直接用
e2fsck检查原始 LV —— 必须先激活快照（lvchange -ay /dev/vg0/lv_root_snap），再对其设备节点检查 - 云平台（如 AWS EBS）挂载的卷，需确认底层存储健康状态（通过云控制台或
smartctl -a /dev/xvdf）后再执行文件系统检查
e2fsck 运行期间磁盘 I/O 压力极大，且无法中断（Ctrl+C 可能导致元数据损坏），务必确保有足够空闲内存（至少 1GB）和稳定电源。静默失败比报错更危险——比如检查中途因磁盘响应慢被 kill，e2fsck 可能不输出任何提示就退出。 
