NTFSとHFS、ext3、その他の数千のファイルに対するファイル操作のパフォーマンス

Question

[私の HNの投稿を聞くからクロスポストされました。質問がスーパーユーザーにとって広すぎる場合は、遠慮なく閉じてください。]

これは私が何年もの間興味を持っていたものですが、このトピックに関する良い議論は見つかりませんでした。もちろん、私のグーグルフーは私を失敗させているかもしれません...

私はしばしば、何千もの比較的小さなファイルを含むプロジェクトを扱います。これは、これらのファイルのすべてまたはそれらの大部分に対して頻繁に操作を実行していることを意味します。プロジェクトフォルダーを別の場所にコピーしたり、一時ファイルの束を削除したりします。長年作業してきたすべてのマシンの中で、私はNTFSがこれらのタスクを処理するのがMacのHFSやLinuxボックスのext3/ext4よりも一貫して遅いことに気づきました。ただし、私が知る限り、NTFSでは生のスループットが実際に遅くなることはありません（少なくとも大幅にではありません）が、個々のファイル間の遅延はほんの少し長くなります。そのわずかな遅延は、実際には何千ものファイルになります。

（補足：私が読んだところによると、これがgitがWindowsで非常に苦痛である理由の1つです。これは、オブジェクトデータベースをファイルシステムに大きく依存しているためです。）

確かに、私の証拠は単なる逸話です。現在、実際のパフォーマンスの数値はありませんが、さらにテストしたいものです（MacをWindowsにデュアルブートする場合など）。それでも、私のオタクは、そこにいる誰かがすでに持っていると主張しています。

誰かがこれを説明できますか、あるいはそれを自分でさらに研究するための正しい方向に私を向けることができますか？

Bruce Ediger · Accepted Answer

私はHFSの専門家ではありませんが、NTFSおよびext3ファイルシステムを調べました。 2つのことを考えるべきだと思われます。

まず、ext2/3/4ファイルシステムは、ファイルメタデータ（ファイルのデータを構成する権限、所有権、ブロックまたはエクステント）を格納するためにディスク上の領域を事前に割り当てます。 NTFSはそうは思わない。 ext3の「inode」に相当するのは$ MFTレコードです。ファイルを作成するときに、$ MFTレコードが必ずしも割り当てられているとは限らないことを理解しています。 $ MFTは、必要に応じて拡張できます。 ext2/3/4ファイルシステムのiノードの数を増やすことははるかに困難です。

私はNTの内部に精通していませんが、$ MFTレコードが必要に応じて作成されるようにすべてが読み取られるため、小さなファイル、ディレクトリ、大きなファイルを散在させることができます。

Ext2/3/4ファイルシステムが最も確実であるBSDFFSスタイルのファイルシステムの場合、ディスク上のiノードをグループ化し、ディレクトリファイルをiノードから分離することに多くのことが費やされています。しかし、ディレクトリとメタデータを効率的かつ安全に書き出すことに多くのことが費やされています。例として： http://www.ece.cmu.edu/~ganger/papers/softupdates.pdf を参照してください。

第二に、私が物事を正しく読んだ場合、小さなファイルのデータは$ MFTレコードに保持されます。これはext2/3/4には当てはまりません。そのため、小さいファイルと大きいファイルの処理は少し異なります。

NT（オペレーティングシステム）が$ MFTの競合に苦しんでいるように私には聞こえます。ディレクティブが更新されます。これは$ MFTレコードの更新です。小さなファイルが作成されます。これは$ MFTの更新です。すべてのメタデータの更新とデータの書き込みはすべて同じ「ファイル」$ MFTに送られるため、OSは読み取りと書き込みを効率的に順序付けることができません。

しかし、私が言ったように、ただの推測です。 NTFSについての私の知識は、主に読書からのものであり、それを実験することからはごくわずかです。 HFTが「ディレクトリ」と「iノード」を「ファイルデータ」とは別に保持しているかどうかを確認することで、私の推測を再確認できます。もしそうなら、それは大きなヒントかもしれません。