Une limitation pour avoir plusieurs fichiers dans un répertoire sous Mac OS X?

J'ai plus de 100 000 fichiers dans un répertoire de mon MacOS X et il semble lent que mon script y lise un fichier.

Y a-t-il une limitation ou une recommandation pour avoir autant de fichiers? Dois-je les diviser en certains répertoires?

La limitation que j'ai trouvée est que je ne peux pas mv * foopour les 100 000 fichiers. Il affiche une erreur indiquant "argument trop long". Il fonctionne avec environ moins de 20 000 fichiers.

Selon cette réponse Stack Overflow et des détails spécifiques sur le site d'Apple , un dossier individuel peut contenir jusqu'à 2,1 milliards d'éléments.

Cela dit, ce n'est pas parce qu'il peut contenir jusqu'à 2,1 milliards d'articles qu'il peut maintenir les performances à ce niveau. Selon Wikipedia ; l'accent est sur moi:

Le fichier catalogue, qui stocke tous les enregistrements de fichiers et de répertoires dans une seule structure de données, entraîne des problèmes de performances lorsque le système autorise le multitâche, car un seul programme peut écrire dans cette structure à la fois, ce qui signifie que de nombreux programmes peuvent être en attente dans la file d'attente. en raison d'un programme "monopolisant" le système. Il s'agit également d'un sérieux problème de fiabilité, car des dommages à ce fichier peuvent détruire l'intégralité du système de fichiers.

Les performances sont donc naturellement dégradées grâce au fait que le fichier catalogue ne peut être utilisé que par un programme à la fois. Et si le répertoire augmente en taille, le risque / dégradation causé par ce problème ne fera qu'augmenter; plus de fichiers signifie plus de chance pour les programmes d'accéder aux fichiers de ce répertoire. Confirmation supplémentaire de cette idée ici ; encore une fois, l'accent est sur moi:

Le fichier catalogue est une structure compliquée. Parce qu'il conserve toutes les informations sur les fichiers et les répertoires, il force la sérialisation du système de fichiers, ce qui n'est pas une situation idéale lorsqu'un grand nombre de threads souhaitent effectuer des E / S sur les fichiers. Dans HFS, toute opération qui crée un fichier ou modifie un fichier de quelque manière que ce soit doit verrouiller le fichier de catalogue, ce qui empêche les autres threads d'accéder même en lecture seule au fichier de catalogue. L'accès au fichier catalogue doit être à rédacteur unique / multireader.

Réponse courte: Eh bien, si vous lisez 100 000 fichiers, je pourrais m'attendre à ce que le script soit lent.

Réponse longue: Pour répondre à cette question de manière plus approfondie, vous devez examiner le système de fichiers sur un Mac. Les Mac utilisent le HFS + ( Hierarchical File System Plus ), qui est un système de fichiers moderne qui a ses limites, mais uniquement dans des situations extrêmes.

D'après mon expérience, cela ressemble beaucoup à un système de fichiers de journalisation Linux EXT. Il prend en charge les répertoires de montage, de type UNIX autorisations, etc. Il traite des fichiers dans un format 32 bits, ce qui rend le nombre maximum de fichiers qui peuvent être stockés dans un volume 4294967295, selon cette source de .

Le système de fichiers commence à rompre avec des fichiers supérieurs à 8 EB sur les systèmes modernes et jusqu'à 2,1 milliards de fichiers et dossiers en un seul endroit, comme indiqué ici .

Étant donné la façon dont le HFS + - ou vraiment n'importe quel système de fichiers est configuré d'ailleurs - avoir beaucoup de fichiers dans un dossier ne devrait rien faire de «bizarre».

Honnêtement, je ne pense pas qu'il y aurait une amélioration des performances en répartissant les fichiers sur une hiérarchie de dossiers plus complexe. En fait, cette technique pourrait être moins efficace car votre script devrait effectuer des appels pour changer de répertoire au milieu du processus.