文件系统检查修复日志的位置
在日常使用 Linux 系统时，偶尔会遇到开机自动进行文件系统检查（fsck）的情况。比如某天重启服务器后卡在“Checking filesystems”界面，等它跑完才能进系统。这时候你可能会想：它到底查了啥？有没有发现错误？修好了吗？这些信息都记录在日志里，但很多人不知道去哪找。
最常见的文件系统检查日志位置是 /var/log/fsck/ 目录下。不同的发行版处理方式略有差异，但大多数现代 Linux 系统都会将 fsck 的输出保存到这里。
具体查看方法
以 Ubuntu、Debian 或 CentOS 8+ 为例，可以这样查看：
ls /var/log/fsck/<br>cat /var/log/fsck/checkfs
<br># 或者按日期命名的日志文件
cat /var/log/fsck/fsck.<date>如果系统在启动时执行了 fsck，但没有生成对应日志，可能是该目录为空或日志被重定向到了其他地方。这时可以尝试查看系统默认的启动日志。
通过 journalctl 查看实时记录
对于使用 systemd 的系统，fsck 的输出通常也会被 journalctl 捕获。可以直接运行：
journalctl | grep -i fsck或者查看本次启动的完整日志：
journalctl -b在输出中搜索 “filesystem check” 或设备名（如 /dev/sda1），就能看到是否执行了检查、是否有错误以及是否成功修复。
特殊情况：临时文件系统未挂载导致无日志
有些老旧系统或精简安装的环境可能没创建 /var/log/fsck 目录，或者 /var 分区还没挂载时就执行 fsck，这时日志无法持久化保存。常见表现是明明看到启动时跑了 fsck，但进去后找不到任何记录。这种情况下，除非手动重定向输出，否则日志只会显示在控制台屏幕上，不会落地到文件。
为了避免遗漏关键信息，建议在维护服务器时养成习惯：每次重启后第一时间检查上述路径和 journalctl 输出，尤其是当系统异常断电或磁盘报错之后。
手动运行 fsck 时的日志处理
如果你是手动执行 fsck 命令来修复分区，例如：
sudo fsck -y /dev/sdb1此时命令本身不会自动写入日志文件，需要自行重定向输出：
sudo fsck -y /dev/sdb1 > /var/log/fsck-manual-sdb1.log 2>&1这样下次排查问题就有据可查，避免重复操作或遗漏修复细节。