Conseils pour améliorer les performances des répertoires

du système de fichiers. Les conseils et astuces suivants constituent un bon point de départ pour doper les performances globales du système de fichiers.

1. Utiliser des répertoires *TYPE2
Les répertoires *TYPE2 résultent d’un remodelage interne de l’objet répertoire *TYPE1 dans les systèmes de fichiers racine, QOpenSys et définis par l’utilisateur. Le nouveau modèle de répertoire *TYPE2 est plus fiable et plus performant que son prédécesseur *TYPE1. Les répertoires *TYPE2 surclassent leurs homologues *TYPE1 dans presque tous les domaines. Voici la liste de quelques améliorations de performances des répertoires *TYPE2 par rapport à *TYPE1 :

• Créer un répertoire : jusqu’à 12-13 fois plus vite
• Supprimer un répertoire : jusqu’à 3-4 fois plus vite
• Lire un répertoire : jusqu’à 4 fois plus vite
• Ouvrir un répertoire : jusqu’à 2 fois plus vite
• Récupérer du stockage : jusqu’à 1,5-2 fois plus vite
• S/R : jusqu’à 2 fois plus vite
• Ouvrir un fichier : jusqu’à 1,5 fois plus vite

Si votre système n’utilise pas de répertoires *TYPE2, vous devriez envisager de convertir les systèmes de fichiers. Pour convertir en V5R1, utilisez d’abord l’API QP0FCVT2 (Convert Directory) pour déterminer si votre système utilise des répertoires *TYPE2. En V5R2 et V5R3, effectuez cette vérification à l’aide de la commande CVTDIR (Convert Directory). Exécutez la commande appropriée pour V5R2 et V5R3 :

CALL PGM(QP0FCVT2) PARM(*LIST)
CVTDIR OPTION(*CHECK)

La figure 3 montre la sortie produite par cette commande.
S’il s’avère qu’un ou plusieurs systèmes de fichiers n’utilisent pas de répertoire *TYPE2, la conversion semble judicieuse. En V5R1, vous effectuerez la conversion à l’aide de l’API QP0FCVT2. En V5R2, vous utiliserez pour cela la commande CVTDIR. Et, en V5R3, c’est le système d’exploitation qui se chargera de la conversion.

Pour plus d’informations sur les répertoires *TYPE2 et sur la conversion des répertoires, visitez l’iSeries Information Center (V5R3 : Files and file systems|Integrated file system| Convert directories from *TYPE1 to *TYPE2. V5R2 : Files and management|Integrated file system|Concepts| Directory|*TYPE2 directories. V5R1 : Database and file systems| File systems and management|Concepts|Integrated file system concepts|*TYPE2 directories).

2. Utiliser des noms de liens et des chemins courts
Les objets répertoire utilisent des liens pour faire tenir ensemble les éléments qui constituent le système de fichiers. Chaque lien reçoit un nom (un « nom de lien », parfois appelé nom de fichier) pour distinguer un lien d’un autre dans un même répertoire. Par conséquent, pour chaque objet du système de fichiers, il existe au moins un lien, et donc au moins un nom de lien.

Les noms de liens d’un système de fichiers sont très importants parce qu’on les combine pour construire des noms de chemins, et que ces derniers permettent d’identifier et de localiser des objets. Ainsi, si un fichier stream se trouve dans le répertoire /home/fred, il existe un lien allant du répertoire /home/fred au fichier stream. Supposons que le nom de ce lien soit foo. Pour accéder à ce fichier stream, il vous faudrait créer un nom de chemin y conduisant, tel que /home/fred/ foo. La figure 4 illustre cet exemple par un graphique.

A l’heure actuelle, un nom de lien est considéré court s’il ne dépasse pas 16 caractères et un nom de chemin est considéré court s’il ne dépasse pas 20 caractères. En utilisant des noms de liens et de chemins courts, vous pouvez bénéficier de certains mécanismes de cache du système de fichiers susceptibles d’améliorer la résolution des noms de chemins : jusqu’à 15 %. Si les noms de liens et de chemins sont plus longs, ils ne pourront pas bénéficier de ces caches. En outre, si les noms de liens dépassent 24 caractères, vos objets répertoire doivent aussi créer et gérer des pools de stockage supplémentaires. Bien entendu, cela augmente d’autant la quantité de stockage consommée par les objets répertoire. Sans parler des risques supplémentaires de défaut de page pendant la résolution du nom de chemin. Tout cela contribue à diminuer les performances du système de fichiers. En règle générale, il faut s’en tenir à des noms de liens et de chemins courts.

