Partager via

Comprendre les tailles de répertoire dans Azure NetApp Files

  • Article

Lorsqu’un fichier est créé dans un répertoire, une entrée est ajoutée à un fichier d’index masqué dans le volume Azure NetApp Files. Ce fichier d’index permet de suivre les inodes existantes dans un répertoire et d’accélérer les demandes de recherche pour les répertoires avec un grand nombre de fichiers. À mesure que les entrées sont ajoutées à ce fichier, la taille du fichier augmente (mais ne diminue jamais) à un taux d’environ 512 octets par entrée en fonction de la longueur du nom de fichier. Les noms de fichiers plus longs ajoutent plus de taille au fichier. Les liens symboliques ajoutent également des entrées à ce fichier. Ce concept est appelé taille de répertoire, qui est un élément commun dans tous les systèmes de fichiers Linux. La taille du répertoire n’est pas le nombre maximal de fichiers dans un seul volume Azure NetApp Files. Cela est déterminé par la valeur maxfiles.

Par défaut, lorsqu’un répertoire est créé, il consomme 4 Kio (4 096 octets) ou huit blocs de 512 octets. Vous pouvez afficher la taille d’un répertoire nouvellement créé à partir d’un client Linux à l’aide de la commande stat.

# mkdir dirsize 
# stat dirsize 
File: ‘dirsize’ 
Size: 4096            Blocks: 8          IO Block: 32768  directory

Les tailles de répertoire sont spécifiques à un seul répertoire et ne sont pas combinées en tailles. Par exemple, s’il existe 10 répertoires dans un volume, chacun peut approcher la limite de taille de répertoire de 320 Mio dans un seul volume.

Déterminer si un répertoire approche de la taille limite

Pour un annuaire de 320 Mio, les blocs sont au nombre de 655360, d’une taille 512 octets chacun (autrement dit, 320x1024x1024/512.) Ce nombre se traduit par environ 4-5 millions de fichiers au maximum pour un annuaire de 320 Mo. Toutefois, le nombre réel de fichiers maximum peut être inférieur, en fonction de facteurs comme le nombre de fichiers avec des caractères non-ASCII dans l’annuaire.

Vous pouvez utiliser la commande stat à partir d’un client pour voir si la taille d’un annuaire approche de la limite maximale pour des métadonnées d’annuaire (320 Mo). Si vous atteignez la limite de taille maximale d’un répertoire unique pour Azure NetApp Files, l’erreur No space left on device se produit.

Pour un annuaire de 320 Mo, les blocs sont au nombre de 655 360, chaque taille de bloc étant de 512 octets. (soit, 320 x 1 024 x 1 024/512). Ce nombre se traduit par environ 4 millions de fichiers au maximum pour un annuaire de 320 Mo. Toutefois, le nombre réel de fichiers maximum peut être inférieur, en fonction de facteurs comme le nombre de fichiers avec des caractères non-ASCII dans l’annuaire. Pour plus d’informations sur la surveillance du maxdirsize, consultez Surveillance maxdirsize.

Considérations relatives à la taille du répertoire

Lorsque vous traitez d’un environnement de nombre élevé de fichiers, tenez compte des recommandations suivantes :

  • Les volumes Azure NetApp Files prennent en charge jusqu’à 320 Mio pour les tailles de répertoire. Cette valeur ne peut pas être augmentée.
  • Une fois la taille du répertoire d’un volume dépassée, les clients affichent une erreur hors espace, même s’il existe un espace libre disponible dans le volume.
  • Pour les volumes réguliers, une taille de répertoire de 320 Mio équivaut à environ 4 à 5 millions de fichiers dans un seul répertoire. Cette valeur dépend des longueurs de nom de fichier.
  • Les volumes volumineux ont une architecture différente de celle des volumes réguliers.
  • Un nombre élevé de fichiers dans un seul répertoire peut présenter des problèmes de performances lors de la recherche. Dans la mesure du possible, limitez la taille totale d’un répertoire unique à 2 Mio (environ 27 000 fichiers) lorsque des recherches fréquentes sont nécessaires.
    • Si d’autres fichiers sont nécessaires dans un répertoire unique, ajustez les attentes en matière de performances de recherche en conséquence. Bien qu’Azure NetApp Files indexe les listes de fichiers de répertoires pour les performances, les recherches peuvent prendre un certain temps avec un nombre élevé de fichiers.
  • Lors de la conception de votre système de fichiers, évitez les dispositions de répertoire plat. Pour plus d’informations sur différentes approches des dispositions d’annuaire, consultez À propos des dispositions d’annuaire.
  • Pour résoudre les problèmes où la taille du répertoire a été dépassée et que de nouveaux fichiers ne peuvent pas être créés, supprimez ou déplacez des fichiers hors du répertoire approprié.

À propos des dispositions d’annuaire

