j'ai eu plus de 8 millions de fichiers ext3 répertoire. libc readdir() qui est utilisé par find , ls et la plupart des autres méthodes discutées dans ce thread pour lister les grands répertoires.

la raison pour laquelle ls et find sont lents dans ce cas est que readdir() ne lit que 32K d'entrées de répertoire à la fois, donc sur les disques lents, il faudra beaucoup de lectures pour lister un répertoire. Il y a une solution à ce problème de vitesse. Je a écrit un article assez détaillé à ce sujet à: http://www.olark.com/spw/2011/08/you-can-list-a-directory-with-8-million-files-but-not-with-ls /

la clé à emporter est: utiliser getdents() directement -- http://www.kernel.org/doc/man-pages/online/pages/man2/getdents.2.html plutôt que tout ce qui est basé sur libc readdir() de sorte que vous pouvez spécifier la taille du tampon lors de la lecture des entrées de répertoire à partir du disque.

cela dépend un peu du système de fichiers utilisé sur le serveur Linux. De nos jours, la valeur par défaut est ext3 avec dir_index, ce qui rend la recherche de grands répertoires très rapide.

donc la vitesse ne devrait pas être un problème, autre que celui que vous avez déjà noté, qui est que les inscriptions prendront plus de temps.

il y a une limite au nombre total de fichiers dans un répertoire. J'ai l'impression de me souvenir que ça marchait vraiment jusqu'à 32000 fichiers.

j'ai un répertoire avec 88914 fichiers. Comme vous, il est utilisé pour stocker des vignettes et sur un serveur Linux.

fichiers listés via FTP ou une fonction php est lente Oui, mais il y a aussi un problème de performance lors de l'affichage du fichier. par exemple: www.website.com/thumbdir/gh3hg4h2b4h234b3h2.jpg a un temps d'attente de 200-400 ms. Comme une comparaison sur un autre site que j'ai avec une centaine de fichiers dans un répertoire l'image est affichée après seulement ~40ms d'attente.

j'ai donné cette réponse car la plupart des gens viennent d'écrire comment les fonctions de recherche dans les répertoires fonctionneront, ce que vous n'utiliserez pas sur un dossier de pouce - juste l'affichage statique de fichiers, mais sera intéressé par la performance de la façon dont les fichiers peuvent réellement être utilisés.

gardez à l'esprit que sur Linux si vous avez un répertoire avec trop de fichiers, l'interpréteur de commandes peut ne pas être capable d'étendre les caractères génériques. J'ai ce problème avec un album photo hébergé sur Linux. Il stocke toutes les images redimensionnées dans un seul répertoire. Alors que le système de fichiers peut gérer de nombreux fichiers, l'interpréteur de commandes ne le peut pas. Exemple:

-shell-3.00$ ls A*
-shell: /bin/ls: Argument list too long

ou

-shell-3.00$ chmod 644 *jpg
-shell: /bin/chmod: Argument list too long

je travaille sur un problème similaire en ce moment. Nous avons une structure de répertoire hiérarchique et utilisons des ID d'image comme noms de fichiers. Par exemple, une image avec id=1234567 est placée dans

..../45/67/1234567_<...>.jpg

en utilisant les 4 derniers chiffres pour déterminer où va le fichier.

Avec quelques milliers d'images, vous pouvez utiliser une hiérarchie à un niveau. Notre sysadmin a suggéré pas plus de deux mille fichiers dans un répertoire donné (ext3) pour l'efficacité / la sauvegarde / quelles que soient les raisons qu'il avait en tête.

pour ce que ça vaut, je viens de créer un répertoire sur un système de fichiers ext4 avec 1 000 000 de fichiers dedans, puis j'ai accédé au hasard à ces fichiers via un serveur web. Je n'ai pas remarqué de prime sur l'accès à ceux (disons) ayant seulement 10 fichiers là-bas.

C'est radicalement différent de mon expérience de faire cela sur ntfs il y a quelques années.

le plus gros problème que j'ai rencontré est un système 32 bits. Une fois que vous avez passé un certain nombre, les outils comme " ls " arrêtent de fonctionner.

essayer de faire quoi que ce soit avec ce répertoire une fois que vous passez cette barrière devient un énorme problème.

cela dépend vraiment du système de fichiers utilisé, et aussi de quelques options.

