web-dev-qa-db-ja.com

JFS：大きなファイルシステムでfsck時間が長いですか？

最近、サーバーの1つを停止させる停電が発生しました。再起動時に、メインストレージファイルシステム（7TB（9x1TB RAID6）ファイルシステム上のJFS）は、読み取り/書き込みをマウントする前にfsckを必要としました。 fsckを開始した後、しばらくの間、トップでそれを監視しました。メモリ使用量は着実に増加し（ただし、それほど速くはありません）、CPU使用率は100％またはほぼ100％に固定されていました。

現在、約12時間で、fsckプロセスはシステム内の4GBのメモリのほぼ94％を消費し、CPU使用率は約2％に低下しました。プロセスはまだ実行中です（さらに実行時間については何も示されません）。

まず最初に：これは問題を示していますか？ CPU使用率が劇的に低下したという事実が心配です。プロセスがメモリバウンドになったかのように見えます。また、fsckはすべての時間をスワッピングに費やしているため、完了するまでに永遠に時間がかかります。 （kswapd0が一番上のリストの一番上近くに不快に浮かんでいることに気づきました。実際には、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
linuxperformancefilesystemsfsckjfs
1
Tim

仮想メモリの使用量に基づいて、ボリューム上で（RAMが追加されていても）妥当な時間内にフルfsckを実行することは不可能であると考えたため、ボリューム上のすべてのファイルをバックアップし、XFSで再フォーマットしました。

0
Tim

私が間違っている場合は訂正してください。ただし、JFSは完全なジャーナリングファイルシステムではありません。ジャーナル内のメタデータのみを処理します。これは、大量のデータがある場合、fsckコマンドの完了に時間がかかることを意味します。

完全にジャーナルされたファイルシステム（etx3/4）に切り替える可能性を調査することをお勧めします。これにより、突然の障害が発生した場合にコマンドを実行する必要がなくなります。

2
Stephane