60000 c'est rien, 20000 aussi. Mais vous devez regrouper ces 20000 par tous les moyens afin d'accélérer leur accès. Peut-être par 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 par milliers, j'ai donc
id/1/1332
id/3/3256
id/12/12334
id/350/350934
Vous pourriez 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.
Si le système de fichiers de votre serveur a le dir_index fonctionnalité activée (voir tune2fs(8) pour plus de détails sur la vérification et l'activation de la fonctionnalité), vous pouvez raisonnablement stocker jusqu'à 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é activée par défaut.)
Cela dit, ajouter un autre niveau de répertoire pour réduire le nombre de fichiers dans un répertoire par un facteur de 16 ou 256 améliorerait considérablement les chances de choses comme ls * travailler sans dépasser le maximum argv du noyau taille.
Généralement, 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 est une approche courante, mais si vous avez des identifiants d'objet uniques, alors 'a'+ id % 16 est un mécanisme assez simple pour déterminer quel répertoire utiliser.)
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 pas de 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, cependant, 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 trop importantes. Cependant, notez que de nombreux outils d'administration (tels que ls ou rm ) peut avoir du mal à gérer les répertoires contenant trop de fichiers. En tant que tel, il est recommandé de diviser vos fichiers afin que vous n'ayez pas plus de quelques centaines à un millier d'éléments dans un répertoire donné. Pour ce faire, un moyen simple consiste à hacher l'ID que vous utilisez et à utiliser les premiers chiffres hexadécimaux comme répertoires intermédiaires.
Par exemple, disons que vous avez l'ID d'article 12345 et qu'il est haché 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.