Mac OS Xのディレクトリに多くのファイルを置くことに対する制限はありますか？

MacOS Xのディレクトリに100,000以上のファイルがあり、スクリプトがそれらのファイルを読み取るのが遅いようです。

それだけ多くのファイルを作成するための制限や推奨事項はありますか？それらをいくつかのディレクトリに分割する必要がありますか？

私が見つけた制限は、mv * foo100,000のファイルすべてに対応できるわけではないということでした。「引数が長すぎます」というエラーが表示されます。約20,000ファイル未満で動作します。

このスタックオーバーフローの回答とAppleのサイトの具体的な詳細によれば、個々のフォルダーには最大21億個のアイテムを含めることができます。

とはいえ、最大21億個のアイテムを保持できるからといって、そのレベルでパフォーマンスを維持できるわけではありません。ウィキペディアによると、強調は私のものです：

すべてのファイルとディレクトリレコードを単一のデータ構造に保存するカタログファイルは、システムがマルチタスクを許可している場合、一度に1つのプログラムしかこの構造に書き込むことができないため、多くのプログラムがキューで待機している可能性があるため、パフォーマンスの問題が発生します。 1つのプログラムがシステムを「占有」するため。このファイルへの損傷はファイルシステム全体を破壊する可能性があるため、これは深刻な信頼性の問題でもあります。

したがって、カタログファイルは一度に1つのプログラムでしか使用できないという事実により、パフォーマンスは当然低下します。また、ディレクトリのサイズが大きくなると、その問題によって引き起こされるリスク/機能低下がエスカレートするだけです。ファイルが多いほど、プログラムがその1つのディレクトリ内のファイルにアクセスできる可能性が高くなります。ここでそのアイデアをさらに確認します。再び強調は私のものです：

カタログファイルは複雑な構造です。すべてのファイルとディレクトリ情報を保持するため、ファイルシステムのシリアル化を強制します。ファイルI / Oを実行したいスレッドが多数ある場合は、理想的な状況ではありません。HFSでは、ファイルを作成したり、何らかの方法でファイルを変更したりする操作では、カタログファイルをロックする必要があります。これにより、他のスレッドがカタログファイルへの読み取り専用アクセスすらできなくなります。カタログファイルへのアクセスは、シングルライター/マルチリーダーである必要があります。

短い回答：ええと、100,000個のファイルを読み取っている場合は、スクリプトが遅いと思うかもしれません。

長い答え：この質問にもっと完全に答えるには、Macのファイルシステムを調べる必要があります。MacはHFS +（Hierarchical File System Plus）を使用します。これは、制限がありますが、極端な状況でのみ使用できる最新のファイルシステムです。

私の経験から、それはLinux EXTジャーナリングファイルシステムによく似ています。このソースによると、マウントディレクトリ、UNIXライクなアクセス許可などをサポートしています。32ビット形式のファイルに対処し、ボリュームに保存できるファイルの最大数を4,294,967,295にしています。

ここで説明するように、ファイルシステムは、最新のシステムでは8 EBを超えるファイルと、1つの場所に最大21億個のファイルとフォルダーで壊れ始めます。

HFS +（または実際にはすべてのファイルシステムがセットアップされている）の方法を考えると、フォルダーに多くのファイルを置いても、「奇妙な」ことはありません。

正直なところ、ファイルをより複雑なフォルダー階層に分散することでパフォーマンスが向上することはないと思います。実際には、スクリプトがプロセスの途中でディレクトリを変更するための呼び出しを行う必要があるため、この手法は効率が悪くなる可能性があります。