NTFSのパフォーマンスが悪い
Linux/ext3などと比較してNTFSのパフォーマンスが非常に悪いのはなぜですか？ほとんどの場合、Subversionから（大きな）ソースツリーをチェックアウトするときにこれが表示されます。 NTFSではチェックアウトに約10〜15分かかりますが、Linux（ほぼ同じハードウェア）での対応するチェックアウトには1桁速くなります（1〜1.5分）。
たぶん、これは多くの小さなファイルの処理に固有であり、大きなファイルに関してはNTFSの方が優れていますが、なぜそうする必要があるのでしょうか。小さなファイルのNTFSパフォーマンスを改善することは、一般的にWindowsのパフォーマンスにとって非常に有益ではないでしょうか。
編集：これは、「NTFSはext3と比較してひどい」という炎症の質問を意味するものではありません。私は本当に興味がありますなぜ NTFSは特定の場合に悪いパフォーマンスをします。それは単に悪いデザイン（私は疑っています）ですか、それとも他の問題が関係していますか？
NTFSには、 マスターファイルテーブル と呼ばれるものがあります。あなたがそれについて読むとき、それは本当にクールに聞こえます。
Ext3は最大約95％のディスク使用量で問題なく動作することがわかりますが、MFTが存在するということは、NTFSがディスクの90％以上を使用することを実際には望んでいないことを意味します。しかし、それはあなたの問題ではなく、あなたの問題は多くの小さなファイルに対する多くの操作にあると思います。
ここでの違いの1つは、小さなファイルを作成したときに何が起こるかです。ファイルがブロックサイズよりも小さい場合、ファイルはそれ自体のブロックに書き込まれるのではなく、MFTに保存されます。ファイルが作成時の状態のままであれば、これは素晴らしいことです。ただし、実際には、svnがファイルに触れてファイルを作成し、そのファイルに追加したり、ファイルから削除したり、ファイルを独自のブロックに移動するのに十分でないために変更したりすると、操作がかなり遅くなります。また、小さなファイルをたくさん読み取るだけで、ブロックごとに複数のファイルが存在するMFTにいくらかのストレスがかかります。なぜこれを行うのでしょうか？先制的に断片化を回避し、より多くのブロックをより効果的に使用することであり、一般的にはそれは良いことです。
対照的に、ext2および3では、すべてのファイルのファイルブロックは、それらが存在するディレクトリのディレクトリメタデータがある場所の隣に保存されます（可能な場合、ディスクが断片化されておらず、約20％の空き容量がある場合）。これは、svnがディレクトリを開いているときに、ドライブ上の16 MBのキャッシュに基本的に無料でキャッシュされ、次にカーネルのキャッシュにキャッシュされることを意味します。これらのファイルには、最後の更新の.svnファイルとリビジョンファイルが含まれている場合があります。これらはsvnが次に調べているファイルの一部である可能性が高いため、これは便利です。 NTFSはこれを実行できませんが、MFTの大部分はシステムにキャッシュする必要がありますが、次に必要になる部分ではない可能性があります。
さて、あなたの特定の問題は
- Subversion自体はUNIXの世界から来ているため、Windowsバージョンは同様のパフォーマンス特性を前提としています。
- NTFSのパフォーマンスは、膨大な数の小さなファイルでは実際には優れていません。
表示されているのは、特定のオペレーティングシステム用に設計されたものの成果物であり、そのオペレーティングシステムのパフォーマンスを前提としています。これは通常、他のシステムに持ち込まれると、ひどく故障します。他の例としては、フォークとスレッドがあります。 UNIXライクでは、何かを麻痺させる従来の方法は、別のプロセスを生成することです。プロセスの開始に少なくとも5倍の時間がかかるWindowsでは、これは本当に悪い考えです。
一般に、特定のOSのアーティファクトを、アーキテクチャが大きく異なる他のOSに付与することはできません。また、NTFSには、ジャーナリングやACLなど、その時点で広く使用されていたUNIXファイルシステムにはなかった多くのファイルシステム機能があることを忘れないでください。それらにはコストがかかります。
いつの日か、暇なときに、トランザクションサポート（「何百万もの小さなファイルに触れる」問題を解消する必要があります）や代替データなど、NTFSの機能を活用するSVNファイルシステムモジュールを作成することを計画していました。ストリーム（個別の.svnディレクトリの必要性を排除する必要があります）。持っているのはいいことですが、SVN開発者が近い将来にそのようなものを実装することを回避できるとは思えません。
補足：私が使用している大規模なSVNリポジトリでの1回の更新には、約250,000のファイル操作が必要でした。いくつかの小さな声は、これは変更された24個のファイルにとって本当に重要であると私に伝えます...
これがMicrosoftの info NTFSのしくみについてです。探しているものにはやり過ぎかもしれませんが、それを研究することで、NTFSに問題があるシナリオに光を当てることができます。