Ext4ディスクチェックがNTFSよりもはるかに高速なのはなぜですか？
今日、コンピュータを再起動したときに、ディスクの整合性をチェックする必要があるという状況が発生しました。約10分後（「1％」完了）、あきらめて家に帰ったら実行させることにしました。
比較のために、私の自宅のコンピューターはすべてのパーティションにExt4を使用しており、ディスクチェック（週に1回程度実行）は数秒しかかかりません。ディスクチェックを高速化することが優先事項だったと読んだことを覚えていますが、どうすればそれができるのかわかりません。
では、Ext4はどのようにしてディスクチェックをそれほど高速に行うのでしょうか？ NTFSがリリースされた後（約10年前）にこれを行うことに大きな進歩はありますか？
注：NTFSディスクは最大300 GB、Ext4ディスクは最大500GBです。どちらも約半分になっています。
パフォーマンスの違いには2つの主な理由と、2つの可能性がある理由があります。まず、主な理由：
ext4とNTFSのパフォーマンスの向上
さまざまなベンチマーク 実際のext4ファイルシステムは、NTFSパーティションよりもさまざまな読み取り/書き込み操作高速を実行できると結論付けています。これらのテストは実際のパフォーマンスを示すものではありませんが、これらの結果を推定して、これを1つの理由として使用できることに注意してください。
なぜext4が実際に優れたパフォーマンスを発揮するのかについては、NTFSにはさまざまな理由があります。たとえば、ext4は遅延割り当てを直接サポートします。ただし、パフォーマンスの向上は、使用しているハードウェアに厳密に依存します（場合によっては、完全に無効になる可能性があります）。
ファイルシステムチェック要件の削減
Ext4ファイルシステムは、他の同等のジャーナリングファイルシステム（NTFSなど）よりも より高速なファイルシステムチェック を実行することもできます。ウィキペディアのページによると：
Ext4では、未割り当てのブロックグループとiノードテーブルのセクションがそのようにマークされます。これにより、e2fsckはチェックでそれらを完全にスキップでき、ext4がサポートするように構築されているサイズのファイルシステムをチェックするのにかかる時間を大幅に短縮します。この機能は、Linuxカーネルのバージョン2.6.24に実装されています。
そして今、2つの可能性の理由：
ユーティリティ自体をチェックするファイルシステム
特定のアプリケーションは、ファイルシステム上で異なるルーチンを実行して、実際にヘルス「チェック」を実行する場合があります。これは、Linuxではfsckユーティリティセットを、Windowsではchkdskユーティリティを使用すると簡単に確認できます。これらのアプリケーションは、さまざまなファイルシステムのさまざまなオペレーティングシステムで作成されています。これを可能な理由として取り上げる理由は、各オペレーティングシステムの低レベルシステムコールが異なるため、2つのユーティリティを使用してユーティリティを直接比較できない可能性があるためです。さまざまなオペレーティングシステム。
ディスクの断片化
これは理解しやすく、ファイルシステム間の違いを理解するのにも役立ちます。ファイルに保持されているすべてのデジタルデータは同じですが、どのようにハードドライブに保存されるかは、ファイルシステムごとにまったく異なります。ファイルの断片化は明らかにアクセス速度を上げる可能性があり、速度の違いが大きくなります。
私の理解では、ext4は、現在データが存在しないオープンiノードの最大の連続ギャップにデータを書き込もうとします。これにより、これらのファイルを読み取る必要がある場合の待ち時間が大幅に短縮されます。ほとんどの場合、個々のファイルのコンテンツ全体が1つの連続したトラック上にあるため、データを含むすべてのブロックを検索するときにドライブヘッドが行う必要が少なくなります。それが1つのファイルを構成します。
それ（ext4）は依然として断片化する可能性がありますが、断片化ははるかに少なく、必ずしもNTFSの場合のように読み取り/書き込みパフォーマンスに深刻な影響を与えるわけではありません。 NTFSでは、データはヘッドのパスの最初の開いているブロックに書き込まれます。
したがって、ヘッドがあり、開いているブロックがある場合は、そのデータを可能な限り書き込み、ヘッドがディスクの別の部分に移動して別のファイルにアクセスする必要がある場合は、ディスク上の他の場所にある場所に書き込みます。他のファイルがまだ書き込まれている間に、ロードしたばかりのプログラムで開く必要があります。
これは、ファイルが大きい場合、ファイルが別々のトラックで互いに分離されたブロックに分散される可能性が高いことを意味し、NTFSでデフラグが頻繁に必要になる理由です。
また、24時間年中無休でデータの書き込みと読み取りが行われているサーバーではI/Oが重いため、サーバーが一般的に使用しない理由もあります。
また、私はわかりませんが、chkdskが各ファイルの整合性をチェックする場合（私はそれとfsckの両方がそうであると私は信じています）、先ほど説明したことにより、比較も遅くなります。 NTFSの断片化。
Windowsは、起動時にNTFSボリュームをチェックする必要はありません。もしそうなら、何かがひどく間違っている-単なるBSODや停電よりもはるかに悪い何か。ファイルシステムのメタデータが破損したために、一部のデータも破損した可能性があります。ディスクチェックはそれを検出できません。その唯一の目的は、さらなる破損を回避することです。
KB285457 は、これが発生する可能性があるいくつかの理由を示しています。 1つは、ボリュームがマウントされたOSを休止状態にし、ボリュームの内容を変更してから、ボリュームを（再）接続した状態で休止状態から再開することです。これを行うと、サイレントデータが破損する可能性が高くなります。
Ext4ファイルシステムが週に1回自分自身をチェックしている理由はわかりませんが、おそらく（うまくいけば）週に1回繰り返される危機が原因ではなかったのでしょう。おそらく、完全な整合性チェックではなく、定期的なサニティチェックを行っているだけです。
UNIX/Linux Ext2/Ext3/Ext4テクノロジーは、ペイントのスプレー缶とは異なり、NTFSが磁気データビットを配置するのとは異なり、データビットのはるかにタイトな磁気ストリップを配置するためです。 NTFSは通常の「デフラグ」を必要としますが、Ext2/3/4はめったにデフラグを必要としません。それはそれと同じくらい簡単です。 UNIX/Linuxドライブから何かが必要な場合-OSは、しっかりと磁化されたデータビットのチップをピックアップする場所を正確に認識していますが、NTFSは、それらをピックアップするためにドライブディスク全体をスクランブルする必要があります。 NTFSジャーナルシステムは非常にうまく機能します-しかし、頭は置かれた磁気ビットを拾うためにポンを演奏しています。デュアルFATファイルシステムはうまく機能しますが、1ビットのブッシェルを収集するために何エーカーも走らなければならない場合は、ビットの文字列全体を取得する必要がなく、取得できる場合ははるかに高速です。