Combien de fichiers puis-je mettre dans un répertoire?

561

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.

Kip
la source

Réponses:

736

FAT32 :

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

NTFS :

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

ext2 :

  • Nombre maximum de fichiers: 10 18
  • Nombre maximal de fichiers par répertoire: ~ 1,3 × 10 20 (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 13 , numberOfBlocks)
  • Taille maximale du fichier: identique à ext2
  • Taille maximale du volume: identique à ext2

ext4 :

  • Nombre maximum de fichiers: 2 32  - 1 (4 294 967 295)
  • Nombre maximum de fichiers par répertoire: illimité
  • Taille maximale du fichier: 2 44  - 1 octets (16 TiB - 1)
  • Taille maximale du volume: 2 48  - 1 octets (256 TiB - 1)
ISW
la source
24
Je suppose que ce sont le nombre maximum de fichiers pour la partition entière, pas un répertoire. Ainsi, ces informations ne sont pas trop utiles concernant le problème, car il y aurait un nombre égal de fichiers quelle que soit la méthode (sauf si vous comptez les répertoires comme des fichiers).
strager
19
Puisque nous sommes en 2012 maintenant, je pense qu'il est temps de préciser que ext4 n'a pas de limite concernant le nombre de sous-répertoires. La taille maximale des fichiers est également passée à 16 To. De plus, la taille globale du système de fichiers peut aller jusqu'à 1 EB = 1 048 576 To.
devsnd
7
Apparemment, ext3 a également une limite de 60 000 fichiers (ou répertoires ou liens) par répertoire. J'ai découvert la voie difficile à ce sujet.
stackular
8
Ancienne réponse, je sais… mais quand tu écris EXT4 - Nombre maximum de fichiers: 2³² - 1 (4 294 967 295) et Nombre maximum de fichiers par répertoire: illimité tu m'as vraiment dérouté car 2³² - 1! = "Illimité". Je suppose que j'ai besoin d'un café maintenant. ;) Néanmoins +1
e-sushi
11
les limites strictes du système de fichiers ne répondent pas à la question " Le nombre de fichiers que je conserve dans un seul répertoire est-il important? "
Etki
191

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.

Ben
la source
6
Lecture intéressante! Puis-je demander dans quelle situation vous aviez 8 millions de fichiers dans un répertoire? haha
Aᴄʜᴇʀᴏɴғᴀɪʟ
J'avais la même chose. J'ai migré la colonne d'objets blob d'une table, chaque colonne d'objets blob que j'ai exportée en tant que fichier. C'est environ 8 millions de fichiers :)
Spike
65

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 .

S ..
la source
6
C'est la seule réponse utile. Nous avons fait des expériences similaires. Notre limite est de 1 000 fichiers pour réduire les problèmes de sauvegarde (trop de répertoires ralentissent aussi).
mgutt
1
Il peut également être utile de monter un disque avec noatime: howtoforge.com/… et de lire ceci également: serverfault.com/questions/354017/…
mgutt
2
Quel système de fichiers utilisez-vous là où il ralentit autant? XFS, par exemple, devrait être capable de gérer facilement 100 000 fichiers dans un répertoire sans aucun ralentissement notable.
Ethan
1
En contradiction avec l'opinion de la plupart des autres, je veux confirmer cette réponse. Nous avons des centaines de milliers d'images sur notre site Web de réseau social. Afin d'améliorer les performances, nous avons été obligés d'avoir 100 (ou 1000 pour certains fichiers) sous-répertoires et d'y distribuer les fichiers (ext3 sous linux + Apache pour nous).
wmac
57

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.

