Est-il important de savoir combien de fichiers je conserve dans un seul répertoire? Si c'est le cas, combien de fichiers dans un répertoire sont trop nombreux et quels sont les impacts d'avoir trop de fichiers? (Ceci est sur un serveur Linux.)

Contexte: J'ai un site d'album photo et chaque image téléchargée est renommée en un identifiant à 8 chiffres hexadécimaux (par exemple, a58f375c.jpg). Cela permet d'éviter les conflits de nom de fichier (si de nombreux fichiers "IMG0001.JPG" sont téléchargés, par exemple). Le nom de fichier d'origine et toutes les métadonnées utiles sont stockés dans une base de données. En ce moment, j'ai quelque part environ 1500 fichiers dans le répertoire images. Cela permet de répertorier les fichiers dans le répertoire (via le client FTP ou SSH) en quelques secondes. Mais je ne vois pas que cela ait un effet autre que celui-là. En particulier, il ne semble pas y avoir d'impact sur la rapidité avec laquelle un fichier image est servi à l'utilisateur.

J'ai pensé à réduire le nombre d'images en créant 16 sous-répertoires: 0-9 et af. Ensuite, je déplacerais les images dans les sous-répertoires en fonction de ce qu'était le premier chiffre hexadécimal du nom de fichier. Mais je ne suis pas sûr qu'il y ait une raison de le faire, sauf pour la liste occasionnelle du répertoire via FTP / SSH.

FAT32 :

• Nombre maximum de fichiers: 268 173 300
• Nombre maximum de fichiers par répertoire: 2 ¹⁶  - 1 (65 535)
• Taille maximale du fichier: 2 Gio - 1 sans LFS , 4 Gio - 1 avec

NTFS :

• Nombre maximum de fichiers: 2 ³²  - 1 (4 294 967 295)
• Taille maximale du fichier
  • Implémentation: 2 ⁴⁴  - 2 ⁶ octets (16 TiB - 64 KiB)
  • Théorique: 2 ⁶⁴  - 2 ⁶ octets (16 EiB - 64 KiB)
• Taille maximale du volume
  • Mise en oeuvre: 2 ³²  - 1 256 clusters (TiB - 64 KiB)
  • Théoriques: 2 ⁶⁴  - 1 groupes (1 YiB - 64 KiB)

ext2 :

• Nombre maximum de fichiers: 10 ¹⁸
• Nombre maximal de fichiers par répertoire: ~ 1,3 × 10 ²⁰ (problèmes de performances au-delà de 10 000)
• Taille maximale du fichier
  • 16 Gio (taille de bloc de 1 Kio)
  • 256 Gio (taille de bloc de 2 Kio)
  • 2 TiB (taille de bloc de 4 KiB)
  • 2 TiB (taille de bloc de 8 KiB)
• Taille maximale du volume
  • 4 TiB (taille de bloc de 1 KiB)
  • 8 TiB (taille de bloc de 2 KiB)
  • 16 TiB (taille de bloc de 4 KiB)
  • 32 TiB (taille de bloc de 8 KiB)

ext3 :

• Nombre maximum de fichiers: min (volumeSize / 2 ¹³ , numberOfBlocks)
• Taille maximale du fichier: identique à ext2
• Taille maximale du volume: identique à ext2

ext4 :

• Nombre maximum de fichiers: 2 ³²  - 1 (4 294 967 295)
• Nombre maximum de fichiers par répertoire: illimité
• Taille maximale du fichier: 2 ⁴⁴  - 1 octets (16 TiB - 1)
• Taille maximale du volume: 2 ⁴⁸  - 1 octets (256 TiB - 1)

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

La raison lsetfind lenteur dans ce cas est que readdir()ne lit que 32 Ko d'entrées de répertoire à la fois, donc sur des disques lents, il faudra de nombreuses lectures pour répertorier un répertoire. Il existe une solution à ce problème de vitesse. J'ai écrit un article assez détaillé à ce sujet sur: http://www.olark.com/spw/2011/08/you-can-list-a-directory-with-8-million-files-but-not-with- ls /

La clé à retenir 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()afin que vous puissiez spécifier le tampon taille lors de la lecture des entrées du répertoire à partir du disque.

J'ai un répertoire contenant 88 914 fichiers. Comme vous, ceci est utilisé pour stocker des miniatures et sur un serveur Linux.

Les fichiers répertoriés via FTP ou une fonction php sont lents oui, mais il y a également un impact sur les performances lors de l'affichage du fichier. Par exemple, www.website.com/thumbdir/gh3hg4h2b4h234b3h2.jpg a un temps d'attente de 200 à 400 ms. À titre de comparaison sur un autre site que j'ai avec environ 100 fichiers dans un répertoire, l'image s'affiche après seulement ~ 40 ms d'attente.