par exemple, ext3 peut avoir plusieurs milliers de fichiers; mais après quelques milliers, il était très lent. Surtout lorsque le listage d'un répertoire, mais aussi lors de l'ouverture d'un fichier unique. Il y a quelques années, il a gagné l'option "htree", qui a considérablement raccourci le temps nécessaire pour obtenir un inode donné un nom de fichier.

Personnellement, j'utilise des sous-répertoires gardez la plupart des niveaux sous un millier d'articles ou plus. Dans votre cas, je créerais 256 répertoires, avec les deux derniers chiffres hexadécimaux de L'ID. Utilisez les derniers et non les premiers chiffres, de sorte que vous obtenez la charge équilibrée.

cela dépend absolument du système de fichiers. Beaucoup de systèmes de fichiers modernes utilisent des structures de données décentes pour stocker le contenu des répertoires, mais les systèmes de fichiers plus anciens ont souvent simplement ajouté les entrées à une liste, donc extraire un fichier était une opération O(n).

même si le système de fichiers le fait correctement, il est tout de même absolument possible pour les programmes qui listent le contenu d'un répertoire de faire un tri O (N^2), donc pour être sûr, je limiterais toujours le nombre de fichiers par répertoire de pas plus de 500.

La question se résume à ce que vous allez faire avec les fichiers.

sous Windows, Tout répertoire avec plus de fichiers 2k a tendance à s'ouvrir lentement pour moi dans Explorer. Si ce sont tous des fichiers image, plus de 1k ont tendance à s'ouvrir très lentement en vue miniature.

à une époque, la limite imposée par le système était de 32 767. C'est plus élevé maintenant, mais même ça c'est beaucoup trop de dossiers à gérer en même temps dans la plupart des circonstances.

si le temps nécessaire à la mise en œuvre d'un schéma de partitionnement de répertoire est minime, je suis pour. La première fois que vous devez déboguer un problème qui implique la manipulation d'un répertoire de 10000 fichiers via la console vous comprendrez.

à titre d'exemple, F-Spot stocke les fichiers photos sous la forme AAAA\MM\JJ\filename.ext, ce qui signifie le plus grand répertoire que j'ai eu à traiter tout en manipulant manuellement ma collection de ~20000 photos est d'environ 800 fichiers. Cela rend également le fichiers plus facilement consultable à partir d'une application tierce. Ne supposez jamais que votre logiciel est la seule chose qui va accéder aux fichiers de votre logiciel.

ext3 a en fait des limites de taille de répertoire, et elles dépendent de la taille du bloc du système de fichiers. Il n'y a pas de répertoire "nombre maximum de fichiers, mais un répertoire "nombre maximum de blocs utilisés pour stocker les entrées du fichier". Plus précisément, la taille du répertoire lui-même ne peut pas pousser au-delà d'un arbre b de hauteur 3, et le fanout de l'arbre dépend de la taille du bloc. Voir ce lien pour plus de détails.

https://www.mail-archive.com/cwelug@googlegroups.com/msg01944.html

j'ai été mordu par ceci récemment sur un système de fichiers formaté avec des blocs de 2K, qui recevait inexplicablement des messages répertoire-noyau warning: ext3_dx_add_entry: Directory index full! quand je copiais à partir d'un autre système de fichiers ext3. Dans mon cas, un répertoire contenant seulement 480.000 fichiers n'a pas pu être copié vers la destination.

je me souviens avoir exécuté un programme qui créait une énorme quantité de fichiers à la sortie. Les fichiers ont été triés à 30000 par répertoire. Je ne me souviens pas avoir eu des problèmes de lecture lorsque j'ai dû réutiliser la sortie produite. Il était sur un ordinateur portable Ubuntu Linux 32 bits, et même Nautilus affiché le contenu du répertoire, bien après quelques secondes.

ext3 système de fichiers: code similaire sur un système 64 bits bien traité avec 64000 fichiers par répertoire.

je respecte cela ne répond pas totalement à votre question quant à savoir combien est trop, mais une idée pour résoudre le problème à long terme est qu'en plus de stocker les métadonnées du fichier original, stocker également quel dossier sur le disque il est stocké - normaliser ce morceau de métadonnées. Une fois qu'un dossier dépasse une certaine limite, vous êtes à l'aise avec pour la performance, esthétique ou n'importe quelle raison, vous créez juste un deuxième dossier et commencez à déposer des fichiers là...