Bart Schuller
la source
4
Gnome et KDE chargent de gros répertoires à un rythme d'escargots, Windows mettra en cache le répertoire de manière raisonnable. J'adore Linux, mais kde et gnome sont mal écrits.
tour
1
Et ext4 semble avoir l'équivalent de dir_index sur par défaut.
contrat du professeur Falken a été rompu le
22
Il y a une limite d'environ 32K sous-répertoires dans un répertoire dans ext3, mais l'OP parle de fichiers image. Il n'y a pas de limite (pratique?) Sur les fichiers dans un système de fichiers ext3 avec Dir Index activé.
Peter N Lewis
1
Cette réponse est obsolète, de nos jours la valeur par défaut est ext4 .
Boris
1
"Il n'y a pas de limite (pratique?) Sur les fichiers dans un système de fichiers ext3 avec Dir Index activé" - Je viens de manquer d'espace fichier dans un répertoire sur un système de fichiers ext4 de 4 To, avec dir_indexactivé. J'avais environ 17 millions de fichiers dans le répertoire. La réponse a été d'activer large_diravec tune2fs.
lunixbochs
49

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
Steve Kuo
la source
33
@Steve, utilisez find (1) et / ou xargs (1) pour ces cas. Pour la même raison, c'est une bonne idée d'utiliser de tels outils dans des scripts au lieu de développer la ligne de commande.
Dave C
3
@Steve voyez-vous une baisse des performances lorsque le nombre de fichiers dans un dossier augmente? Ou n'y a-t-il pas de relation?
Pacerier
6
C'est un bon point, mais pour nitpick, la raison donnée est fausse. La liste d'arguments trop longue n'est pas une limitation du shell, mais de l' execimplémentation du système . Le shell peut généralement développer le caractère générique très bien - c'est l'appel à execautant d'arguments qui renvoie l'erreur.
jw013
J'ai eu la même erreur hier soir (Fedora 15) avec "rm" (certainsfichiers *) avec environ ~ 400 000 fichiers dans un répertoire. J'ai pu couper les anciens fichiers avec "find" au point où je pouvais "rm" avec un caractère générique.
PJ Brunet
10.000.000 de fichiers dans un répertoire sur etx4 fonctionnent bien. Pas beaucoup de performances lors de l'accès. Mais plutôt lent avec un caractère générique. Soyez prudent lorsque vous utilisez des programmes shell qui aiment trier les noms de fichiers! :)
Simon Rigét
25

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.

armandino
la source
1
C'est une assez bonne solution. Chaque niveau de votre répertoire jusqu'au fichier aurait au plus 100 entrées si vous respectez la ventilation à 2 chiffres, et le répertoire le plus bas n'aurait qu'un seul fichier.
RobKohr
Implémentation
21

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.

TJ Crowder
la source
quel genre de fichiers? texte ou images? je suis sur ext4 et je dois importer 80000 images dans un seul répertoire sous wordpress et je voudrais savoir si ça va aller
Yvon Huynh
1
@YvonHuynh: Le type de fichier est complètement hors de propos. Les frais généraux dans le répertoire de listage / suivi du fichier sont les mêmes.
TJ Crowder
14

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.

Mike Paterson
la source
9

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:

référence

A écrit un article .

Hartator
la source
Un lien vers une solution est le bienvenu, mais assurez-vous que votre réponse est utile sans elle: ajoutez du contexte autour du lien pour que vos collègues aient une idée de ce que c'est et pourquoi il est là, puis citez la partie la plus pertinente de la page que vous '' relier à au cas où la page cible n'est pas disponible. Les réponses qui ne sont guère plus qu'un lien peuvent être supprimées.
Samuel Liew
1
Intéressant. Nous avons constaté qu'après 10 000 fichiers, les performances se dégradaient très très rapidement au point d'être inutilisables. Nous avons décidé de diviser les fichiers en sous-répertoires d'environ 100 à chaque niveau pour obtenir des performances optimales. Je suppose que la morale de l'histoire est de toujours la comparer pour vous-même sur vos propres systèmes avec vos propres exigences.
Joshua Pinter
7

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.

Sparr
la source
6
Je déconseille le partitionnement par date car les importations en masse peuvent regrouper des fichiers à une certaine date.
max
Un bon point. Vous devez absolument considérer vos cas d'utilisation avant de choisir un schéma de partitionnement. Il m'arrive d'importer des photos sur plusieurs jours dans une distribution relativement large, ET quand je veux manipuler les photos en dehors de la date F-Spot est le moyen le plus simple de les trouver, c'est donc un double gain pour moi.
Sparr
7

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.

Michael Borgwardt
la source
7

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.

Javier
la source
6
Si les noms de fichiers étaient complètement aléatoires, peu importe les chiffres utilisés.
strager le
En effet, ces noms de fichiers sont générés de manière aléatoire.
Kip
2
Ou utilisez les N premiers octets du condensé SHA-1 du nom de fichier.
gawi
6

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.

sans données
la source
5

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.

Oui - ce Jake.
la source
5

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.

ordinateursavvy
la source
4

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.

user54579
la source
4

"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.

mgutt
la source
3

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 ...

Goyuix
la source
3

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

Swhistlesoft
la source
1

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.

shvahabi
la source
1

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.

Paul Smith
la source