fsckは30 TBのボリュームでどれくらいの時間がかかりますか？

11月中旬に、ホスティング会社からレンタルしているVPSが応答しなくなりました。サポートに連絡すると、データセンターの停電が原因で強制的な再起動とfsckが発生したと説明されました。最終的に、なぜそんなに時間がかかったのかと尋ねると、ボリュームのサイズは30 TBだと言われました。最後に更新を受け取ったのは2月で、最近の問い合わせには回答していません。

一部のファイルシステムではfsckが非常に遅くなる可能性があることを理解していますが、30 TBのボリュームでfsckが6か月かかることはありますか？月？

fsck速度は主に、ファイルの数と、それぞれのディレクトリでのファイルの広がりに依存します。とfsckはいえ、aの6か月はまったくばかげています。特にxfs高速xfs_repairユーティリティを使用している場合は、せいぜい数時間で完了するはずです。ここでは、いくつかfsckの大規模な実行を見つけることができます-すべてが1時間（3600秒）以内に完了しました。したがって、fsckまだ実行されていることはできません。

とにかく、予想外の電力損失はフルブローを引き起こさずfsck、むしろ非常に速い（数秒）ジャーナル再生のみを引き起こします。ただし、一部のキーファイルが破損していると、OSが起動できなくなる可能性があります。

しかし、彼らはおそらくあなたに嘘をついただけでしょう。すぐに支払いを停止し、説明を求め、全額払い戻しを申請してください。

推測：システムは、BBU / FBWCなしのRAID（またはソフトウェアRAID）を使用し、すべての可能な書き込みキャッシュ（ハードドライブ自体にあるものを含む）を最も積極的な設定に設定して、最小限のコストで最大限のパフォーマンスを実現します。そのようなセットアップでの停電により、ジャーナルが信頼できず、リカバリに使用できない状態にジャーナリングファイルシステムが残る場合があります。問題は、そのようなシステムが書き込みを積極的に並べ替え、延期することです。つまり、データアクションが失われたり、結果として生じたデータアクションでジャーナルエントリが失われたりして、ジャーナルエントリを書き込むことができます。

このようなシステムを最悪の停止から回復するには、すべてのファイルシステム構造を実際に検査する「遅い」fsck / repairを実行する必要があります。複数の修復サイクルを実行する必要があることはありそうにありません。これに加えて、これを監視する担当者が常に利用できるとは限らないので、週に1つのfsckを簡単に実行できます。彼らはおそらくあきらめて忘れてしまった。

通常、メタデータのみがチェックされるため、エラーが発生した場合でも、ほとんどのファイルシステムでははるかに高速です。

最悪の場合、ディスク全体（たとえばfsck.ext4 -cc /dev/sda、ブロックごとに非破壊的な書き込みテストを実行するようなもの）を読み取る可能性があり、30 TBでは数日かかります。ドライブの速度がわかっている場合は、サイズ/速度を計算できます。約100 MB / sのコピーを備えた一般消費者のハードドライブの場合、ほとんどの人が予想するよりも数TBの時間がかかります。

サーバーである場合fsck、エラーを修正するかどうかを尋ねられたときに起動してハングするという問題が発生する可能性があります。ただし、データセンター管理者はfsck、すべてのVPSがオフラインになっている間、6か月間ハングアップすることはありません。

だから彼らはあなたに嘘をついているか、大きな誤解があります。または、彼らはしばらく前にfsckを実行していましたが、新しい問題については終了後に更新しませんでした。