3. Utiliser un répertoire de travail courant et éviter des sous-arborescences profondes
Un répertoire de travail courant (CWD, current working directory) est un répertoire que le système d’exploitation met en cache. Par défaut, quand vous vous connectez au système, il utilise le répertoire home de votre profil utilisateur comme CWD. Chaque fois qu’un nom de chemin relatif (c’est-à-dire un nom de chemin non précédé d’une barre oblique (/) comme MyDir/MyFile) est utilisé, le CWD est le premier répertoire dans lequel le système d’exploitation commence la résolution du nom de chemin. On peut assimiler le concept CWD à une bibliothèque courante : on peut changer et afficher un CWD selon les besoins, comme on le ferait avec une bibliothèque courante. Pour changer et afficher votre CWD, utilisez les commandes CHGCURDIR (Change Current Directory) et DSPCURDIR (Display Current Directory), respectivement. Il existe deux API correspondantes – chdir() et getcwd() – que vous pouvez aussi utiliser.

Chaque job ou processus a un CWD qui, bien utilisé, peut accélérer la résolution des noms de chemins. A titre d’exemple, voyons dans la figure 5 le répertoire /Level7, qui a un nom de chemin entièrement qualifié de /Level1/Level2/ Level3/Level4/Level5/Level6/Level7. Si un job a pour mission de créer un grand nombre de fichiers stream dans le répertoire /Level7, il est tout indiqué de définir /Level1 /Level2/ Level3/Level4/Level5/Level6/Level7 comme CWD pour le job, avant de créer les fichiers stream. Après quoi, vous pourrez utiliser des noms de chemins relatifs (comme /Stmf1) pour créer les fichiers stream. Si vous utilisez des noms de chemins entièrement qualifiés (comme /Level1/ Level2/Level3/ Level4/Level5/Level6/Level7/Stmf1) lors de la création des fichiers stream, le système doit résoudre le nom de chemin entièrement qualifié pour le répertoire /Level7 pendant chaque création.

Des résolutions de noms de chemins excessives alourdissent considérablement la charge du système parce qu’il doit couvrir plusieurs étapes pendant la résolution : vérifier que l’utilisateur a l’autorité execute (*X) sur chaque répertoire présent dans le nom du chemin, éventuellement déposer un enregistrement d’audit pour chaque répertoire, et résoudre les liens symboliques. En réduisant cette charge, on améliore considérablement les performances du système, particulièrement s’il doit effectuer un grand nombre de résolutions de noms de chemins. Un test de performances utilisant l’exemple précédent indique que l’utilisation d’un CWD pour obtenir l’information pour (avec l’API stat()) ou ouvrir (avec l’API open()) le fichier stream /Level1/Level2/ Level3/Level4/Level5/Level6/Level7/Stmf1, est, en moyenne, environ trois à quatre fois plus rapide qu’avec le nom de chemin entièrement qualifié.

Il sera parfois impossible d’utiliser un CWD pour toutes les résolutions de noms de chemins. Dans une telle éventualité, il est bon que la sous-arborescence des répertoires soit aussi « plate » que possible. Il n’existe pas de nombre exact pour distinguer une sous-arborescence profonde d’une sous-arborescence plate en matière de répertoires. Par conséquent, il faut viser une sous-arborescence bien équilibrée : pas trop profonde (100 niveaux, par exemple) et pas trop plate (tous les objets système de fichiers dans le même répertoire, par exemple). En substance, on voit bien qu’un système de fichiers bien organisé qui réduit la résolution des noms de chemins, améliore les performances du système de fichiers. Pour plus d’informations sur les CWD (Files and file systems|Integrated file system|Concepts|Directory), visitez le V5R3 iSeries Information Center.