J'ai donné cette réponse car la plupart des gens viennent d'écrire comment les fonctions de recherche de répertoire fonctionneront, que vous n'utiliserez pas sur un dossier miniature - affichant simplement des fichiers statiquement, mais seront intéressés par les performances de la façon dont les fichiers peuvent être réellement utilisés .

Cela dépend un peu du système de fichiers spécifique 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.

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

Il y a une limite au nombre total de fichiers dans un répertoire. Il me semble que cela fonctionne sans aucun doute jusqu'à 32 000 fichiers.

Gardez à l'esprit que sous Linux, si vous avez un répertoire avec trop de fichiers, le shell peut ne pas être en mesure de développer des 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, le shell 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épertoires hiérarchique et utilisons des identifiants d'image comme noms de fichiers. Par exemple, une image avec id=1234567est 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 administrateur système n'a suggéré que quelques milliers de fichiers dans un répertoire donné (ext3) pour des raisons d'efficacité / de sauvegarde / quelles que soient les autres raisons qu'il avait en tête.

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

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

Le plus gros problème que j'ai rencontré concerne un système 32 bits. Une fois que vous avez dépassé un certain nombre, des outils comme «ls» cessent de fonctionner.

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

J'ai eu le même problème. Essayer de stocker des millions de fichiers sur un serveur Ubuntu en ext4. Fin de l'exécution de mes propres repères. J'ai découvert que le répertoire plat fonctionne bien mieux tout en étant plus simple à utiliser:

A écrit un article .

Si le temps nécessaire à l'implémentation d'un schéma de partitionnement d'annuaire est minime, je suis en faveur de celui-ci. La première fois que vous devrez déboguer un problème impliquant la manipulation d'un répertoire de 10000 fichiers via la console, vous comprendrez.

Par exemple, F-Spot stocke les fichiers photo sous la forme AAAA \ MM \ JJ \ nom_fichier.ext, ce qui signifie que le plus grand répertoire auquel j'ai dû faire face lors de la manipulation manuelle de ma collection de ~ 20000 photos est d'environ 800 fichiers. Cela rend également les fichiers plus faciles à parcourir à partir d'une application tierce. Ne présumez jamais que votre logiciel est la seule chose qui accède aux fichiers de votre logiciel.

Cela dépend absolument du système de fichiers. De nombreux 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 venaient souvent d'ajouter les entrées à une liste, donc la récupération d'un fichier était une opération O (n).

Même si le système de fichiers le fait correctement, il est toujours possible pour les programmes qui répertorient le contenu des répertoires de se tromper et de faire un tri O (n ^ 2), donc pour être sûr, je limiterais toujours le nombre de fichiers par répertoire à pas plus de 500.

Cela dépend vraiment du système de fichiers utilisé, ainsi que de certains indicateurs.

Par exemple, ext3 peut contenir plusieurs milliers de fichiers; mais après quelques milliers, c'était très lent. Surtout lors de la liste d'un répertoire, mais aussi lors de l'ouverture d'un seul fichier. 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 pour garder la plupart des niveaux sous un millier d'articles. Dans votre cas, je créerais 256 répertoires, avec les deux derniers chiffres hexadécimaux de l'ID. Utilisez les derniers chiffres et non les premiers, pour équilibrer la charge.

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

https://www.mail-archive.com/[email protected]/msg01944.html

J'ai récemment été mordu par cela sur un système de fichiers formaté avec des blocs 2K, qui recevait inexplicablement les messages du noyau plein de répertoires warning: ext3_dx_add_entry: Directory index full!lorsque je copiais à partir d'un autre système de fichiers ext3. Dans mon cas, un répertoire contenant à peine 480 000 fichiers n'a pas pu être copié vers la destination.

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

Sous Windows, tout répertoire contenant plus de 2 000 fichiers a tendance à s'ouvrir lentement pour moi dans l'Explorateur. S'ils sont tous des fichiers image, plus de 1 Ko ont tendance à s'ouvrir très lentement en vue miniature.

À un moment donné, la limite imposée par le système était de 32 767. Il est plus élevé maintenant, mais même cela représente beaucoup trop de fichiers à gérer à la fois dans la plupart des circonstances.

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 d'origine.

Dans l'environnement actuel, nous avons un grand conglomérat de différents matériels et logiciels - certains 32 bits, certains 64 bits, certains de pointe et certains éprouvés - fiables et sans changement. À cela s'ajoutent une variété de matériel ancien et plus récent, des systèmes d'exploitation plus anciens et plus récents, différents fournisseurs (Windows, Unixes, Apple, etc.) et une myriade d'utilitaires et de serveurs qui vont avec. Au fur et à mesure que le matériel s'est amélioré et que le logiciel est converti en compatibilité 64 bits, il y a forcément eu un retard considérable pour que toutes les pièces de ce monde très vaste et complexe jouent bien avec le rythme rapide des changements.

