Mac OS Xのディレクトリに多くのファイルを置くことに関する制限はありますか？
MacOS Xのディレクトリに100,000以上のファイルがあり、スクリプトがそれらのファイルを読み取るのに時間がかかるようです。
その数のファイルを持つための制限や推奨事項はありますか？それらをいくつかのディレクトリに分割する必要がありますか？
私が見つけた制限は、100,000個のファイルすべてに対してmv * fooできないということでした。 「引数が長すぎます」というエラーが表示されます。約20,000未満のファイルで動作します。
このStack Overflowの回答 および特定の Appleのサイトの詳細 によると、個々のフォルダには最大21億のアイテムを含めることができます。
とはいえ、最大21億個のアイテムを保持できるからといって、そのレベルでパフォーマンスを維持できるとは限りません。 ウィキペディアによると ;強調は私のものです：
すべてのファイルとディレクトリレコードを単一のデータ構造に格納するカタログファイルは、システムがマルチタスクを許可する場合、一度に1つのプログラムのみがこの構造に書き込むことができるため、パフォーマンスの問題が発生しますつまり、1つのプログラムがシステムを「占有」しているために、多くのプログラムがキューで待機している可能性があります。このファイルが損傷するとファイルシステム全体が破壊される可能性があるため、これは信頼性に関する重大な懸念事項でもあります。
そのため、カタログファイルは一度に1つのプログラムでしか使用できないため、パフォーマンスは自然に低下します。また、ディレクトリのサイズが大きくなると、その問題によって引き起こされるリスク/劣化はエスカレートするだけです。ファイルが多いほど、プログラムがその1つのディレクトリ内のファイルにアクセスする可能性が高くなります。さらに ここでそのアイデアの確認 ;再び強調は私のものです：
カタログファイルは複雑な構造です。すべてのファイルとディレクトリの情報を保持するため、ファイルシステムのシリアル化が強制されます。これは、ファイルI/Oを実行するスレッドが多数ある場合の理想的な状況ではありません。 HFSでは、ファイルを作成したり、ファイルを変更したりする操作では、カタログファイルをロックする必要があります。これにより、他のスレッドがカタログファイルに読み取り専用でアクセスすることさえできなくなります。カタログファイルへのアクセスは、シングルライター/マルチリーダーである必要があります。
短い答え：ええと、100,000個のファイルを読んでいるとしたら、スクリプトが遅いと思うかもしれません。
長い答え：この質問にもっと完全に答えるには、Macのファイルシステムを調べる必要があります。 MacはHFS +（ Hierarchical File System Plus ）を使用します。これは、制限がありますが、極端な状況でのみ使用される最新のファイルシステムです。
私の経験からすると、LinuxEXTジャーナリングファイルシステムによく似ています。ディレクトリのマウント、UNIXライクなアクセス許可などをサポートします。32ビット形式のファイルをアドレス指定し、 this ソースによると、ボリュームに格納できるファイルの最大数を4,294,967,295にします。
ファイルシステムは、最近のシステムでは8 EBを超えるファイルと、概説されているように1つの場所に最大21億のファイルとフォルダーで壊れ始めます ここ 。
HFS +（または実際には任意のファイルシステムのセットアップ方法）を考えると、フォルダー内に多数のファイルがあると、「奇妙な」ことは何も起こりません。
正直なところ、より複雑なフォルダ階層にファイルを分散することでパフォーマンスが向上することはないと思います。実際には、スクリプトがプロセスの途中でディレクトリを変更するために呼び出しを行う必要があるため、この手法は効率が低下する可能性があります。