最近发生了电源故障，导致我的一台服务器掉线。 在重新启动时，主存储文件系统 – 7TB（9x1TB RAID6）文件系统上的JFS – 在安装读写之前需要fsck。 在我开始使用fsck之后，我观察了一段时间，内存使用率稳步上升（但不是太快），CPU使用率达到或接近100％。
现在，大约12个小时，fsck进程消耗了系统中4GB内存的将近94％，CPU使用率下降到了2％左右。 该进程仍在运行（并没有提供进一步运行时间的指示）。
首先：这是否表示有问题？ 我担心的是CPU使用率已经大幅度下降 – 看起来好像这个过程已经成为内存限制，而fsck将会永远完成，因为它花费了所有的时间。 （我注意到kswapd0浮动在顶部的顶部附近，实际上超过fsck进程的CPU使用率超过一半的时间。）如果情况并非如此，如果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
如果我错了，纠正我，但JFS不是一个完整的日志文件系统：它只处理日志中的元数据。 这意味着如果你有很多数据的话，fsck命令将花费一些时间来完成。
我build议你调查切换到完全日志文件系统（etx3 / 4）的可能性：这应该不需要在突然失败的情况下运行的命令。
根据虚拟内存的使用情况，我认为在任何合理的时间内（即使有额外的RAM），都不可能在卷上运行完整的fsck，因此我备份了卷上的所有文件并使用XFS重新格式化。