なぜExt4ディスクチェックはNTFSよりもずっと速いのですか？

今日、コンピューターを再起動したときに、ディスクの整合性を確認する必要があると言われました。約10分後（「1％」完了時）、私はあきらめ、家に帰ったときに実行させることにしました。

比較のために、私の自宅のコンピューターはすべてのパーティションにExt4を使用しており、ディスクチェック（週に1回実行される）には数秒しかかかりません。高速なディスクチェックを行うことが優先事項であったことを読んだことを覚えていますが、どうすればそれができるのかわかりません。

それでは、どのようにExt4はディスクチェックを非常に高速に行うのでしょうか？NTFSがリリースされた後（約10年前）、これを行う際に大きなブレークスルーがありますか？

注：NTFSディスクは最大300 GB、Ext4ディスクは最大500 GBです。両方とも約半分です。

パフォーマンスの違いには2つの主な理由と、考えられる 2つの理由があります。まず、主な理由：

ext4とNTFSのパフォーマンスの向上

さまざまなベンチマークにより、実際のext4ファイルシステムは、NTFSパーティションよりも高速にさまざまな読み取り/書き込み操作を実行できると結論付けられています。これらのテストは実際のパフォーマンスを示すものではありませんが、これらの結果を推定し、これを1つの理由として使用できることに注意してください。

ext4のパフォーマンスがNTFSよりも優れている理由については、さまざまな理由が考えられます。たとえば、ext4は遅延割り当てを直接サポートします。繰り返しますが、パフォーマンスの向上は使用しているハードウェアに厳密に依存します（特定のケースでは完全に無効になる可能性があります）。

ファイルシステムのチェック要件の削減

ext4ファイルシステムは、他の同等のジャーナリングファイルシステム（NTFSなど）よりも高速なファイルシステムチェックを実行することもできます。ウィキペディアのページによると：

ext4では、未割り当てのブロックグループとinodeテーブルのセクションはそのようにマークされます。これにより、e2fsckはチェックでそれらを完全にスキップでき、ext4がサポートするために構築されたサイズのファイルシステムをチェックするのにかかる時間を大幅に短縮します。この機能は、Linuxカーネルのバージョン2.6.24で実装されています。

そして今、考えられる 2つの理由：

ファイルシステムチェックユーティリティ自体

特定のアプリケーションは、ファイルシステム上で異なるルーチンを実行して、実際にヘルス「チェック」を実行する場合があります。これは、Linuxではfsckユーティリティセットを使用し、Windowsではchkdskユーティリティを使用する場合に簡単に確認できます。これらのアプリケーションは、ファイルシステムごとに異なるオペレーティングシステムで記述されています。考えられる理由としてこれを取り上げる理由は、各オペレーティングシステムの低レベルシステムコールが異なるため、2つの異なるオペレーティングシステムを使用してユーティリティを直接比較できない場合があるためです。

ディスクの断片化

これは簡単に理解でき、ファイルシステム間の違いを理解するのにも役立ちます。ファイルに保持されているすべてのデジタルデータは同じですが、ハードドライブに保存される方法は、ファイルシステムごとにまったく異なります。ファイルの断片化により、明らかにアクセス速度が向上し、速度の差が大きくなることがあります。

私の理解では、ext4は、現在データが存在しないオープンiノードの最大連続ギャップにデータを書き込もうとします。ほとんどの場合、個々のファイルのコンテンツ全体が単一の連続したトラック上にあるため、これらのファイルを読み取る必要がある場合、レイテンシが大幅に削減されるため、ドライブヘッドは、データを含むすべてのブロックを見つけるときに行うシークが少なくなりますその1つのファイルを構成します。

それ（ext4）はまだ断片化する可能性がありますが、断片化ははるかに少なく、必ずしもNTFSのように読み取り/書き込みパフォーマンスに深刻な影響を与える方法ではありません。NTFSでは、データはヘッドのパスの最初の開いているブロックに書き込まれます。

そのため、ヘッドがどこにあり、開いているブロックがある場合でも、可能な限り多くのデータを書き込み、次に、ヘッドがディスクの別の部分に移動して別のファイルにアクセスする必要があるときに、ディスク上の他の場所にある場所に書き込みます他のファイルがまだ書き込まれている間にロードしたプログラムで開く必要があります。
これは、ファイルが大きい場合、別々のトラックで互いに分離されたブロックに分散される可能性が高いことを意味し、NTFSで頻繁にデフラグが必要になるのです。

また、データがディスク24/7から絶えず書き込まれたり読み取られたりするサーバーでは、より重いI / Oが行われているため、サーバーが一般的に使用しない理由。

また、確信はありませんがchkdsk、各ファイルの整合性をチェックする場合（それが信じられますfsckが）、NTFSでのフラグメント化について説明したことにより、比較すると遅くなります。

Windowsは、起動時にNTFSボリュームを確認する必要はありません。もしそうなら、何かが真剣に間違っています。単なるBSODや停電よりもはるかに悪いものです。ファイルシステムのメタデータが破損したため、一部のデータも破損した可能性があります。ディスクチェックはそれを検出できません。その唯一の目的は、さらなる破損を回避することです。

KB2854570には、これが発生する可能性のあるいくつかの理由がリストされています。1つは、ボリュームがマウントされたOSを休止状態にし、ボリュームの内容を変更してから、ボリュームを（再）接続した状態で休止状態から再開することです。これを行うと、サイレントデータ破損の可能性が高くなります。

ext4ファイルシステムが週に1回自分自身をチェックしている理由はわかりませんが、おそらく（おそらく）毎週繰り返される同様の危機によるものではありません。おそらく、完全な一貫性チェックではなく、日常的な健全性チェックを行っているだけでした。