NTFS を使用する Windows は、大量のファイルとディレクトリをどのように処理しますか?
パフォーマンスの問題やその他の問題が発生する前に、単一のディレクトリに配置できるファイルまたはディレクトリの制限に関するガイダンスはありますか?
たとえば、100,000 個のフォルダーを含むフォルダーを作成しても問題ありませんか?
James Newton-King
質問する
134958 次
7 に答える
287
これは、数千万のファイルを含むフォルダーがある環境の誰かからのアドバイスです。
- フォルダは、インデックス情報（子ファイルと子フォルダへのリンク）をインデックスファイルに保存します。子供が多い場合、このファイルは非常に大きくなります。フォルダである子とファイルである子を区別しないことに注意してください。唯一の違いは、実際には、その子のコンテンツが子のフォルダインデックスまたは子のファイルデータのいずれかであるということです。注：私はこれをいくらか単純化していますが、これで要点がわかります。
- インデックスファイルは断片化されます。断片化しすぎると、そのフォルダにファイルを追加できなくなります。これは、許可されるフラグメントの数に制限があるためです。これは仕様によるものです。サポートインシデントコールでMicrosoftに確認しました。したがって、フォルダに含めることができるファイル数の理論上の制限は数十億ですが、最初に断片化の制限に達するので、数千万のファイルにぶつかり始めたら幸運を祈ります。
- しかし、すべてが悪いわけではありません。ツールcontig.exeを使用して、このインデックスを最適化できます。インデックスのサイズ（数千万のファイルで最大数ギグに達する可能性があります）を減らすことはできませんが、フラグメントの数を減らすことはできます。注：ディスクデフラグツールは、フォルダのインデックスをデフラグしません。ファイルデータをデフラグします。contig.exeツールのみがインデックスをデフラグします。参考：これを使用して、個々のファイルのデータを最適化することもできます。
- デフラグを実行する場合は、フラグメントの最大数に達するまで待たないでください。手遅れになるまで待っていたため、デフラグできないフォルダがあります。次のテストは、いくつかのファイルをそのフォルダーから別のフォルダーに移動して、デフラグできるかどうかを確認することです。これが失敗した場合、私がしなければならないことは1）新しいフォルダを作成することです。2）ファイルのバッチを新しいフォルダに移動します。3）新しいフォルダをデフラグします。これが完了するまで＃2と＃3を繰り返してから、4）古いフォルダを削除し、古いフォルダと一致するように新しいフォルダの名前を変更します。
あなたの質問にもっと直接的に答えるために：あなたが100Kのエントリーを見ているなら、心配はありません。ノックアウトしてください。数千万のエントリを見ている場合は、次のいずれかです。
a）それらをサブフォルダーに分割する計画を立てます（たとえば、1億個のファイルがあるとします。1つの大きなフォルダーに保存するよりも、フォルダーごとに100,000個のファイルしかないように1000個のフォルダーに保存することをお勧めします。これフラグメントの最大数の制限に達する可能性が高い単一の大きなインデックスではなく、1000のフォルダインデックスを作成します。
b）大きなフォルダのインデックスを最適化しておくために、contig.exeを定期的に実行する計画を立てます。
退屈している場合にのみ、以下をお読みください。
実際の制限は、フラグメントの数ではなく、フラグメントへのポインタを格納するデータセグメントのレコード数にあります。
つまり、ディレクトリデータのフラグメントへのポインタを格納するデータセグメントがあります。ディレクトリデータには、ディレクトリに保存されていると思われるサブディレクトリとサブファイルに関する情報が保存されます。実際、ディレクトリは何も「保存」しません。これは、記憶媒体自体が線形であるため、ユーザーに階層の錯覚を提示する単なる追跡および表示機能です。
于 2008-11-14T20:27:10.173 に答える
50
また、短いファイル名を作成すると速度が低下するというパフォーマンス上の問題もあります。フォルダに 30 万を超えるファイルがある場合、Microsoft は短いファイル名の作成をオフにすることをお勧めします [1]。最初の 6 文字の固有性が低いほど、これは問題になります。
[1] How NTFS Works http://technet.microsoft.comから「300,000」を検索
于 2009-03-25T20:51:07.293 に答える
15
100万あればいいのに。
私は（逸話的に）何百万ものファイルで問題を抱えている人々を見てきました.6万を超える数千のファイルを数える方法がわからないだけでExplorerに問題がありましたが、話しているボリュームにはNTFSが適しているはずです。
ご参考までに、技術的な (そして理論的なことを願っています) ファイルの最大数は 4,294,967,295 です。
于 2008-10-13T10:14:24.297 に答える
8
ローカル アクセスの場合、多数のディレクトリ/ファイルは問題にならないようです。ただし、ネットワーク経由でアクセスしている場合は、数百回後にパフォーマンスが著しく低下します (特に Vista マシンからアクセスした場合 (XP から Windows Server w/NTFS への移行は、その点ではるかに高速に実行されるようです))。
于 2008-10-13T11:57:11.140 に答える
2
N 個のエントリを持つフォルダを作成すると、ファイル システム レベルで N 個のアイテムのリストが作成されます。このリストは、システム全体の共有データ構造です。その後、エントリを追加/削除してこのリストを継続的に変更し始めると、共有データに対するロックの競合が少なくとも発生することが予想されます。この競合は、理論的には、パフォーマンスに悪影響を与える可能性があります。
読み取り専用のシナリオでは、多数のエントリを持つディレクトリのパフォーマンスが低下する理由は想像できません。
于 2008-10-13T14:56:05.583 に答える
2
1 つのオンライン ライブラリをコピーしているときに、ディレクトリ内の NTFS で約 100,000 個のファイル (それぞれ数 MB) を実際に使用した経験があります。
エクスプローラーや 7-zip でディレクトリを開くのに約 15 分かかります。
でのサイトコピーの書き込みwinhttrackは、しばらくすると常にスタックします。また、約 1 000 000 個のファイルを含むディレクトリも扱いました。最悪なのは、MFT がシーケンシャルにしかトラバースできないことだと思います。
ext3 の ext2fsd の下で同じものを開くと、ほぼ同じタイミングが得られました。おそらく、(reiser4fs ではなく) reiserfs に移行することが役に立ちます。
この状況を回避しようとするのがおそらく最善です。
fs なしで blob を使用する独自のプログラムでは、有益な場合があります。これは、Facebook が写真を保存する方法です。
于 2017-03-14T16:12:06.437 に答える