Nombre maximum de fichiers / répertoires sous Linux?
Je développe une boutique en ligne LAMP, qui permettra aux administrateurs de télécharger plusieurs images pour chaque article.
Ma préoccupation est - dès le départ, il y aura 20000 éléments, ce qui signifie environ 60000 images.
Des questions:
Quel est le nombre maximum de fichiers et/ou répertoires sous Linux?
Quelle est la manière habituelle de gérer cette situation (meilleure pratique)?
Mon idée était de créer un répertoire pour chaque élément, sur la base de son ID unique, mais alors j'aurais toujours 20000 répertoires dans un répertoire principal ploads, et il augmentera indéfiniment comme les anciens éléments ne le feront pas. être retiré.
Merci pour toute aide.
les systèmes de fichiers ext [234] ont un nombre maximum fixe d'inodes; chaque fichier ou répertoire nécessite un inode. Vous pouvez voir le nombre actuel et les limites avec df -i. Par exemple, sur un système de fichiers ext3 de 15 Go, créé avec les paramètres par défaut:
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/xvda 1933312 134815 1798497 7% /
Il n'y a aucune limite sur les répertoires en particulier au-delà de cela; Gardez à l'esprit que chaque fichier ou répertoire nécessite au moins un bloc de système de fichiers (généralement 4 Ko), même s'il s'agit d'un répertoire contenant un seul élément.
Comme vous pouvez le voir, 80 000 inodes ne poseront probablement pas de problème. Et avec le dir_index option (activable avec tune2fs), les recherches dans les grands répertoires ne sont pas un gros problème. Cependant, notez que de nombreux outils d'administration (tels que ls ou rm) peuvent avoir du mal à gérer les répertoires contenant trop de fichiers. En tant que tel, il est recommandé de diviser vos fichiers afin de ne pas avoir plus de quelques centaines à mille éléments dans un répertoire donné. Un moyen simple de le faire est de hacher l'ID que vous utilisez et d'utiliser les premiers chiffres hexadécimaux comme répertoires intermédiaires.
Par exemple, supposons que vous disposez de l'ID d'article 12345 et qu'il se transforme en 'DEADBEEF02842.......'. Vous pouvez stocker vos fichiers sous /storage/root/d/e/12345. Vous avez maintenant réduit le nombre de fichiers dans chaque répertoire de 1/256e.
Si le système de fichiers de votre serveur a la fonctionnalité dir_index Activée (voir tune2fs(8) pour plus de détails sur la vérification et l'activation de la fonctionnalité), vous pouvez raisonnablement stocker plus de 100 000 fichiers dans un répertoire avant que les performances ne se dégradent . (dir_index A été la valeur par défaut pour les nouveaux systèmes de fichiers pour la plupart des distributions depuis plusieurs années maintenant, donc ce ne serait qu'un ancien système de fichiers qui n'a pas la fonctionnalité par défaut. )
Cela dit, l'ajout d'un autre niveau de répertoire pour réduire le nombre de fichiers dans un répertoire d'un facteur 16 ou 256 améliorerait considérablement les chances que des choses comme ls * Fonctionnent sans surcharger le maximum du noyau argv Taille.
En règle générale, cela se fait par quelque chose comme:
/a/a1111
/a/a1112
...
/b/b1111
...
/c/c6565
...
c'est-à-dire, en ajoutant une lettre ou un chiffre au chemin, en fonction d'une fonctionnalité que vous pouvez calculer à partir du nom. (Les deux premiers caractères de md5sum Ou sha1sum Du nom de fichier sont une approche courante, mais si vous avez des ID d'objet uniques, alors 'a'+ id % 16 Est un mécanisme assez simple pour déterminer lequel répertoire à utiliser.)
60000 n'est rien, 20000 aussi. Mais vous devez regrouper ces 20000 par tous les moyens afin d'accélérer leur accès. Peut-être en groupes de 100 ou 1000, en prenant le numéro du répertoire et en le divisant par 100, 500, 1000, peu importe.
Par exemple, j'ai un projet où les fichiers ont des numéros. Je les regroupe en milliers, donc j'ai
id/1/1332
id/3/3256
id/12/12334
id/350/350934
Vous pouvez en fait avoir une limite stricte - certains systèmes ont des inodes 32 bits, vous êtes donc limité à un nombre de 2 ^ 32 par système de fichiers.
En plus des réponses générales (essentiellement "ne vous embêtez pas autant", "ajustez votre système de fichiers", et "organisez votre répertoire avec des sous-répertoires contenant chacun quelques milliers de fichiers"):
Si les images individuelles sont petites (par exemple moins de quelques kilo-octets), au lieu de les mettre dans un dossier, vous pouvez également les mettre dans une base de données (par exemple avec MySQL comme BLOB ) ou peut-être à l'intérieur d'un fichier indexé GDBM . Ensuite, chaque petit élément ne consommera pas d'inode (sur de nombreux systèmes de fichiers, chaque inode veut au moins quelques kilo-octets). Vous pouvez également le faire pour un certain seuil (par exemple, placer des images de plus de 4 Ko dans des fichiers individuels et de plus petites dans une base de données ou un fichier GDBM). Bien sûr, n'oubliez pas de sauvegarder vos données (et de définir une stratégie de sauvegarde).
L'année est 2014. Je reviens dans le temps pour ajouter cette réponse. Beaucoup de gros/petits fichiers? Vous pouvez utiliser Amazon S3 et d'autres alternatives basées sur Ceph comme DreamObjects, où il n'y a aucune limite de répertoire à craindre.
J'espère que cela aide quelqu'un à choisir parmi toutes les alternatives.