linux系统启动时自动运行fsck仅在文件系统标记为“dirty”、挂载次数或检查间隔超阈值、或存在/forcefsck文件等特定条件下触发，而非每次开机都执行；ext系列由e2fsck处理，xfs需xfs_repair，btrfs则用btrfs check，且禁用需谨慎评估风险。
Linux 系统启动时会自动触发 fsck，但不是每次开机都执行——它只在检测到文件系统“不干净”或满足特定条件时才运行。理解触发逻辑，能帮你判断是否该干预、何时需手动介入，避免误操作或忽略潜在风险。
什么情况下启动时自动运行 fsck
系统通过内核和 init 系统（如 systemd）协作判断是否需要检查：
- 上一次关机非正常：断电、强制重启、内核 panic 后，ext 类文件系统会在超级块中标记为 “dirty”，下次启动时自动触发 fsck
- 挂载次数达到阈值：使用
tune2fs设置了最大挂载次数（如tune2fs -c 30 /dev/sda1），达到后强制检查 - 自上次检查已超指定天数：通过
tune2fs -i 30d /dev/sda1设置时间间隔，超期即检查 - 文件系统被显式标记需检查：例如手动创建
/forcefsck文件（sudo touch /forcefsck），重启后 fsck 执行并自动删除该文件
如何确认启动时是否真运行了 fsck
启动过程中若 fsck 被调用，屏幕通常会显示类似 *** Checking filesystem on /dev/sda1 的提示；也可事后验证：
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 查看启动日志：
journalctl -b | grep -i "fsck\|checking\|e2fsck" - 检查上次检查时间：
s dumpe2fs -h /dev/sda1 | grep -E "(Last mounted|Last checked|Check interval)" - 观察根分区挂载状态：若启动卡在维护模式（提示
Give root password for maintenance），大概率是 fsck 中止并等待人工干预
不同文件系统的处理差异
并非所有文件系统都走同一套 fsck 流程：
-
ext2/ext3/ext4：由
e2fsck实际执行，支持日志回滚，多数错误可自动恢复，fsck 调用的是fsck.ext4 -
XFS：
fsck命令对 XFS 是空操作（不生效），真正修复需用xfs_repair；系统启动时若检测到 XFS 异常，会调用xfs_repair -L（慎用，-L 清日志）或依赖其内置日志机制自行恢复 -
Btrfs：不依赖传统 fsck，而是用
btrfs check或btrfs scrub进行一致性校验，启动时不自动运行 fsck
禁用或延迟启动时 fsck 的常见做法
生产环境有时需跳过自动检查以缩短启动时间，但需明确风险：
- 临时跳过：在 GRUB 启动菜单中编辑内核参数，添加
fsck.mode=skip（systemd 系统）或fastboot（SysVinit） - 永久调整：修改
/etc/fstab第六列（pass）字段，设为0表示不参与启动检查（仅适用于非根分区，如/home、/data） - 延长检查周期：
tune2fs -i 0 /dev/sda1可关闭基于时间的检查，但不建议对关键系统分区这么做