j'ai rencontré un problème similaire. J'essayais d'accéder à un répertoire contenant plus de 10 000 fichiers. Il prenait trop de temps pour construire la liste des fichiers et exécuter n'importe quel type de commandes sur les fichiers.

j'ai pensé à un petit script php pour faire cela pour moi et a essayé de trouver un moyen de l'empêcher de temps dans le navigateur.

voici le script php que j'ai écrit pour résoudre le problème.

Fichiers De Listage dans un répertoire avec trop de fichiers pour FTP

la Façon dont il aide quelqu'un

je préfère de la même façon que @armandino . Pour cela j'utilise cette petite fonction en PHP pour convertir les IDs en un chemin de fichier qui produit 1000 fichiers par répertoire:

function dynamic_path($int) {
    // 1000 = 1000 files per dir
    // 10000 = 10000 files per dir
    // 2 = 100 dirs per dir
    // 3 = 1000 dirs per dir
    return implode('/', str_split(intval($int / 1000), 2)) . '/';
}

ou vous pouvez utiliser la deuxième version, si vous voulez utiliser l'alpha-numérique:

function dynamic_path2($str) {
    // 26 alpha + 10 num + 3 special chars (._-) = 39 combinations
    // -1 = 39^2 = 1521 files per dir
    // -2 = 39^3 = 59319 files per dir (if every combination exists)
    $left = substr($str, 0, -1);
    return implode('/', str_split($left ? $left : $str[0], 2)) . '/';
}

résultats:

<?php
$files = explode(',', '1.jpg,12.jpg,123.jpg,999.jpg,1000.jpg,1234.jpg,1999.jpg,2000.jpg,12345.jpg,123456.jpg,1234567.jpg,12345678.jpg,123456789.jpg');
foreach ($files as $file) {
    echo dynamic_path(basename($file, '.jpg')) . $file . PHP_EOL;
}
?>

1/1.jpg
1/12.jpg
1/123.jpg
1/999.jpg
1/1000.jpg
2/1234.jpg
2/1999.jpg
2/2000.jpg
13/12345.jpg
12/4/123456.jpg
12/35/1234567.jpg
12/34/6/12345678.jpg
12/34/57/123456789.jpg

<?php
$files = array_merge($files, explode(',', 'a.jpg,b.jpg,ab.jpg,abc.jpg,ddd.jpg,af_ff.jpg,abcd.jpg,akkk.jpg,bf.ff.jpg,abc-de.jpg,abcdef.jpg,abcdefg.jpg,abcdefgh.jpg,abcdefghi.jpg'));
foreach ($files as $file) {
    echo dynamic_path2(basename($file, '.jpg')) . $file . PHP_EOL;
}
?>

1/1.jpg
1/12.jpg
12/123.jpg
99/999.jpg
10/0/1000.jpg
12/3/1234.jpg
19/9/1999.jpg
20/0/2000.jpg
12/34/12345.jpg
12/34/5/123456.jpg
12/34/56/1234567.jpg
12/34/56/7/12345678.jpg
12/34/56/78/123456789.jpg
a/a.jpg
b/b.jpg
a/ab.jpg
ab/abc.jpg
dd/ddd.jpg
af/_f/af_ff.jpg
ab/c/abcd.jpg
ak/k/akkk.jpg
bf/.f/bf.ff.jpg
ab/c-/d/abc-de.jpg
ab/cd/e/abcdef.jpg
ab/cd/ef/abcdefg.jpg
ab/cd/ef/g/abcdefgh.jpg
ab/cd/ef/gh/abcdefghi.jpg

Comme vous pouvez le voir pour le $int -version chaque dossier contient jusqu'à 1000 fichiers et jusqu'à 99 répertoires contenant 1000 fichiers et 99 répertoires ...

mais n'oubliez pas que de nombreux répertoires peuvent accélérer votre processus de sauvegarde. N'hésitez pas à tester 1000 à 10000 fichiers par répertoire, mais n'ajoutez pas beaucoup plus car vous aurez des temps d'accès très longs si vous aimez lire le fichier répertoire par fichier (clients ftp, fonctions de lecture de fichiers, etc.).

