fsckは、30 TBボリューム）をどのくらいの時間かかることができますか？
11月中旬に、ホスティング会社からレンタルしているVPSが応答しなくなりました。サポートに連絡したところ、データセンターの停電が原因で強制再起動とfsckが発生したと説明されました。結局、なぜこんなに時間がかかるのかと尋ねると、ボリュームのサイズは30 TBだと言われました。更新を最後に受け取ったのは2月で、最近の問い合わせには回答がありません。
一部のファイルシステムではfsckが非常に遅くなる可能性があることを理解していますが、fsckが30 TBボリューム）で6か月かかる可能性はありますか。毎月支払いを続けるには？
fsck速度は主に、ファイルの数とそれぞれのディレクトリでのファイルの分散方法に依存します。とはいえ、fsckの6か月はまったくばかげています。特に、高速なxfsを使用している場合は、最大で数時間で完了しているはずですxfs_repairユーティリティ。 ここ いくつかのfsck実行を大規模に実行できます-すべて1時間（3600秒）未満で完了します。したがって、fsckがまだ実行されていることはありません。
とにかく、予期しない停電が発生してもは全速fsckではなく、非常に速い（数秒） ジャーナル再生 。ただし、一部の重要なファイルが破損している場合、OSが起動できなくなる可能性があります。
しかし、彼らはおそらくあなたに嘘をついただけでしょう。すぐに支払いを停止し、説明を求め、全額返金を申請する必要があります。
予想：彼らのシステムはBBU/FBWCなしのRAID（またはソフトウェアRAID）を使用しており、可能な限りすべての書き込みキャッシュ（ハードドライブ自体に含まれるものも含む）を最も積極的な設定に設定して、最小限のコストで最大のパフォーマンスを実現します。このような設定での停電により、ジャーナリングファイルシステムは、ジャーナルが信頼できず、リカバリに使用できない状態になる可能性があります。問題は、そのようなシステムが書き込みを積極的に並べ替えて延期することです。つまり、データアクションが失われたり、結果として発生したデータアクションでジャーナルエントリが失われたりして、ジャーナルエントリを書き込むことができます。
最悪のケースの停止からそのようなシステムを回復することは、実際にすべてのファイルシステム構造を実際に検査する「遅い」fsck/repairを実行する必要があることを意味する可能性があり、実際には30TBで1〜2日かかることがあります。複数の修理サイクルを実行する必要がある可能性は低くありません。これに加えて、担当者が常にこれを監視できるとは限らないため、1週間に1つのfsckを簡単に実行できる可能性があります。彼らはおそらくあきらめて、忘れました。
通常、メタデータのみがチェックされるため、ほとんどのファイルシステムでは、エラーが発生した場合でも、はるかに高速になります。
最悪の場合、ディスク全体を読み取る可能性があります。（egfsck.ext4 -cc /dev/sdaのようなもので、毎回非破壊的な書き込みテストを行いますブロック）、30 TBの場合、数日かかる場合があります。ドライブの速度がわかっている場合は、size/speedを計算できます。約100 MB/sのコンシューマハードドライブの場合、数個のTBをコピーすると、ほとんどの人よりも時間がかかる場合があります期待する。
それがサーバーである場合、fsckがエラーを修正するかどうか尋ねてきたときに、サーバーが起動してハングするという問題がある可能性があります。しかし、データセンターの管理者は、すべてのVPSがオフラインである間、fsckを6か月間放置し続けることはありません。
だから彼らはあなたに嘘をついているか、大きな誤解があります。または、彼らはしばらく前にfsckを実行していて、終了後に新しい問題について更新しませんでした。