À mon humble avis, il n'y a pas une seule façon de résoudre un problème. La solution consiste à rechercher les possibilités, puis par essais et erreurs à trouver ce qui convient le mieux à vos besoins particuliers. Chaque utilisateur doit déterminer ce qui fonctionne pour son système plutôt que d'utiliser une approche de cookie cutter.

J'ai par exemple un serveur multimédia avec quelques très gros fichiers. Le résultat est seulement environ 400 fichiers remplissant un lecteur de 3 To. Seulement 1% des inodes sont utilisés mais 95% de l'espace total est utilisé. Quelqu'un d'autre, avec beaucoup de fichiers plus petits, peut manquer d'inodes avant de se rapprocher de 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 pouvant être contenus dans un répertoire est presque infini, l'aspect pratique détermine que l'utilisation globale détermine des unités réalistes, pas juste des capacités de système de fichiers.

J'espère que toutes les différentes 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.

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 de problèmes de lecture lorsque j'ai dû réutiliser la sortie produite. C'était sur un ordinateur portable Ubuntu Linux 32 bits, et même Nautilus affichait le contenu du répertoire, quoique après quelques secondes.

Système de fichiers ext3: un code similaire sur un système 64 bits traitait bien 64 000 fichiers par répertoire.

"Dépend du système de fichiers"
Certains utilisateurs ont mentionné que l'impact sur les performances dépend du système de fichiers utilisé. Bien sûr. Les systèmes de fichiers comme EXT3 peuvent être très lents. Mais même si vous utilisez EXT4 ou XFS, vous ne pouvez pas empêcher que la liste d'un dossier via lsou findou via une connexion externe comme FTP devienne plus lente et plus lente.

Solution
Je préfère la même manière que @armandino . Pour cela, j'utilise cette petite fonction en PHP pour convertir les identifiants en un chemin de fichier qui génère 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 souhaitez utiliser des caractères alphanumériques:

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 la $intversion-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 provoquent les mêmes problèmes de performances!

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

Je respecte cela ne répond pas totalement à votre question sur le nombre, mais une idée pour résoudre le problème à long terme est qu'en plus de stocker les métadonnées du fichier d'origine, stockez également le dossier sur le disque dans lequel il est stocké - normaliser sur ce morceau de métadonnées. Une fois qu'un dossier se développe au-delà d'une certaine limite avec laquelle vous êtes à l'aise pour les performances, l'esthétique ou autre, vous créez simplement un deuxième dossier et commencez à y déposer des fichiers ...

J'ai rencontré un problème similaire. J'essayais d'accéder à un répertoire contenant plus de 10 000 fichiers. La création de la liste de fichiers et l'exécution de tout type de commandes sur l'un des fichiers prenaient trop de temps.

J'ai imaginé un petit script php pour le faire moi-même et j'ai essayé de trouver un moyen de l'empêcher de s'arrêter dans le navigateur.

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

Liste des fichiers dans un répertoire contenant trop de fichiers pour FTP

Comment cela aide quelqu'un

Pas une réponse, mais juste quelques suggestions.

Sélectionnez un FS (système de fichiers) plus approprié. Étant donné que d'un point de vue historique, tous vos problèmes étaient suffisamment judicieux pour être jadis au cœur des SF évoluant au fil des décennies. Je veux dire que les FS plus modernes prennent mieux en charge vos problèmes. Faites d'abord un tableau de décision de comparaison basé sur votre objectif ultime à partir de la liste FS .

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

Je ne suis pas sûr de travailler, mais si vous ne mentionnez pas d'expérimentation, essayez AUFS sur votre système de fichiers actuel. Je suppose qu'il a des installations pour imiter plusieurs dossiers en un seul dossier virtuel.

Pour surmonter les limites matérielles, vous pouvez utiliser RAID-0.

Il n'y a pas un seul chiffre qui soit «trop», tant qu'il ne dépasse pas les limites du système d'exploitation. 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, les performances sont non linéaires, donc trouver un fichier sur 10 000 prend plus de 10 fois plus de temps puis pour trouver un fichier en 1000.

Les problèmes secondaires associés à la présence de nombreux fichiers dans un répertoire incluent les échecs d'extension des caractères génériques. Pour réduire les risques, vous pourriez envisager de commander vos répertoires par date de téléchargement, ou tout autre élément utile de métadonnées.