enfin, vous devriez réfléchir à la façon de réduire le nombre de fichiers au total. En fonction de votre cible vous pouvez utiliser des sprites CSS pour combiner plusieurs petites images comme des avatars, des icônes, des smilies, etc. ou si vous utilisez de nombreux petits fichiers non-média, envisagez de les combiner, par exemple au format JSON. Dans mon cas, j'avais des milliers de mini-caches et finalement j'ai décidé de les combiner en paquets de 10.

ce que la plupart des réponses ci-dessus ne montrent pas, c'est qu'il n'y a pas de réponse" Taille unique " à la question originale.

dans l'environnement d'aujourd'hui, nous avons un grand conglomérat de différents matériels et logiciels - certains est de 32 bits, certains est de 64 bits, certains est à la pointe et certains est essayé et vrai-fiable et ne changeant jamais. À cela s'ajoute une variété de matériels plus anciens et plus récents, des os plus anciens et plus récents, des fournisseurs différents (Windows, Unixes, Apple, etc.) et une myriade des utilitaires et des serveurs qui vont le long. À mesure que le matériel s'est amélioré et que le logiciel a été converti en une compatibilité 64 bits, il a fallu beaucoup de temps pour que toutes les pièces de ce monde très vaste et complexe se comportent bien avec le rythme rapide des changements.

IMHO il n'y a pas une seule façon de résoudre un problème. La solution est de rechercher les possibilités et ensuite par tâtonnements trouver ce qui fonctionne le mieux pour vos besoins particuliers. Chaque utilisateur doit déterminer fonctionne pour leur système plutôt que d'utiliser une approche à l'emporte-pièce.

j'ai par exemple un serveur multimédia avec quelques très gros fichiers. Le résultat est seulement environ 400 dossiers remplissant un lecteur de 3 TB. Seulement 1% des inodes sont utilisés, mais 95% de l'espace total est utilisé. Quelqu'un d'autre, avec beaucoup de petits fichiers peut manquer d'inodes avant de s'approcher de remplir l'espace. (Sur les systèmes de fichiers ext4 en règle générale, 1 inode est utilisé pour chaque fichier/répertoire.) Alors que, théoriquement, le nombre total de fichiers qui peuvent être contenus dans un répertoire est presque infini, la praticité détermine que l'utilisation globale détermine des unités réalistes, pas seulement des capacités du système de fichiers.

j'espère que toutes les réponses ci-dessus ont favorisé la réflexion et la résolution de problèmes plutôt que de présenter un obstacle insurmontable au progrès.

ce n'est pas une réponse, mais juste quelques suggestions.

sélectionnez un système de fichiers plus adapté. Puisque d'un point de vue historique, TOUS vos problèmes étaient assez sages, pour être une fois au centre de la FSs évoluant sur des décennies. Je veux dire, des services sociaux plus modernes qui supportent mieux vos problèmes. Tout d'abord faire une table de décision de comparaison basée sur votre but ultime de liste de FS .

je pense qu'il est temps de changer votre paradigmes. Je suggère donc personnellement utilisation d'un système distribué conscient FS , ce qui signifie aucune limite en ce qui concerne la taille, le nombre de fichiers et etc Sinon, vous serez tôt ou tard confrontés à de nouveaux problèmes imprévus.

Je ne suis pas sûr de travailler, mais si vous ne mentionnez pas quelques expériences, donnez AUFS sur votre système de fichiers actuel un essai. Je suppose qu'il a des équipements pour imiter plusieurs dossiers comme un seul dossier virtuel.

pour surmonter les limites matérielles que vous pouvez Utilisez RAID-0.

Il n'y a pas une seule figure qui est "trop", tant qu'il ne dépasse pas les limites de l'OS. Cependant, plus il y a de fichiers dans un répertoire, quel que soit le système D'exploitation, plus il faut de temps pour accéder à un fichier individuel, et sur la plupart des systèmes d'exploitation, la performance est non linéaire, donc trouver un fichier sur 10 000 prend plus de 10 fois plus de temps que trouver un fichier sur 1 000.

problèmes secondaires associés à avoir beaucoup de fichiers dans un répertoire incluent l'extension wild card échec. Pour réduire les risques, vous pourriez envisager de commander vos répertoires en fonction de la date de téléchargement ou d'autres éléments de métadonnées utiles.