JFS:在大型文件系统上长时间的fsck？

Question

最近我的一台服务器出了故障。在重新启动时，主存储文件系统-- 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

而免费-m的结果是：

             total       used       free     shared    buffers     cached 
Mem:          3959       3932         26          0          0          6 
-/+ buffers/cache:       3925         33 
Swap:          964        482        482

Answer 1

根据虚拟内存的使用情况，我认为不可能在任何合理的时间内(即使有额外的RAM)在卷上运行完整的fsck，所以我备份了卷上的所有文件并使用XFS重新格式化。

Answer 2

如果我错了，请纠正我，但是JFS不是一个完整的日志文件系统:它只处理日志中的元数据。这意味着如果您有大量数据，fsck命令将需要很长时间才能完成。

我建议您研究切换到完全日志记录的文件系统(etx3 3/4)的可能性:这将消除在发生突然故障时运行命令的需要。