La valeur maxdirsize peut créer des problèmes lorsque vous utilisez des structures de répertoires plats, où un dossier unique contient des millions de fichiers à un seul niveau. Les structures de dossiers où les fichiers, les dossiers et les sous-dossiers sont intercalés ont un faible impact sur maxdirsize. Il existe plusieurs méthodologies de structure d’annuaire.

Une structure de répertoires plats est un répertoire unique avec de nombreux fichiers sous le même répertoire.

Diagramme d’une structure de répertoire plat.

Une structure de répertoires large contient de nombreux répertoires de niveau supérieur avec des fichiers répartis dans tous les répertoires.

Diagramme d’une structure de répertoire large.

Une structure de répertoires profonds contient moins de répertoires de niveau supérieur avec de nombreux sous-répertoires. Bien que cette structure fournit moins de fichiers par dossier, les longueurs de chemin d’accès de fichier peuvent devenir un problème si les dispositions de répertoires sont trop profondes et que les chemins d’accès aux fichiers deviennent trop longs. Pour plus d’informations sur les longueurs de chemin d’accès de fichier, consultez Comprendre les longueurs de chemin d’accès de fichier dans Azure NetApp Files.

Diagramme d’une structure de répertoire profond.

Impact des structures de répertoires plats dans Azure NetApp Files

Les structures de répertoires plats (de nombreux fichiers dans un ou plusieurs répertoires) ont un effet négatif sur un large éventail de systèmes de fichiers, de volumes Azure NetApp File ou d’autres. Les problèmes potentiels sont les suivants :

  • Sollicitation de la mémoire
  • Utilisation du processeur
  • Performances/latence réseau (en particulier pendant les requêtes en masse de fichiers, d’opérations GETATTR et d’opérations READDIR)

En raison de la conception de grands volumes Azure NetApp Files, l’impact de maxdirsize est unique. Le grand volume d’Azure NetApp Files maxdirsize est affecté de manière unique en raison de sa conception. Contrairement à un volume normal, un grand volume utilise des liens durs distants à l’intérieur d’Azure NetApp Files pour vous aider à rediriger le trafic sur différents appareils de stockage afin de fournir plus d’échelle et de performances. Lorsque vous utilisez des répertoires plats, il existe un ratio plus élevé de liens durs distants internes vers des fichiers locaux. Ces liens durs distants comptent sur la valeur maxdirsize totale, de sorte qu’un grand volume peut approcher sa limite maxdirsize plus rapidement qu’un volume normal.

Par exemple, si un répertoire unique contient des millions de fichiers et génère environ 85 % de liens durs distants pour le système de fichiers, vous pouvez vous attendre maxdirsize à être épuisé à près de deux fois la quantité qu’un volume normal ferait.

Pour obtenir des résultats optimaux avec des tailles de répertoire dans Azure NetApp Files :

  • Évitez les structures de répertoire plat dans Azure NetApp Files. Les structures de répertoires étendus ou profonds fonctionnent mieux, à condition que la longueur du chemin d’accès du fichier ou du dossier ne dépasse pas les normes de protocole NAS.
  • Si les structures de répertoire plat sont inévitables, surveillez maxdirsize pour les répertoires.

Surveiller maxdirsize

Pour un répertoire unique, utilisez la commande stat pour rechercher la taille du répertoire.

# stat /mnt/dir_11/c5

Bien que la commande stat puisse être utilisée pour vérifier la taille du répertoire d’un répertoire spécifique, il peut ne pas être aussi efficace de l’exécuter individuellement sur un seul répertoire. Pour afficher la liste des plus grandes tailles de répertoires triées de la plus grande au plus petite, la commande suivante fournit ce qui suit lors de l’omission des répertoires d’instantanés de la requête.

# find /mnt -name .snapshot -prune -o -type d -ls -links 2 -prune | sort -rn -k 7 | head | awk '{print $2 " " $11}' | sort -rn

Remarque

La taille du répertoire signalée par la commande stat est en octets. La taille signalée dans la commande find est en Kio.

Exemple

# stat /mnt/dir_11/c5 

  File: ‘/mnt/dir_11/c5’ 

  Size: 322396160       Blocks: 632168     IO Block: 32768  directory 
 
# find /mnt -name .snapshot -prune -o -type d -ls -links 2 -prune | sort -rn -k 7 | head | awk '{print $2 " " $11}' | sort -rn 
316084 /mnt/dir_11/c5 

3792 /mnt/dir_19 

3792 /mnt/dir_16

Dans le précédent, la taille du répertoire de /mnt/dir_11/c5 est de 316 084 Kio (308,6 Mio), qui approche de la limite de 320 Mio. Cela équivaut à environ 4,1 millions de fichiers.

# ls /mnt/dir_11/c5 | wc -l
4171624

Dans ce cas, envisagez des actions correctives telles que le déplacement ou la suppression de fichiers.

Plus d’informations