为什么文件系统检查这么慢
你可能遇到过这种情况：服务器重启后卡在“Checking filesystem”界面，几分钟甚至几十分钟都没动静。看着进度条纹丝不动，心里直打鼓，是不是硬盘坏了？其实不一定是硬件问题，更多时候是检查过程本身太耗时。
文件系统检查（fsck）会在系统非正常关机后自动触发，目的是修复可能的元数据损坏。但如果磁盘容量大、文件数量多，或者存在大量未清理的 inode，检查时间自然会拉长。
跳过不必要的检查
如果你确定上次关机是正常的，或者只是临时测试机器，完全可以手动跳过检查。在 GRUB 启动界面按 e 编辑启动参数，在内核行末尾加上 fastboot 或 fsck.mode=skip，然后按 Ctrl+X 启动。
linux /boot/vmlinuz root=UUID=xxxx-xxxx quiet fastboot调整文件系统检查频率
Linux 默认每 30 次挂载或 180 天就会强制检查一次 ext4 文件系统。这个值可以通过 tune2fs 调整。比如你想改成 180 天检查一次：
tune2fs -i 180d /dev/sda1如果想完全禁用时间周期，只按挂载次数算：
tune2fs -i 0 /dev/sda1注意：不建议完全禁用，定期检查能避免小问题积累成大故障。
减少挂载次数触发条件
默认每 30 次挂载就检查一次，对于频繁重启的测试环境来说太频繁。可以改成 100 次甚至更高：
tune2fs -c 100 /dev/sda1查看当前设置：
tune2fs -l /dev/sda1 | grep -i check检查过程中卡住？可能是硬件问题
如果 fsck 长时间卡在某个百分比（比如 75%），特别是伴随硬盘异响，那可能是物理坏道。这时候不要强行中断，否则可能导致文件系统更严重损坏。建议接上外部电源和散热，保持稳定运行。
如果是虚拟机，确保磁盘镜像没有存储在慢速设备上，比如网络挂载的 NFS 目录。
使用备用超级块恢复
主超级块损坏时，fsck 会尝试从备份中恢复，但这个过程会变慢。提前记录好备用超级块位置能加快处理：
dumpe2fs /dev/sda1 | grep -i superblock使用备用超级块手动检查：
fsck -b 32768 /dev/sda1日常维护建议
定期清理大目录下的碎片文件，比如 /tmp、/var/log。一个包含几十万个文件的目录，光扫描 inode 就可能花十几分钟。合理设置日志轮转，避免单个分区塞满小文件。
对于生产服务器，建议在维护窗口执行手动检查，而不是等重启时被动触发。提前发现问题，避免上线时卡在检查界面出不来。