最近发生电源故障，导致我的一台服务器瘫痪。重启时，主存储文件系统（7TB（9x1TB RAID6）文件系统上的 JFS）在挂载读写之前需要进行 fsck。启动 fsck 后，我在 top 中观察了一段时间 - 内存使用率稳步上升（但不是太快），CPU 使用率稳定在 100% 或接近 100%。
现在，大约 12 小时后，fsck 进程已消耗了系统中 4GB 内存的近 94%，而 CPU 使用率已降至 2% 左右。该进程仍在运行（并且没有显示进一步运行时间）。
首先：这是否表明存在问题？我担心 CPU 使用率会急剧下降 - 似乎该过程已受到内存限制，并且 fsck 将永远无法完成，因为它将所有时间都花在了交换上。（我注意到 kswapd0 在 top 中令人不安地徘徊在列表顶部附近，实际上在超过一半的时间内 CPU 使用率超过了 fsck 进程。）如果不是这种情况，如果 fsck 只是在进程结束时 CPU 速度变慢，那很好 - 我只需要知道这一点。
如果这是个问题，我该怎么做才能提高 fsck 的性能？我几乎可以接受任何建议，包括“为系统购买更多内存”。
从顶部开始的相关行：
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
5201 root 20 0 58.1g 3.6g 128 D 2 93.8 1071:27 fsck.jfs
free -m 的结果如下：
total used free shared buffers cached
Mem: 3959 3932 26 0 0 6
-/+ buffers/cache: 3925 33
Swap: 964 482 482答案1
如果我错了请纠正我，但 JFS 不是一个完整的日志文件系统：它只处理日志中的元数据。这意味着如果您有大量数据，则 fsck 命令将需要很长时间才能完成。
我建议您研究切换到完全日志文件系统（etx3 / 4）的可能性：这样在发生突然故障时就无需运行命令。
答案2
根据虚拟内存的使用情况，我认为在任何合理的时间内（即使有额外的 RAM）在卷上运行完整的 fsck 是不可能的，所以我备份了卷上的所有文件并使用 XFS 重新格式化。