À partir de Red Hat Enterprise Linux 9, les systèmes de fichiers GFS2 sont créés avec le format version 1802.

La version 1802 du format permet les fonctionnalités suivantes :

Les systèmes de fichiers créés avec la nouvelle version du format ne pourront pas être montés sous les versions antérieures de RHEL et les anciennes versions de l'utilitaire fsck.gfs2 ne pourront pas les vérifier.

Les utilisateurs peuvent créer un système de fichiers avec l'ancienne version du format en exécutant la commande mkfs.gfs2 avec l'option -o format=1801.

Les utilisateurs peuvent mettre à jour la version du format d'un ancien système de fichiers fonctionnant sur un système de fichiers non monté tunegfs2 -r 1802 device sur un système de fichiers non monté. La rétrogradation de la version du format n'est pas prise en charge.

Avant d'installer et de configurer un système de fichiers GFS2, vous devez tenir compte d'un certain nombre de paramètres clés.

Pour pouvoir bénéficier de l'assistance de Red Hat pour un cluster exécutant un système de fichiers GFS2, vous devez prendre en compte les politiques d'assistance pour les systèmes de fichiers GFS2.

Pour formater votre système de fichiers GFS2 afin d'en optimiser les performances, vous devez tenir compte de ces recommandations.

Taille du système de fichiers : Plus c'est petit, mieux c'est

GFS2 est basé sur une architecture 64 bits, qui peut théoriquement accueillir un système de fichiers de 8 EB. Cependant, la taille maximale actuellement supportée par un système de fichiers GFS2 pour un matériel 64 bits est de 100 To.

Notez que même si les systèmes de fichiers GFS2 de grande taille sont possibles, cela ne signifie pas qu'ils sont recommandés. La règle de base avec GFS2 est que plus c'est petit, mieux c'est : il est préférable d'avoir 10 systèmes de fichiers de 1 To plutôt qu'un système de fichiers de 10 To.

Il y a plusieurs raisons pour lesquelles vous devriez garder vos systèmes de fichiers GFS2 de petite taille :

En outre, la réduction du nombre de groupes de ressources à gérer se traduit par de meilleures performances.

Bien entendu, si votre système de fichiers GFS2 est trop petit, vous risquez de manquer d'espace, ce qui n'est pas sans conséquences. Vous devez prendre en compte vos propres cas d'utilisation avant de décider de la taille du système.

Taille des blocs : Les blocs par défaut (4K) sont privilégiés

La commande mkfs.gfs2 tente d'estimer une taille de bloc optimale basée sur la topologie du périphérique. En général, les blocs de 4K sont la taille de bloc préférée car 4K est la taille de page par défaut (mémoire) pour Red Hat Enterprise Linux. Contrairement à d'autres systèmes de fichiers, GFS2 effectue la plupart de ses opérations en utilisant des tampons de noyau de 4K. Si la taille de votre bloc est de 4K, le noyau doit effectuer moins de travail pour manipuler les tampons.

Il est recommandé d'utiliser la taille de bloc par défaut, qui devrait permettre d'obtenir les meilleures performances. L'utilisation d'une taille de bloc différente n'est nécessaire que si vous avez besoin de stocker efficacement de nombreux petits fichiers.

Taille du journal : La valeur par défaut (128 Mo) est généralement optimale

Lorsque vous exécutez la commande mkfs.gfs2 pour créer un système de fichiers GFS2, vous pouvez spécifier la taille des journaux. Si vous n'indiquez pas de taille, la valeur par défaut est de 128 Mo, ce qui devrait être optimal pour la plupart des applications.

Certains administrateurs de système pourraient penser que 128 Mo est excessif et être tentés de réduire la taille du journal au minimum de 8 Mo ou à 32 Mo, ce qui est plus prudent. Bien que cette solution puisse fonctionner, elle peut avoir un impact important sur les performances. Comme de nombreux systèmes de fichiers avec journalisation, chaque fois que GFS2 écrit des métadonnées, celles-ci sont validées dans le journal avant d'être mises en place. Cela garantit que si le système tombe en panne ou perd de l'énergie, vous récupérerez toutes les métadonnées lorsque le journal sera automatiquement rejoué au moment du montage. Cependant, il ne faut pas beaucoup d'activité au système de fichiers pour remplir un journal de 8 Mo, et lorsque le journal est plein, les performances ralentissent car GFS2 doit attendre les écritures sur le stockage.

Il est généralement recommandé d'utiliser la taille de journal par défaut de 128 Mo. Si votre système de fichiers est très petit (par exemple, 5 Go), l'utilisation d'un journal de 128 Mo peut s'avérer peu pratique. Si vous disposez d'un système de fichiers plus important et que vous pouvez vous permettre d'utiliser l'espace nécessaire, l'utilisation de journaux de 256 Mo peut améliorer les performances.

Taille et nombre des groupes de ressources

Lorsqu'un système de fichiers GFS2 est créé à l'aide de la commande mkfs.gfs2, il divise le stockage en tranches uniformes appelées groupes de ressources. Il tente d'estimer une taille optimale pour les groupes de ressources (entre 32 Mo et 2 Go). Vous pouvez remplacer la valeur par défaut avec l'option -r de la commande mkfs.gfs2.

La taille optimale du groupe de ressources dépend de l'utilisation que vous ferez du système de fichiers. Tenez compte du degré de saturation du système et de la présence ou non d'une fragmentation importante.

Il est conseillé d'expérimenter différentes tailles de groupes de ressources afin de déterminer celle qui permet d'obtenir des performances optimales. La meilleure pratique consiste à expérimenter avec un cluster de test avant de déployer GFS2 en production complète.

Si votre système de fichiers comporte trop de groupes de ressources, chacun d'entre eux étant trop petit, les allocations de blocs peuvent perdre trop de temps à rechercher un bloc libre dans des dizaines de milliers de groupes de ressources. Plus votre système de fichiers est saturé, plus le nombre de groupes de ressources à rechercher est élevé, et chacun d'entre eux nécessite un verrou à l'échelle de la grappe. Les performances s'en trouvent ralenties.

Toutefois, si votre système de fichiers comporte trop peu de groupes de ressources, chacun d'entre eux étant trop grand, les allocations de blocs risquent de se disputer plus souvent le même verrou de groupe de ressources, ce qui a également un impact sur les performances. Par exemple, si vous avez un système de fichiers de 10 Go divisé en cinq groupes de ressources de 2 Go, les nœuds de votre cluster se disputeront ces cinq groupes de ressources plus souvent que si le même système de fichiers était divisé en 320 groupes de ressources de 32 Mo. Le problème est exacerbé si votre système de fichiers est presque plein, car chaque allocation de bloc peut devoir parcourir plusieurs groupes de ressources avant d'en trouver un avec un bloc libre. GFS2 tente d'atténuer ce problème de deux manières :

Le pire scénario est celui d'un répertoire central dans lequel tous les nœuds créent des fichiers, car tous les nœuds se battent constamment pour verrouiller le même groupe de ressources.

Lorsque vous déterminez le nombre de nœuds que votre système contiendra, notez qu'il existe un compromis entre la haute disponibilité et les performances. Avec un plus grand nombre de nœuds, il devient de plus en plus difficile de faire évoluer les charges de travail. Pour cette raison, Red Hat ne prend pas en charge l'utilisation de GFS2 pour les déploiements de systèmes de fichiers en cluster de plus de 16 nœuds.

Le déploiement d'un système de fichiers en grappe ne remplace pas le déploiement d'un nœud unique. Red Hat recommande de prévoir une période d'environ 8 à 12 semaines de tests sur les nouvelles installations afin de tester le système et de s'assurer qu'il fonctionne au niveau de performance requis. Au cours de cette période, tout problème de performance ou de fonctionnement peut être résolu et toute question doit être adressée à l'équipe d'assistance de Red Hat.

Red Hat recommande aux clients qui envisagent de déployer des clusters de faire réviser leurs configurations par le support Red Hat avant le déploiement afin d'éviter tout problème de support ultérieur.

Tenez compte des considérations matérielles suivantes lors du déploiement d'un système de fichiers GFS2.

Chaque inode de fichier et de répertoire est associé à trois horodatages :

Si les mises à jour de atime sont activées, comme c'est le cas par défaut sur GFS2 et d'autres systèmes de fichiers Linux, chaque fois qu'un fichier est lu, son inode doit être mis à jour.

Étant donné que peu d'applications utilisent les informations fournies par atime, ces mises à jour peuvent nécessiter une quantité importante de trafic d'écriture et de verrouillage de fichiers inutiles. Ce trafic peut dégrader les performances ; il peut donc être préférable de désactiver les mises à jour de atime ou d'en réduire la fréquence.

Les méthodes suivantes permettent de réduire les effets de la mise à jour de atime:

Utilisez la commande suivante pour monter un système de fichiers GFS2 avec l'option de montage noatime Linux.

mount BlockDevice MountPoint -o noatime

Dans cet exemple, le système de fichiers GFS2 réside sur /dev/vg01/lvol0 et est monté sur le répertoire /mygfs2, les mises à jour de atime étant désactivées.

# mount /dev/vg01/lvol0 /mygfs2 -o noatime

Comme tous les systèmes de fichiers Linux, GFS2 repose sur une couche appelée système de fichiers virtuels (VFS). Le VFS fournit de bonnes valeurs par défaut pour les paramètres de cache pour la plupart des charges de travail et ne devrait pas avoir besoin d'être modifié dans la plupart des cas. Toutefois, si vous avez une charge de travail qui ne fonctionne pas efficacement (par exemple, le cache est trop grand ou trop petit), vous pouvez améliorer les performances en utilisant la commande sysctl(8) pour ajuster les valeurs des fichiers sysctl dans le répertoire /proc/sys/vm. La documentation de ces fichiers se trouve dans l'arborescence des sources du noyau Documentation/sysctl/vm.txt.

Par exemple, les valeurs de dirty_background_ratio et vfs_cache_pressure peuvent être ajustées en fonction de votre situation. Pour obtenir les valeurs actuelles, utilisez les commandes suivantes :

# sysctl -n vm.dirty_background_ratio
# sysctl -n vm.vfs_cache_pressure

Les commandes suivantes permettent d'ajuster les valeurs :

# sysctl -w vm.dirty_background_ratio=20
# sysctl -w vm.vfs_cache_pressure=500

Vous pouvez modifier de façon permanente les valeurs de ces paramètres en éditant le fichier /etc/sysctl.conf.

Pour trouver les valeurs optimales pour vos cas d'utilisation, recherchez les différentes options VFS et expérimentez sur un cluster de test avant de le déployer en production.

L'utilisation de Security Enhanced Linux (SELinux) avec GFS2 entraîne une légère pénalité en termes de performances. Pour éviter cette surcharge, vous pouvez choisir de ne pas utiliser SELinux avec GFS2, même sur un système où SELinux est en mode d'application. Lors du montage d'un système de fichiers GFS2, vous pouvez vous assurer que SELinux n'essaiera pas de lire l'élément seclabel sur chaque objet du système de fichiers en utilisant l'une des options context décrites dans la page de manuel mount(8) ; SELinux supposera que tout le contenu du système de fichiers est étiqueté avec l'élément seclabel fourni dans les options de montage context. Cela accélérera également le traitement en évitant une autre lecture sur disque du bloc d'attributs étendu qui pourrait contenir des éléments seclabel.

Par exemple, sur un système doté de SELinux en mode renforcé, vous pouvez utiliser la commande mount suivante pour monter le système de fichiers GFS2 s'il doit contenir du contenu Apache. Cette étiquette s'applique à l'ensemble du système de fichiers ; elle reste en mémoire et n'est pas écrite sur le disque.

# mount -t gfs2 -o context=system_u:object_r:httpd_sys_content_t:s0 /dev/mapper/xyz/mnt/gfs2

Si vous n'êtes pas sûr que le système de fichiers contiendra du contenu Apache, vous pouvez utiliser les étiquettes public_content_rw_t ou public_content_t, ou vous pouvez définir une nouvelle étiquette et définir une politique autour d'elle.

Notez que dans un cluster Pacemaker, vous devez toujours utiliser Pacemaker pour gérer un système de fichiers GFS2. Vous pouvez spécifier les options de montage lorsque vous créez une ressource de système de fichiers GFS2.

En raison de la complexité accrue du sous-système de verrouillage GFS2 et de sa nature en grappe, la configuration de NFS sur GFS2 nécessite de nombreuses précautions.

Outre les considérations relatives au verrouillage, vous devez tenir compte des éléments suivants lors de la configuration d'un service NFS sur un système de fichiers GFS2.

Vous pouvez utiliser le service de fichiers Samba (SMB ou Windows) à partir d'un système de fichiers GFS2 avec CTDB, qui permet des configurations actives/actives.

L'accès simultané aux données du partage Samba depuis l'extérieur de Samba n'est pas pris en charge. Il n'y a actuellement aucune prise en charge des baux de grappes GFS2, qui ralentissent le service de fichiers Samba. Pour plus d'informations sur les politiques de prise en charge de Samba, voir Politiques de prise en charge du stockage résilient RHEL - Politiques générales de ctdb et Politiques de prise en charge du stockage résilient RHEL - Exportation de contenus gfs2 via d'autres protocoles.

Lors de l'utilisation d'un système de fichiers GFS2 avec une machine virtuelle, il est important que les paramètres de stockage de la VM sur chaque nœud soient configurés correctement afin de forcer la désactivation du cache. Par exemple, l'inclusion de ces paramètres pour cache et io dans le domaine libvirt devrait permettre à GFS2 de se comporter comme prévu.

<driver name='qemu' type='raw' cache='none' io='native'/>

Vous pouvez également configurer l'attribut shareable dans l'élément device. Cet attribut indique que l'appareil est censé être partagé entre les domaines (tant que l'hyperviseur et le système d'exploitation le prennent en charge). Si shareable est utilisé, cache='no' doit être utilisé pour ce dispositif.

Même si les applications qui ne font qu'écrire des données ne se soucient généralement pas de savoir comment ou où un bloc est alloué, une certaine connaissance du fonctionnement de l'allocation des blocs peut vous aider à optimiser les performances.

Vous créez un système de fichiers GFS2 à l'aide de la commande mkfs.gfs2. Un système de fichiers est créé sur un volume LVM activé.

mkfs.gfs2 -p lock_dlm -t ClusterName:FSName -j NumberJournals BlockDevice

mkfs -t gfs2 -p lock_dlm -t ClusterName:FSName -j NumberJournals BlockDevice

# mkfs.gfs2 -p lock_dlm -t alpha:mydata1 -j 8 /dev/vg01/lvol0
# mkfs.gfs2 -p lock_dlm -t alpha:mydata2 -j 8 /dev/vg01/lvol1

Avant de pouvoir monter un système de fichiers GFS2, le système de fichiers doit exister, le volume où se trouve le système de fichiers doit être activé et les systèmes de clustering et de verrouillage doivent être démarrés. Une fois ces conditions remplies, vous pouvez monter le système de fichiers GFS2 comme n'importe quel système de fichiers Linux.

Pour manipuler les ACL de fichiers, vous devez monter le système de fichiers avec l'option de montage -o acl. Si un système de fichiers est monté sans l'option de montage -o acl, les utilisateurs sont autorisés à visualiser les listes de contrôle d'accès (avec getfacl), mais ne sont pas autorisés à les définir (avec setfacl).

# mount /dev/vg01/lvol0 /mygfs2

mount BlockDevice MountPoint -o option

montage MountPoint

Il est important d'effectuer des sauvegardes régulières de votre système de fichiers GFS2 en cas d'urgence, quelle que soit la taille de votre système de fichiers. De nombreux administrateurs système se sentent en sécurité parce qu'ils sont protégés par des systèmes RAID, multipath, mirroring, snapshots et autres formes de redondance, mais il n'y a pas de sécurité suffisante.

La création d'une sauvegarde peut s'avérer problématique car le processus de sauvegarde d'un nœud ou d'un ensemble de nœuds implique généralement la lecture séquentielle de l'ensemble du système de fichiers. Si cette opération est effectuée à partir d'un seul nœud, celui-ci conservera toutes les informations en mémoire cache jusqu'à ce que les autres nœuds de la grappe commencent à demander des verrous. L'exécution de ce type de programme de sauvegarde pendant que la grappe fonctionne aura un impact négatif sur les performances.

L'abandon des caches une fois la sauvegarde terminée réduit le temps nécessaire aux autres nœuds pour reprendre possession de leurs verrous/caches de cluster. Cette solution n'est toutefois pas idéale, car les autres nœuds auront cessé de mettre en cache les données qu'ils mettaient en cache avant le début du processus de sauvegarde. Vous pouvez supprimer les caches à l'aide de la commande suivante une fois la sauvegarde terminée :

echo -n 3 > /proc/sys/vm/drop_caches

Il est plus rapide que chaque nœud de la grappe sauvegarde ses propres fichiers afin que la tâche soit répartie entre les nœuds. Vous pouvez y parvenir avec un script qui utilise la commande rsync sur des répertoires spécifiques à chaque nœud.

Red Hat recommande d'effectuer une sauvegarde GFS2 en créant un instantané matériel sur le SAN, en présentant l'instantané à un autre système et en le sauvegardant à cet endroit. Le système de sauvegarde doit monter l'instantané avec -o lockproto=lock_nolock puisqu'il ne sera pas dans un cluster.

Vous pouvez suspendre l'activité d'écriture sur un système de fichiers à l'aide de la commande dmsetup suspend. La suspension de l'activité d'écriture permet d'utiliser des instantanés de périphériques matériels pour capturer le système de fichiers dans un état cohérent. La commande dmsetup resume met fin à la suspension.

Le format de la commande de suspension de l'activité d'un système de fichiers GFS2 est le suivant.

dmsetup suspend MountPoint

Cet exemple suspend les écritures sur le système de fichiers /mygfs2.

# dmsetup suspend /mygfs2

Le format de la commande de fin de suspension d'activité sur un système de fichiers GFS2 est le suivant.

dmsetup resume MountPoint

Cet exemple met fin à la suspension des écritures sur le système de fichiers /mygfs2.

# dmsetup resume /mygfs2

La commande gfs2_grow est utilisée pour étendre un système de fichiers GFS2 après que le périphérique où réside le système de fichiers a été étendu. L'exécution de la commande gfs2_grow sur un système de fichiers GFS2 existant remplit tout l'espace libre entre l'extrémité actuelle du système de fichiers et l'extrémité du périphérique avec une extension de système de fichiers GFS2 nouvellement initialisée. Tous les nœuds du cluster peuvent alors utiliser l'espace de stockage supplémentaire qui a été ajouté.

La commande gfs2_grow doit être exécutée sur un système de fichiers monté. La procédure suivante permet d'augmenter la taille du système de fichiers GFS2 dans un cluster qui est monté sur le volume logique shared_vg/shared_lv1 avec un point de montage de /mnt/gfs2.

GFS2 nécessite un journal pour chaque nœud d'une grappe qui doit monter le système de fichiers. Si vous ajoutez des nœuds supplémentaires à la grappe, vous pouvez ajouter des journaux à un système de fichiers GFS2 à l'aide de la commande gfs2_jadd. Vous pouvez ajouter des journaux à un système de fichiers GFS2 de manière dynamique à tout moment sans étendre le volume logique sous-jacent. La commande gfs2_jadd doit être exécutée sur un système de fichiers monté, mais sur un seul nœud du cluster. Tous les autres nœuds détectent que l'extension a eu lieu.

Avant d'ajouter des journaux à un système de fichiers GFS2, vous pouvez savoir combien de journaux le système de fichiers GFS2 contient actuellement à l'aide de la commande gfs2_edit -p jindex, comme dans l'exemple suivant :

# gfs2_edit -p jindex /dev/sasdrives/scratch|grep journal
   3/3 [fc7745eb] 4/25 (0x4/0x19): File    journal0
   4/4 [8b70757d] 5/32859 (0x5/0x805b): File    journal1
   5/5 [127924c7] 6/65701 (0x6/0x100a5): File    journal2

Le format de la commande de base pour ajouter des journaux à un système de fichiers GFS2 est le suivant.

gfs2_jadd -j Number MountPoint

Dans cet exemple, un journal est ajouté au système de fichiers du répertoire /mygfs2.

# gfs2_jadd -j 1 /mygfs2

La mise en œuvre des quotas de disque pour les systèmes de fichiers GFS2 s'effectue en trois étapes.

Les étapes à suivre pour mettre en œuvre les quotas de disque sont les suivantes :

Chacune de ces étapes est examinée en détail dans les sections suivantes.

# pcs resource create gfs2mount Filesystem options="quota=on" device=BLOCKDEVICE directory=MOUNTPOINT fstype=gfs2 clone

# quotacheck -ug /home

# edquota username

Disk quotas for user testuser (uid 501):
Filesystem                blocks     soft     hard    inodes   soft   hard
/dev/VolGroup00/LogVol02  440436        0        0

Disk quotas for user testuser (uid 501):
Filesystem                blocks     soft     hard    inodes   soft   hard
/dev/VolGroup00/LogVol02  440436   500000   550000

# quota testuser

# edquota -g devel

Disk quotas for group devel (gid 505):
Filesystem                blocks    soft     hard    inodes   soft   hard
/dev/VolGroup00/LogVol02  440400       0        0

$ quota -g devel

Si des quotas sont mis en place, ils nécessitent une certaine maintenance, principalement sous la forme d'une surveillance pour voir si les quotas sont dépassés et pour s'assurer que les quotas sont exacts.

Si les utilisateurs dépassent leurs quotas de façon répétée ou atteignent régulièrement leurs limites, l'administrateur système a plusieurs choix à faire en fonction du type d'utilisateurs et de l'impact de l'espace disque sur leur travail. L'administrateur peut soit aider l'utilisateur à déterminer comment utiliser moins d'espace disque, soit augmenter le quota de l'utilisateur.

Vous pouvez créer un rapport sur l'utilisation du disque en exécutant l'utilitaire repquota. Par exemple, la commande repquota /home produit le résultat suivant :

*** Report for user quotas on device /dev/mapper/VolGroup00-LogVol02
Block grace time: 7days; Inode grace time: 7days
			Block limits			File limits
User		used	soft	hard	grace	used	soft	hard	grace
----------------------------------------------------------------------
root      --      36       0       0              4     0     0
kristin   --     540       0       0            125     0     0
testuser  --  440400  500000  550000          37418     0     0

Pour afficher le rapport d'utilisation du disque pour tous les systèmes de fichiers à quotas (option -a), utilisez la commande suivante :

# repquota -a

Le message -- affiché après chaque utilisateur est un moyen rapide de déterminer si les limites de blocage ont été dépassées. Si la limite de blocs est dépassée, un apparaît à la place du premier - dans la sortie. Le deuxième - indique la limite d'inode, mais les systèmes de fichiers GFS2 ne prennent pas en charge les limites d'inode ; ce caractère restera donc -. Les systèmes de fichiers GFS2 ne prennent pas en charge le délai de grâce, de sorte que la colonne grace reste vide.

Notez que la commande repquota n'est pas prise en charge par NFS, quel que soit le système de fichiers sous-jacent.

Si vous activez les quotas sur votre système de fichiers après une période pendant laquelle les quotas étaient désactivés, vous devez exécuter la commande quotacheck pour créer, vérifier et réparer les fichiers de quotas. En outre, vous pouvez exécuter la commande quotacheck si vous pensez que vos fichiers de quotas ne sont pas exacts, comme cela peut se produire lorsqu'un système de fichiers n'est pas démonté proprement après une panne du système.

Pour plus d'informations sur la commande quotacheck, voir la page de manuel quotacheck(8).

GFS2 stocke toutes les informations relatives aux quotas dans son propre fichier interne sur le disque. Un nœud GFS2 ne met pas à jour ce fichier de quotas à chaque écriture du système de fichiers ; par défaut, il met à jour le fichier de quotas une fois toutes les 60 secondes. Cela est nécessaire pour éviter les conflits entre les nœuds qui écrivent dans le fichier de quotas, ce qui entraînerait un ralentissement des performances.

Lorsqu'un utilisateur ou un groupe approche de sa limite de quota, GFS2 réduit dynamiquement l'intervalle de temps entre les mises à jour des fichiers de quota afin d'empêcher le dépassement de la limite. Le délai normal entre les synchronisations de quotas est un paramètre réglable, quota_quantum. Vous pouvez le modifier par rapport à sa valeur par défaut de 60 secondes à l'aide de l'option de montage quota_quantum=, comme décrit dans le tableau "Options de montage spécifiques à GFS2" dans Montage d'un système de fichiers GFS2 qui spécifie les options de montage.

Le paramètre quota_quantum doit être défini sur chaque nœud et à chaque fois que le système de fichiers est monté. Les modifications apportées au paramètre quota_quantum ne sont pas persistantes lors des démontages. Vous pouvez mettre à jour la valeur quota_quantum à l'aide de la commande mount -o remount.

Vous pouvez utiliser la commande quotasync pour synchroniser les informations de quotas d'un nœud avec le fichier de quotas sur disque entre les mises à jour automatiques effectuées par GFS2. Utilisation Synchronizing Quota Information

quotasync [-ug] -a|mountpoint...

Vous pouvez régler le délai entre les synchronisations en spécifiant une option de montage quota-quantum.

# mount -o quota_quantum=secs,remount BlockDevice MountPoint

L'exemple suivant synchronise tous les quotas sales mis en cache du nœud sur lequel il est exécuté avec le fichier de quotas sur disque pour le système de fichiers /mnt/mygfs2.

# quotasync -ug /mnt/mygfs2

L'exemple suivant modifie le délai par défaut entre les mises à jour régulières des fichiers de quotas à une heure (3600 secondes) pour le système de fichiers /mnt/mygfs2 lors du remontage de ce système de fichiers sur le volume logique /dev/volgroup/logical_volume.

# mount -o quota_quantum=3600,remount /dev/volgroup/logical_volume /mnt/mygfs2

L'exécution de la commande fsck.gfs2 peut nécessiter de la mémoire système en plus de la mémoire utilisée pour le système d'exploitation et le noyau. Les systèmes de fichiers de grande taille, en particulier, peuvent nécessiter de la mémoire supplémentaire pour exécuter cette commande.

Le tableau suivant indique les valeurs approximatives de mémoire qui peuvent être nécessaires pour exécuter les systèmes de fichiers fsck.gfs2 sur des systèmes de fichiers GFS2 d'une taille de 1 To, 10 To et 100 To avec une taille de bloc de 4K.

Notez qu'une taille de bloc plus petite pour le système de fichiers nécessiterait une plus grande quantité de mémoire. Par exemple, les systèmes de fichiers GFS2 avec une taille de bloc de 1K nécessiteraient quatre fois la quantité de mémoire indiquée dans ce tableau.

Le format de la commande fsck.gfs2 pour réparer un système de fichiers GFS2 est le suivant :

fsck.gfs2 -y BlockDevice

Dans cet exemple, le système de fichiers GFS2 résidant sur le périphérique de bloc /dev/testvg/testlv est réparé. Toutes les demandes de réparation reçoivent automatiquement la réponse suivante : yes.

# fsck.gfs2 -y /dev/testvg/testlv
Initializing fsck
Validating Resource Group index.
Level 1 RG check.
(level 1 passed)
Clearing journals (this may take a while)...
Journals cleared.
Starting pass1
Pass1 complete
Starting pass1b
Pass1b complete
Starting pass1c
Pass1c complete
Starting pass2
Pass2 complete
Starting pass3
Pass3 complete
Starting pass4
Pass4 complete
Starting pass5
Pass5 complete
Writing changes to disk
fsck.gfs2 complete

Bien qu'il n'existe pas d'outil de défragmentation pour GFS2 sur Red Hat Enterprise Linux, vous pouvez défragmenter des fichiers individuels en les identifiant avec l'outil filefrag, en les copiant dans des fichiers temporaires et en renommant les fichiers temporaires pour remplacer les originaux.

Afin d'obtenir les meilleures performances d'un système de fichiers GFS2, il est important de comprendre la théorie de base de son fonctionnement. Un système de fichiers à nœud unique est mis en œuvre avec un cache, dont le but est d'éliminer la latence des accès au disque lors de l'utilisation de données fréquemment demandées. Sous Linux, le cache de page (et historiquement le cache tampon) assure cette fonction de mise en cache.

Avec GFS2, chaque nœud possède son propre cache de pages qui peut contenir une partie des données sur disque. GFS2 utilise un mécanisme de verrouillage appelé glocks (prononcé gee-locks) pour maintenir l'intégrité du cache entre les nœuds. Le sous-système glock fournit une fonction de gestion du cache qui est mise en œuvre en utilisant distributed lock manager (DLM) comme couche de communication sous-jacente.

Les verrous assurent la protection du cache par inode, de sorte qu'il existe un verrou par inode utilisé pour contrôler la couche de cache. Si ce verrou est accordé en mode partagé (DLM lock mode : PR), les données sous ce verrou peuvent être mises en cache sur un ou plusieurs nœuds en même temps, de sorte que tous les nœuds peuvent avoir un accès local aux données.

Si le glock est accordé en mode exclusif (DLM lock mode : EX), seul un nœud unique peut mettre en cache les données sous ce glock. Ce mode est utilisé par toutes les opérations qui modifient les données (comme l'appel système write ).

Si un autre nœud demande un verrou qui ne peut être accordé immédiatement, le DLM envoie un message au(x) nœud(s) qui détient(nt) actuellement les verrous bloquant la nouvelle demande pour leur demander d'abandonner leurs verrous. L'abandon des verrous peut être un processus long (par rapport à la plupart des opérations du système de fichiers). L'abandon d'un verrou partagé ne nécessite que l'invalidation du cache, ce qui est relativement rapide et proportionnel à la quantité de données mises en cache.

L'abandon d'un bloc exclusif nécessite une vidange du journal et la réécriture de toutes les données modifiées sur le disque, suivies de l'invalidation conformément au bloc partagé.

La différence entre un système de fichiers à nœud unique et GFS2 réside donc dans le fait qu'un système de fichiers à nœud unique dispose d'un seul cache et que GFS2 dispose d'un cache séparé sur chaque nœud. Dans les deux cas, le temps de latence pour accéder aux données mises en cache est du même ordre de grandeur, mais le temps de latence pour accéder aux données non mises en cache est beaucoup plus important dans GFS2 si un autre nœud a précédemment mis en cache ces mêmes données.

Les opérations telles que read (buffered), stat, et readdir ne nécessitent qu'un sas partagé. Les opérations telles que write (buffered), mkdir, rmdir, et unlink nécessitent un sas exclusif. Les opérations de lecture/écriture d'E/S directes nécessitent un sas différé si aucune allocation n'a lieu, ou un sas exclusif si l'écriture nécessite une allocation (c'est-à-dire l'extension du fichier ou le remplissage de trous).

Il en découle deux considérations principales en matière de performances. Tout d'abord, les opérations en lecture seule se parallélisent très bien au sein d'un cluster, puisqu'elles peuvent être exécutées indépendamment sur chaque nœud. Deuxièmement, les opérations nécessitant un bloc exclusif peuvent réduire les performances si plusieurs nœuds se disputent l'accès au(x) même(s) inode(s). La prise en compte de l'ensemble de travail sur chaque nœud est donc un facteur important dans les performances du système de fichiers GFS2, par exemple lorsque vous effectuez une sauvegarde du système de fichiers, comme décrit dans Sauvegarde d'un système de fichiers GFS2.

En conséquence, nous recommandons l'utilisation de l'option de montage noatime ou nodiratime avec GFS2 dans la mesure du possible, avec une préférence pour noatime lorsque l'application le permet. Cela empêche les lectures de nécessiter des verrous exclusifs pour mettre à jour l'horodatage de atime.

Pour les utilisateurs soucieux de l'efficacité de l'ensemble de travail ou de la mise en cache, GFS2 fournit des outils qui permettent de surveiller les performances d'un système de fichiers GFS2 : Performance Co-Pilot et GFS2 tracepoints.

Lors de l'utilisation du verrouillage Posix, il convient de tenir compte des éléments suivants :

Il est généralement possible de modifier la manière dont une application gênante stocke ses données afin d'obtenir un avantage considérable en termes de performances.

Un exemple typique d'application problématique est un serveur de courrier électronique. Ceux-ci sont souvent organisés avec un répertoire spool contenant des fichiers pour chaque utilisateur (mbox), ou avec un répertoire pour chaque utilisateur contenant un fichier pour chaque message (maildir). Lorsque les demandes arrivent par IMAP, l'idéal est de donner à chaque utilisateur une affinité avec un nœud particulier. De cette manière, les demandes de consultation et de suppression de messages électroniques seront généralement traitées à partir du cache de ce nœud. Évidemment, si ce nœud tombe en panne, la session peut être redémarrée sur un autre nœud.

Lorsque le courrier arrive par SMTP, les nœuds individuels peuvent être configurés de manière à transmettre par défaut le courrier d'un utilisateur donné à un nœud particulier. Si le nœud par défaut n'est pas en place, le message peut être enregistré directement dans le spool de l'utilisateur par le nœud de réception. Là encore, cette conception vise à conserver des ensembles particuliers de fichiers en cache sur un seul nœud dans le cas normal, mais à permettre un accès direct en cas de défaillance d'un nœud.

Cette configuration permet d'utiliser au mieux le cache de pages de GFS2 et rend les défaillances transparentes pour l'application, qu'il s'agisse de imap ou de smtp.

La sauvegarde est souvent un autre point délicat. Encore une fois, si cela est possible, il est largement préférable de sauvegarder l'ensemble de travail de chaque nœud directement à partir du nœud qui met en cache cet ensemble particulier d'inodes. Si vous avez un script de sauvegarde qui s'exécute à intervalles réguliers et qui semble coïncider avec un pic dans le temps de réponse d'une application fonctionnant sur GFS2, il y a de fortes chances que le cluster n'utilise pas le cache de pages de la manière la plus efficace possible.

Évidemment, si vous êtes en mesure d'arrêter l'application pour effectuer une sauvegarde, cela ne posera pas de problème. En revanche, si une sauvegarde est exécutée à partir d'un seul nœud, une fois qu'elle est terminée, une grande partie du système de fichiers sera mise en cache sur ce nœud, ce qui pénalisera les performances pour les accès ultérieurs à partir d'autres nœuds. Ce problème peut être atténué dans une certaine mesure en supprimant le cache de page VFS sur le nœud de sauvegarde une fois la sauvegarde terminée à l'aide de la commande suivante :

echo -n 3 >/proc/sys/vm/drop_caches

Toutefois, cette solution n'est pas aussi bonne que celle qui consiste à s'assurer que l'ensemble de travail de chaque nœud est soit partagé, soit principalement en lecture seule dans la grappe, soit accessible en grande partie à partir d'un seul nœud.

Si les performances de votre cluster sont affectées par une utilisation inefficace de la mise en cache GFS2, vous pouvez observer des temps d'attente d'E/S importants et croissants. Vous pouvez utiliser les informations de vidage de verrou de GFS2 pour déterminer la cause du problème.

Les informations sur le vidage des verrous GFS2 peuvent être recueillies dans le fichier debugfs qui se trouve dans le chemin d'accès suivant, en supposant que debugfs soit monté sur /sys/kernel/debug/:

/sys/kernel/debug/gfs2/fsname/glocks

Le contenu du fichier est une série de lignes. Chaque ligne commençant par G : représente un glock, et les lignes suivantes, indentées d'un seul espace, représentent une information relative au glock qui les précède immédiatement dans le fichier.

La meilleure façon d'utiliser le fichier debugfs est d'utiliser la commande cat pour prendre une copie du contenu complet du fichier (cela peut prendre beaucoup de temps si vous avez une grande quantité de mémoire vive et beaucoup d'inodes en cache) pendant que l'application rencontre des problèmes, puis d'examiner les données résultantes à une date ultérieure.

Les lignes du fichier debugfs commençant par H : (holders) représentent des demandes de verrouillage accordées ou en attente d'être accordées. Le champ flags de la ligne f : (holders) indique lesquelles : Le drapeau "W" correspond à une demande en attente, le drapeau "H" à une demande accordée. Les glocks qui présentent un grand nombre de demandes en attente sont probablement ceux qui font l'objet d'une contestation particulière.

Les tableaux suivants indiquent la signification des drapeaux de glock et des drapeaux de porte-glock.

Après avoir identifié un glock qui pose problème, l'étape suivante consiste à déterminer à quel inode il se rapporte. Le numéro du glock (n : sur la ligne G :) l'indique. Il est de la forme type/number et si type est égal à 2, le glock est un inode glock et number est un numéro d'inode. Pour retrouver l'inode, vous pouvez alors exécuter find -inum number où number est le numéro d'inode converti en décimal à partir du format hexadécimal du fichier glocks.

Le tableau suivant indique la signification des différents types de glock.

Si le glock identifié était d'un type différent, il est plus probable qu'il soit de type 3 : (groupe de ressources). Si vous observez un nombre significatif de processus en attente d'autres types de glock sous des charges normales, signalez-le à l'assistance de Red Hat.

Si vous voyez un certain nombre de demandes en attente sur un verrou de groupe de ressources, il peut y avoir plusieurs raisons à cela. L'une d'elles est qu'il y a un grand nombre de nœuds par rapport au nombre de groupes de ressources dans le système de fichiers. Une autre raison est que le système de fichiers est presque plein (ce qui nécessite, en moyenne, des recherches plus longues pour les blocs libres). Dans les deux cas, la situation peut être améliorée en ajoutant de l'espace de stockage et en utilisant la commande gfs2_grow pour étendre le système de fichiers.

En règle générale, GFS2 n'écrit que les métadonnées dans son journal. Le contenu des fichiers est ensuite écrit sur le disque par la synchronisation périodique du noyau qui vide les tampons du système de fichiers. Un appel à fsync() sur un fichier entraîne l'écriture immédiate des données du fichier sur le disque. L'appel est renvoyé lorsque le disque signale que toutes les données ont été écrites en toute sécurité.

La journalisation des données peut se traduire par une réduction du temps fsync() pour les très petits fichiers, car les données du fichier sont écrites dans le journal en plus des métadonnées. Cet avantage diminue rapidement à mesure que la taille du fichier augmente. L'écriture sur des fichiers de taille moyenne ou supérieure sera beaucoup plus lente si la journalisation des données est activée.

Les applications qui s'appuient sur fsync() pour synchroniser les données des fichiers peuvent voir leurs performances améliorées par l'utilisation de la journalisation des données. La journalisation des données peut être activée automatiquement pour tous les fichiers GFS2 créés dans un répertoire marqué (et tous ses sous-répertoires). La journalisation des données peut également être activée ou désactivée pour les fichiers existants de longueur nulle.

L'activation de la journalisation des données dans un répertoire lui confère la valeur "inherit jdata", ce qui indique que tous les fichiers et répertoires créés ultérieurement dans ce répertoire sont journalisés. Vous pouvez activer et désactiver la journalisation des données sur un fichier à l'aide de la commande chattr.

Les commandes suivantes activent la journalisation des données sur le fichier /mnt/gfs2/gfs2_dir/newfile et vérifient ensuite si l'indicateur a été correctement défini.

# chattr +j /mnt/gfs2/gfs2_dir/newfile
# lsattr /mnt/gfs2/gfs2_dir
---------j--- /mnt/gfs2/gfs2_dir/newfile

Les commandes suivantes désactivent la journalisation des données sur le fichier /mnt/gfs2/gfs2_dir/newfile et vérifient ensuite si l'indicateur a été correctement défini.

# chattr -j /mnt/gfs2/gfs2_dir/newfile
# lsattr /mnt/gfs2/gfs2_dir
------------- /mnt/gfs2/gfs2_dir/newfile

Vous pouvez également utiliser la commande chattr pour activer l'indicateur j sur un répertoire. Lorsque vous activez cet indicateur pour un répertoire, tous les fichiers et répertoires créés ultérieurement dans ce répertoire sont journalisés. Le jeu de commandes suivant définit l'indicateur j pour le répertoire gfs2_dir, puis vérifie si l'indicateur a été correctement défini. Ensuite, les commandes créent un nouveau fichier appelé newfile dans le répertoire /mnt/gfs2/gfs2_dir, puis vérifient si l'indicateur j a été défini pour le fichier. Puisque l'indicateur j est activé pour le répertoire, la journalisation doit également être activée pour newfile.

# chattr -j /mnt/gfs2/gfs2_dir
# lsattr /mnt/gfs2
---------j--- /mnt/gfs2/gfs2_dir
# touch /mnt/gfs2/gfs2_dir/newfile
# lsattr /mnt/gfs2/gfs2_dir
---------j--- /mnt/gfs2/gfs2_dir/newfile

La fonction GFS2 withdraw est une fonction d'intégrité des données du système de fichiers GFS2 qui empêche tout dommage potentiel du système de fichiers dû à un matériel ou à un logiciel noyau défectueux. Si le module du noyau GFS2 détecte une incohérence lors de l'utilisation d'un système de fichiers GFS2 sur un nœud de cluster donné, il se retire du système de fichiers, le rendant indisponible pour ce nœud jusqu'à ce qu'il soit démonté et remonté (ou que la machine détectant le problème soit redémarrée). Tous les autres systèmes de fichiers GFS2 montés restent pleinement fonctionnels sur ce nœud. (La fonction de retrait de GFS2 est moins grave qu'une panique du noyau, qui entraîne la clôture du nœud)

Les principales catégories d'incohérences pouvant entraîner un retrait de la GFS2 sont les suivantes :

Un exemple d'incohérence susceptible d'entraîner un retrait de GFS2 est un nombre de blocs incorrect pour l'inode d'un fichier. Lorsque GFS2 supprime un fichier, il supprime systématiquement tous les blocs de données et de métadonnées référencés par ce fichier. Il vérifie ensuite le nombre de blocs de l'inode. Si le nombre de blocs n'est pas égal à 1 (ce qui signifie qu'il ne reste que l'inode du disque lui-même), cela indique une incohérence du système de fichiers, car le nombre de blocs de l'inode ne correspond pas aux blocs réellement utilisés pour le fichier.

Dans de nombreux cas, le problème peut avoir été causé par un matériel défectueux (mémoire défectueuse, carte mère, HBA, lecteurs de disques, câbles, etc.) Il peut également être dû à un bogue du noyau (un autre module du noyau écrasant accidentellement la mémoire de GFS2) ou à une détérioration réelle du système de fichiers (causée par un bogue de GFS2).

Dans la plupart des cas, la meilleure façon de récupérer un système de fichiers GFS2 retiré est de redémarrer ou de clôturer le nœud. Le système de fichiers GFS2 retiré vous donnera l'occasion de déplacer les services vers un autre nœud du cluster. Une fois les services déplacés, vous pouvez redémarrer le nœud ou forcer une clôture à l'aide de cette commande.

pcs stonith fence node

Le problème de cohérence à l'origine du retrait peut rendre impossible l'arrêt du service de système de fichiers, car il risque de bloquer le système.

Si le problème persiste après un remontage, vous devez arrêter le service de système de fichiers pour démonter le système de fichiers sur tous les nœuds du cluster, puis effectuer un contrôle du système de fichiers à l'aide de la commande fsck.gfs2 avant de redémarrer le service à l'aide de la procédure suivante.

Vous pouvez remplacer la fonction de retrait de GFS2 en montant le système de fichiers avec l'option -o errors=panic spécifiée dans le service du système de fichiers.

# pcs resource update mydata_fs “options=noatime,errors=panic”

Lorsque cette option est spécifiée, toutes les erreurs qui entraîneraient normalement le retrait du système provoquent une panique du noyau. Les communications du nœud sont alors interrompues, ce qui entraîne la clôture du nœud. Cette option est particulièrement utile pour les grappes qui sont laissées sans surveillance pendant de longues périodes sans contrôle ni intervention.

En interne, la fonction de retrait de GFS2 fonctionne en déconnectant le protocole de verrouillage afin de garantir que toutes les opérations ultérieures du système de fichiers se traduisent par des erreurs d'E/S. Par conséquent, lorsque le retrait se produit, il est normal de voir un certain nombre d'erreurs d'E/S provenant du périphérique de mappage signalées dans les journaux du système.

Si votre système de fichiers GFS2 se bloque et ne renvoie pas les commandes exécutées, mais que le redémarrage d'un nœud spécifique ramène le système à la normale, cela peut indiquer un problème de verrouillage ou un bogue. Si cela se produit, rassemblez les données GFS2 pendant l'une de ces occurrences et ouvrez un ticket d'assistance avec l'assistance de Red Hat, comme décrit dans Rassembler les données GFS2 pour le dépannage.

Si votre système de fichiers GFS2 se bloque et ne renvoie pas les commandes exécutées, ce qui vous oblige à redémarrer tous les nœuds de la grappe avant de l'utiliser, vérifiez les points suivants.

Si vous ajoutez un nouveau nœud à un cluster et que vous constatez que vous ne pouvez pas monter votre système de fichiers GFS2 sur ce nœud, il se peut que vous ayez moins de journaux sur le système de fichiers GFS2 que de nœuds tentant d'accéder au système de fichiers GFS2. Vous devez disposer d'un journal par hôte GFS2 sur lequel vous souhaitez monter le système de fichiers (à l'exception des systèmes de fichiers GFS2 montés avec l'option de montage spectator, qui ne nécessitent pas de journal). Vous pouvez ajouter des journaux à un système de fichiers GFS2 à l'aide de la commande gfs2_jadd, comme décrit dans Ajout de journaux à un système de fichiers GFS2.

If you have an empty GFS2 file system, the df command will show that there is space being taken up. This is because GFS2 file system journals consume space (number of journals * journal size) on disk. If you created a GFS2 file system with a large number of journals or specified a large journal size then you will be see (number of journals * journal size) as already in use when you execute the df command. Even if you did not specify a large number of journals or large journals, small GFS2 file systems (in the 1GB or less range) will show a large amount of space as being in use with the default GFS2 journal size.

Si votre système de fichiers GFS2 se bloque et ne renvoie pas les commandes exécutées contre lui et que vous estimez devoir ouvrir un ticket avec l'assistance de Red Hat, vous devez tout d'abord rassembler les données suivantes :

Une fois que vous avez rassemblé ces données, vous pouvez ouvrir un ticket avec le support de Red Hat et fournir les données que vous avez collectées.

Vous pouvez configurer un cluster Pacemaker comprenant des systèmes de fichiers GFS2 à l'aide de la procédure suivante. Dans cet exemple, vous créez trois systèmes de fichiers GFS2 sur trois volumes logiques dans un cluster à deux nœuds.

Pour plus d'informations sur la création d'un cluster Pacemaker et la configuration de la clôture pour le cluster, voir Création d'un cluster Red Hat High-Availability avec Pacemaker.

Vous pouvez créer un cluster Pacemaker qui inclut un système de fichiers GFS2 crypté LUKS à l'aide de la procédure suivante. Dans cet exemple, vous créez un système de fichiers GFS2 sur un volume logique et vous chiffrez le système de fichiers. Les systèmes de fichiers GFS2 chiffrés sont pris en charge par l'agent de ressources crypt, qui prend en charge le chiffrement LUKS.

Cette procédure comporte trois parties :

[root@z1 ~]# lvs
  LV         VG          Attr       LSize
  shared_lv1 shared_vg1  -wi-a----- 5.00g

[root@z2 ~]# lvs
  LV         VG          Attr       LSize
  shared_lv1 shared_vg1  -wi-a----- 5.00g

[root@z1 ~]# ls -l /dev/mapper/
...
lrwxrwxrwx 1 root root 7 Mar 4 09:52 luks_lv1 -> ../dm-3
...

Il existe actuellement trois types de tracepoints GFS2 : glock (prononcé "gee-lock") tracepoints, bmap tracepoints et log tracepoints. Ils peuvent être utilisés pour surveiller un système de fichiers GFS2 en cours d'exécution et fournir des informations supplémentaires à celles qui peuvent être obtenues avec les options de débogage prises en charge dans les versions précédentes de Red Hat Enterprise Linux. Les points de contrôle sont particulièrement utiles lorsqu'un problème, tel qu'un blocage ou un problème de performance, est reproductible et que la sortie du point de contrôle peut être obtenue pendant l'opération problématique. Dans GFS2, les glocks sont le principal mécanisme de contrôle du cache et ils sont la clé pour comprendre les performances du cœur de GFS2. Les points de contrôle bmap (block map) peuvent être utilisés pour surveiller les allocations de blocs et le mappage de blocs (recherche de blocs déjà alloués dans l'arborescence des métadonnées du disque) au fur et à mesure qu'ils se produisent et pour vérifier tout problème lié à la localité de l'accès. Les tracepoints de journal suivent les données écrites et libérées du journal et peuvent fournir des informations utiles sur cette partie de GFS2.

Les tracepoints sont conçus pour être aussi génériques que possible, ce qui devrait signifier qu'il ne sera pas nécessaire de modifier l'API au cours de Red Hat Enterprise Linux 8. D'un autre côté, les utilisateurs de cette interface doivent savoir qu'il s'agit d'une interface de débogage et qu'elle ne fait pas partie de l'ensemble des API normales de Red Hat Enterprise Linux 8, et qu'en tant que telle, Red Hat ne garantit pas que des changements ne seront pas apportés à l'interface des tracepoints de GFS2.

Les tracepoints sont une caractéristique générique de Red Hat Enterprise Linux et leur champ d'application va bien au-delà de GFS2. Ils sont notamment utilisés pour mettre en œuvre l'infrastructure blktrace et les tracepoints blktrace peuvent être utilisés en combinaison avec ceux de GFS2 pour obtenir une image plus complète des performances du système. En raison du niveau auquel les tracepoints fonctionnent, ils peuvent produire d'importants volumes de données en très peu de temps. Ils sont conçus pour exercer une charge minimale sur le système lorsqu'ils sont activés, mais il est inévitable qu'ils aient un certain effet. Le filtrage des événements par divers moyens peut aider à réduire le volume de données et à se concentrer sur l'obtention des informations utiles à la compréhension d'une situation particulière.

Les points de traçage se trouvent dans le répertoire /sys/kernel/debug/tracing/, à condition que debugfs soit monté à l'emplacement standard du répertoire /sys/kernel/debug. Le sous-répertoire events contient tous les événements de traçage qui peuvent être spécifiés et, à condition que le module gfs2 soit chargé, il y aura un sous-répertoire gfs2 contenant d'autres sous-répertoires, un pour chaque événement GFS2. Le contenu du répertoire /sys/kernel/debug/tracing/events/gfs2 devrait ressembler à peu près à ce qui suit :

[root@chywoon gfs2]# ls
enable            gfs2_bmap       gfs2_glock_queue         gfs2_log_flush
filter            gfs2_demote_rq  gfs2_glock_state_change  gfs2_pin
gfs2_block_alloc  gfs2_glock_put  gfs2_log_blocks          gfs2_promote

Pour activer tous les tracepoints GFS2, entrez la commande suivante :

[root@chywoon gfs2]# echo -n 1 >/sys/kernel/debug/tracing/events/gfs2/enable

Pour activer un point de contrôle spécifique, il existe un fichier enable dans chacun des sous-répertoires d'événements individuels. Il en va de même pour le fichier filter qui peut être utilisé pour définir un filtre d'événement pour chaque événement ou ensemble d'événements. La signification des différents événements est expliquée plus en détail ci-dessous.

La sortie des tracepoints est disponible en format ASCII ou binaire. Cette annexe ne couvre pas actuellement l'interface binaire. L'interface ASCII est disponible de deux manières. Pour obtenir la liste du contenu actuel du tampon circulaire, vous pouvez entrer la commande suivante :

[root@chywoon gfs2]# cat /sys/kernel/debug/tracing/trace

Cette interface est utile lorsque vous utilisez un processus de longue durée pendant un certain temps et que, après un événement, vous souhaitez consulter les dernières informations capturées dans la mémoire tampon. Une autre interface, /sys/kernel/debug/tracing/trace_pipe, peut être utilisée lorsque toutes les données de sortie sont nécessaires. Les événements sont lus dans ce fichier au fur et à mesure qu'ils se produisent ; aucune information historique n'est disponible via cette interface. Le format de sortie est le même pour les deux interfaces et est décrit pour chacun des événements GFS2 dans les sections suivantes de cette annexe.

Un utilitaire appelé trace-cmd est disponible pour lire les données des points de contrôle. Pour plus d'informations sur cet utilitaire, voir http://lwn.net/Articles/341902/. L'utilitaire trace-cmd peut être utilisé de la même manière que l'utilitaire strace, par exemple pour exécuter une commande tout en recueillant des données de traçage à partir de diverses sources.

Pour comprendre GFS2, le concept le plus important, et celui qui le différencie des autres systèmes de fichiers, est celui des glocks. Dans le code source, un glock est une structure de données qui réunit le DLM et la mise en cache en une seule machine à états. Chaque glock a une relation 1:1 avec un seul verrou DLM et fournit un cache pour cet état de verrouillage afin que les opérations répétitives effectuées à partir d'un seul nœud du système de fichiers n'aient pas à appeler le DLM à plusieurs reprises, ce qui permet d'éviter un trafic réseau inutile. Il existe deux grandes catégories de glocks, ceux qui mettent en cache les métadonnées et ceux qui ne le font pas. Les glocks d'inodes et les glocks de groupes de ressources mettent tous deux des métadonnées en cache, tandis que les autres types de glocks ne mettent pas de métadonnées en cache. Le glock inode est également impliqué dans la mise en cache de données en plus des métadonnées et possède la logique la plus complexe de tous les glocks.

Les glocks restent en mémoire jusqu'à ce qu'ils soient déverrouillés (à la demande d'un autre nœud ou de la VM) et qu'il n'y ait plus d'utilisateurs locaux. Ils sont alors retirés de la table de hachage des glocks et libérés. Lorsqu'un glock est créé, le verrou DLM n'est pas immédiatement associé au glock. Le verrou DLM est associé au cadenas lors de la première demande au DLM, et si cette demande aboutit, le drapeau "I" (initial) est activé sur le cadenas. Le tableau "Glock Flags" dans The glock debugfs interface montre la signification des différents drapeaux de glock. Une fois que le DLM a été associé au glock, le verrou DLM restera toujours au moins en mode NL (Null) jusqu'à ce que le glock soit libéré. La rétrogradation du verrou DLM de NL à déverrouillé est toujours la dernière opération dans la vie d'un cadenas.

Chaque glock peut être associé à un certain nombre de "détenteurs", chacun d'entre eux représentant une demande de verrouillage de la part des couches supérieures. Les appels système relatifs à GFS2 mettent en file d'attente et retirent de la file d'attente les détenteurs du glock afin de protéger la section critique du code.

La machine à états de glock est basée sur une file d'attente. Pour des raisons de performance, les tasklets seraient préférables ; cependant, dans l'implémentation actuelle, nous devons soumettre des E/S à partir de ce contexte, ce qui interdit leur utilisation.

Le tableau suivant montre quel état peut être mis en cache dans chacun des modes de verrouillage et si cet état mis en cache peut être sale. Cela s'applique aux verrous d'inodes et de groupes de ressources, bien qu'il n'y ait pas de composant de données pour les verrous de groupes de ressources, seulement des métadonnées.

L'interface glock debugfs permet de visualiser l'état interne des glocks et des détenteurs et comprend également des détails sommaires sur les objets verrouillés dans certains cas. Chaque ligne du fichier commence soit par G : sans indentation (ce qui fait référence au glock lui-même), soit par une lettre différente, indentée d'un seul espace, et faisant référence aux structures associées au glock immédiatement au-dessus d'elle dans le fichier (H : est un support, I : un inode, et R : un groupe de ressources). Voici un exemple de ce que pourrait être le contenu de ce fichier :

G:  s:SH n:5/75320 f:I t:SH d:EX/0 a:0 r:3
 H: s:SH f:EH e:0 p:4466 [postmark] gfs2_inode_lookup+0x14e/0x260 [gfs2]
G:  s:EX n:3/258028 f:yI t:EX d:EX/0 a:3 r:4
 H: s:EX f:tH e:0 p:4466 [postmark] gfs2_inplace_reserve_i+0x177/0x780 [gfs2]
 R: n:258028 f:05 b:22256/22256 i:16800
G:  s:EX n:2/219916 f:yfI t:EX d:EX/0 a:0 r:3
 I: n:75661/219916 t:8 f:0x10 d:0x00000000 s:7522/7522
G:  s:SH n:5/127205 f:I t:SH d:EX/0 a:0 r:3
 H: s:SH f:EH e:0 p:4466 [postmark] gfs2_inode_lookup+0x14e/0x260 [gfs2]
G:  s:EX n:2/50382 f:yfI t:EX d:EX/0 a:0 r:2
G:  s:SH n:5/302519 f:I t:SH d:EX/0 a:0 r:3
 H: s:SH f:EH e:0 p:4466 [postmark] gfs2_inode_lookup+0x14e/0x260 [gfs2]
G:  s:SH n:5/313874 f:I t:SH d:EX/0 a:0 r:3
 H: s:SH f:EH e:0 p:4466 [postmark] gfs2_inode_lookup+0x14e/0x260 [gfs2]
G:  s:SH n:5/271916 f:I t:SH d:EX/0 a:0 r:3
 H: s:SH f:EH e:0 p:4466 [postmark] gfs2_inode_lookup+0x14e/0x260 [gfs2]
G:  s:SH n:5/312732 f:I t:SH d:EX/0 a:0 r:3
 H: s:SH f:EH e:0 p:4466 [postmark] gfs2_inode_lookup+0x14e/0x260 [gfs2]

L'exemple ci-dessus est une série d'extraits (d'un fichier d'environ 18 Mo) générés par la commande cat /sys/kernel/debug/gfs2/unity:myfs/glocks >my.lock lors de l'exécution du test de référence postmark sur un système de fichiers GFS2 à nœud unique. Les glocks de la figure ont été sélectionnés afin de montrer certaines des caractéristiques les plus intéressantes des dumps de glocks.

Les états de verrouillage sont EX (exclusif), DF (différé), SH (partagé) ou UN (déverrouillé). Ces états correspondent directement aux modes de verrouillage DLM, à l'exception de UN qui peut représenter soit l'état de verrouillage DLM nul, soit le fait que GFS2 ne détient pas de verrouillage DLM (en fonction de l'indicateur I, comme expliqué ci-dessus). Le champ s : du glock indique l'état actuel du verrou et le même champ dans le holder indique le mode demandé. Si le verrou est accordé, le détenteur aura le bit H activé dans ses drapeaux (champ f :). Dans le cas contraire, le bit d'attente W est activé.

Le champ n : (numéro) indique le numéro associé à chaque élément. Pour les glocks, il s'agit du numéro de type suivi du numéro de glock. Ainsi, dans l'exemple ci-dessus, le premier glock est n:5/75320, ce qui indique un glock iopen lié à l'inode 75320. Dans le cas des glocks d'inodes et de iopen, le numéro de glock est toujours identique au numéro de bloc de disque de l'inode.

La liste complète de tous les drapeaux, tant pour le détenteur que pour le glock, figure dans le tableau "Glock Flags", ci-dessous, et dans le tableau "Glock Holder Flags", dans la rubrique "Glock holders" ( détenteurs de glock). Le contenu des blocs de valeurs de verrouillage n'est actuellement pas disponible via l'interface glock debugfs.

Le tableau suivant indique la signification des différents types de glock.

L'un des drapeaux les plus importants de glock est le drapeau l (locked). Il s'agit du bit de verrouillage utilisé pour arbitrer l'accès à l'état glock lorsqu'un changement d'état doit être effectué. Il est activé lorsque la machine d'état est sur le point d'envoyer une demande de verrouillage à distance via le DLM, et n'est désactivé que lorsque l'opération complète a été effectuée. Parfois, cela peut signifier que plus d'une demande de verrouillage a été envoyée, avec diverses invalidations se produisant entre-temps.

Le tableau suivant indique la signification des différents drapeaux du glock.

Lorsqu'un rappel à distance est reçu d'un nœud qui souhaite obtenir un verrou dans un mode qui entre en conflit avec celui détenu par le nœud local, l'un ou l'autre des deux drapeaux D (demote) ou d (demote pending) est activé. Afin d'éviter les situations de famine lorsqu'il y a de la contention sur un verrou particulier, chaque verrou se voit attribuer un temps de maintien minimum. Un nœud qui n'a pas encore eu le verrou pendant le temps de maintien minimum est autorisé à conserver ce verrou jusqu'à ce que l'intervalle de temps ait expiré.

Si l'intervalle de temps a expiré, l'indicateur D (demote) est activé et l'état requis est enregistré. Dans ce cas, la prochaine fois qu'il n'y aura pas de verrou accordé dans la file d'attente des détenteurs, le verrou sera rétrogradé. Si l'intervalle de temps n'a pas expiré, l'indicateur d (demote pending) est activé à la place. Cela permet également de programmer la machine à états pour effacer d (demote pending) et définir D (demote) lorsque le temps d'attente minimum a expiré.

L'indicateur I (initial) est activé lorsque le verrou DLM a été attribué au glock. Cela se produit lorsque le glock est utilisé pour la première fois et l'indicateur I reste activé jusqu'à ce que le glock soit finalement libéré (c'est-à-dire que le verrou DLM soit déverrouillé).

Le tableau suivant indique la signification des différents drapeaux du porte-bloc.

Les indicateurs de détenteurs les plus importants sont H (holder) et W (wait), comme indiqué précédemment, puisqu'ils sont activés respectivement sur les demandes de verrou accordées et sur les demandes de verrou en file d'attente. L'ordre des détenteurs dans la liste est important. S'il y a des détenteurs accordés, ils seront toujours en tête de la file d'attente, suivis par les détenteurs en file d'attente.

S'il n'y a pas de titulaire accordé, le premier titulaire de la liste sera celui qui déclenchera le prochain changement d'état. Les demandes de rétrogradation étant toujours considérées comme plus prioritaires que les demandes émanant du système de fichiers, il se peut qu'elles n'entraînent pas directement une modification de l'état demandé.

Le sous-système glock prend en charge deux types de verrous "try". Ceux-ci sont utiles à la fois parce qu'ils permettent de prendre des verrous hors de l'ordre normal (avec un back-off et un retry appropriés) et parce qu'ils peuvent être utilisés pour éviter des ressources utilisées par d'autres nœuds. Le verrou normal t (try) est exactement ce que son nom indique ; c'est un verrou "try" qui ne fait rien de spécial. Le verrou T (try 1CB), quant à lui, est identique au verrou t, à ceci près que le DLM envoie un rappel unique aux détenteurs de verrous incompatibles actuels. Le verrou T (try 1CB) est notamment utilisé avec les verrous iopen, qui servent à arbitrer entre les nœuds lorsque le compte i_nlink d'un inode est nul, et à déterminer lequel des nœuds sera responsable de la désallocation de l'inode. Le verrou iopen est normalement maintenu dans l'état partagé, mais lorsque le compte i_nlink devient nul et que →evict_inode() est appelé, il demande un verrou exclusif avec T (try 1CB). Il continuera à désallouer l'inode si le verrou est accordé. Si le verrou n'est pas accordé, le ou les nœuds qui empêchaient l'octroi du verrou marqueront leur(s) glock(s) du drapeau D (demote), qui est vérifié au moment de →drop_inode() afin de s'assurer que la désallocation n'est pas oubliée.

Cela signifie que les inodes dont le nombre de liens est nul mais qui sont encore ouverts seront désalloués par le nœud sur lequel se produit le dernier close(). De plus, au moment où le nombre de liens de l'inode est décrémenté à zéro, l'inode est marqué comme étant dans l'état spécial d'avoir un nombre de liens nul mais toujours en cours d'utilisation dans la carte bitmap du groupe de ressources. Cela fonctionne comme la liste des orphelins du système de fichiers ext3, en ce sens que cela permet à tout lecteur ultérieur de la carte bitmap de savoir qu'il y a potentiellement de l'espace qui pourrait être récupéré, et d'essayer de le récupérer.

Les tracepoints sont également conçus pour pouvoir confirmer l'exactitude du contrôle du cache en les combinant avec la sortie de blktrace et avec la connaissance de la disposition sur le disque. Il est alors possible de vérifier qu'une E/S donnée a été émise et achevée sous le bon verrou, et qu'il n'y a pas de course.

Le tracepoint gfs2_glock_state_change est le plus important à comprendre. Il suit chaque changement d'état du glock depuis sa création initiale jusqu'à la rétrogradation finale qui se termine par gfs2_glock_put et la transition finale de NL à unlocked (déverrouillé). Le drapeau l (locked) glock est toujours activé avant qu'un changement d'état ne se produise et ne sera effacé qu'une fois celui-ci terminé. Lors d'un changement d'état, il n'y a jamais de détenteurs accordés (drapeau de détenteur de cadenas H). S'il y a des titulaires en file d'attente, ils seront toujours dans l'état W (en attente). Lorsque le changement d'état est terminé, les titulaires peuvent être accordés, ce qui constitue la dernière opération avant l'effacement de l'indicateur l glock.

Le tracepoint gfs2_demote_rq garde la trace des demandes de rétrogradation, qu'elles soient locales ou distantes. En supposant qu'il y ait suffisamment de mémoire sur le nœud, les demandes de rétrogradation locales seront rarement vues, et le plus souvent elles seront créées par umount ou par une récupération occasionnelle de la mémoire. Le nombre de demandes de rétrogradation à distance est une mesure de la concurrence entre les nœuds pour un inode ou un groupe de ressources particulier.

Le point de contrôle gfs2_glock_lock_time fournit des informations sur la durée des requêtes adressées au DLM. L'indicateur de blocage (b) a été introduit dans le glock spécifiquement pour être utilisé en combinaison avec ce point de contrôle.

Lorsqu'un titulaire se voit accorder un verrou, gfs2_promote est appelé, ce qui se produit lors des étapes finales d'un changement d'état ou lorsqu'un verrou est demandé et qu'il peut être accordé immédiatement parce que l'état glock a déjà mis en cache un verrou d'un mode approprié. Si le détenteur est le premier à se voir accorder ce verrou, l'indicateur f (first) est activé sur ce détenteur. Cette fonction n'est actuellement utilisée que par les groupes de ressources.

Le mappage des blocs est une tâche essentielle pour tout système de fichiers. GFS2 utilise un système traditionnel basé sur la cartographie avec deux bits par bloc. L'objectif principal des tracepoints dans ce sous-système est de permettre le contrôle du temps nécessaire à l'allocation et au mappage des blocs.

Le tracepoint gfs2_bmap est appelé deux fois pour chaque opération bmap : une fois au début pour afficher la requête bmap, et une fois à la fin pour afficher le résultat. Il est ainsi facile de faire correspondre les demandes et les résultats et de mesurer le temps nécessaire pour mapper des blocs dans différentes parties du système de fichiers, différents décalages de fichiers ou même différents fichiers. Il est également possible de voir quelles sont les tailles d'étendue moyennes renvoyées par rapport à celles demandées.

Le point de contrôle gfs2_rs suit les réservations de blocs au fur et à mesure de leur création, de leur utilisation et de leur destruction dans l'allocateur de blocs.

Pour garder une trace des blocs alloués, gfs2_block_alloc est appelé non seulement lors des allocations, mais aussi lors de la libération des blocs. Comme les allocations sont toutes référencées en fonction de l'inode auquel le bloc est destiné, il est possible de savoir quels blocs physiques appartiennent à quels fichiers dans un système de fichiers actif. Ceci est particulièrement utile lorsqu'il est combiné avec blktrace, qui montrera les schémas d'E/S problématiques qui peuvent alors être renvoyés aux inodes pertinents en utilisant la cartographie obtenue au moyen de ce tracepoint.

Direct I/O (iomap) est une politique de cache alternative qui permet aux transferts de données de fichiers de se produire directement entre le disque et la mémoire tampon de l'utilisateur. Cela présente des avantages dans les situations où le taux d'atteinte du cache est censé être faible. Les points de trace gfs2_iomap_start et gfs2_iomap_end retracent ces opérations et peuvent être utilisés pour garder une trace du mappage utilisant l'E/S directe, les positions sur le système de fichiers de l'E/S directe ainsi que le type d'opération.

Les tracepoints de ce sous-système suivent les blocs ajoutés et retirés du journal (gfs2_pin), ainsi que le temps nécessaire à la validation des transactions dans le journal (gfs2_log_flush). Cela peut s'avérer très utile pour déboguer les problèmes de performance de la journalisation.

Le point de contrôle gfs2_log_blocks garde la trace des blocs réservés dans le journal, ce qui peut aider à montrer si le journal est trop petit pour la charge de travail, par exemple.

Le point de contrôle gfs2_ail_flush est similaire au point de contrôle gfs2_log_flush dans la mesure où il suit le début et la fin des vidanges de la liste AIL. La liste AIL contient des tampons qui sont passés par le journal, mais qui n'ont pas encore été réécrits à leur place. Elle est périodiquement vidée afin de libérer de l'espace pour le système de fichiers, ou lorsqu'un processus demande un sync ou un fsync.

GFS2 maintient des statistiques qui peuvent aider à suivre ce qui se passe dans le système de fichiers. Cela vous permet de repérer les problèmes de performance.

GFS2 gère deux compteurs :

En outre, GFS2 conserve trois paires moyenne/variance. Les paires moyenne/variance sont des estimations exponentielles lissées et l'algorithme utilisé est celui qui sert à calculer les temps d'aller-retour dans le code du réseau.

Les paires de moyenne et de variance conservées dans GFS2 ne sont pas mises à l'échelle, mais sont exprimées en nanosecondes entières.

Une requête non bloquante est une requête qui se termine immédiatement, quel que soit l'état du verrou DLM en question. Cela signifie actuellement toute demande lorsque (a) l'état actuel du verrou est exclusif (b) l'état demandé est soit nul soit déverrouillé ou (c) l'indicateur "try lock" est activé. Une demande bloquante couvre toutes les autres demandes de verrouillage.

Les temps les plus longs sont meilleurs pour les IRTT, tandis que les temps les plus courts sont meilleurs pour les RTT.

Les statistiques sont conservées dans deux fichiers sysfs:

Pour plus d'informations sur les tracepoints et le fichier GFS2 glocks, voir les ressources suivantes :

Pour fonctionner correctement, le PMDA GFS2 nécessite que le système de fichiers debugfs soit monté. Si le système de fichiers debugfs n'est pas monté, exécutez les commandes suivantes avant d'installer le GFS2 PMDA :

# mkdir /sys/kernel/debug
# mount -t debugfs none /sys/kernel/debug

Le PMDA GFS2 n'est pas activé dans le cadre de l'installation par défaut. Pour utiliser la surveillance métrique de GFS2 via PCP, vous devez l'activer après l'installation.

Exécutez les commandes suivantes pour installer PCP et activer le PMDA GFS2. Notez que le script d'installation du PMDA doit être exécuté en tant que root.

# dnf install pcp pcp-pmda-gfs2
# cd /var/lib/pcp/pmdas/gfs2
# ./Install
Updating the Performance Metrics Name Space (PMNS) ...
Terminate PMDA if already installed ...
Updating the PMCD control file, and notifying PMCD ...
Check gfs2 metrics have appeared ... 346 metrics and 255 values

L'outil pminfo affiche des informations sur les mesures de performance disponibles. Les exemples suivants montrent différentes mesures GFS2 que vous pouvez afficher avec cet outil.

# pminfo -f gfs2.glocks

gfs2.glocks.total
    inst [0 or "afc_cluster:data"] value 43680
    inst [1 or "afc_cluster:bin"] value 2091

gfs2.glocks.shared
    inst [0 or "afc_cluster:data"] value 25
    inst [1 or "afc_cluster:bin"] value 25

gfs2.glocks.unlocked
    inst [0 or "afc_cluster:data"] value 43652
    inst [1 or "afc_cluster:bin"] value 2063

gfs2.glocks.deferred
    inst [0 or "afc_cluster:data"] value 0
    inst [1 or "afc_cluster:bin"] value 0

gfs2.glocks.exclusive
    inst [0 or "afc_cluster:data"] value 3
    inst [1 or "afc_cluster:bin"] value 3

# pminfo -f gfs2.glstats

gfs2.glstats.total
    inst [0 or "afc_cluster:data"] value 43680
    inst [1 or "afc_cluster:bin"] value 2091

gfs2.glstats.trans
    inst [0 or "afc_cluster:data"] value 3
    inst [1 or "afc_cluster:bin"] value 3

gfs2.glstats.inode
    inst [0 or "afc_cluster:data"] value 17
    inst [1 or "afc_cluster:bin"] value 17

gfs2.glstats.rgrp
    inst [0 or "afc_cluster:data"] value 43642
    inst [1 or "afc_cluster:bin"] value 2053

gfs2.glstats.meta
    inst [0 or "afc_cluster:data"] value 1
    inst [1 or "afc_cluster:bin"] value 1

gfs2.glstats.iopen
    inst [0 or "afc_cluster:data"] value 16
    inst [1 or "afc_cluster:bin"] value 16

gfs2.glstats.flock
    inst [0 or "afc_cluster:data"] value 0
    inst [1 or "afc_cluster:bin"] value 0

gfs2.glstats.quota
    inst [0 or "afc_cluster:data"] value 0
    inst [1 or "afc_cluster:bin"] value 0

gfs2.glstats.journal
    inst [0 or "afc_cluster:data"] value 1
    inst [1 or "afc_cluster:bin"] value 1

# pminfo -f gfs2.holders.flags.wait

gfs2.holders.flags.wait
    inst [0 or "afc_cluster:data"] value 0
    inst [1 or "afc_cluster:bin"] value 0

# pmstore gfs2.control.tracepoints.all 1
gfs2.control.tracepoints.all old value=0 new value=1

# pminfo -f gfs2.latency.grant.all gfs2.latency.demote.all

gfs2.latency.grant.all
    inst [0 or "afc_cluster:data"] value 0
    inst [1 or "afc_cluster:bin"] value 0

gfs2.latency.demote.all
    inst [0 or "afc_cluster:data"] value 0
    inst [1 or "afc_cluster:bin"] value 0

# pminfo -f gfs2.latency.grant.all gfs2.latency.demote.all

gfs2.tracepoints.promote.other.null_lock
     inst [0 or "afc_cluster:data"] value 0
     inst [1 or "afc_cluster:bin"] value 0

gfs2.tracepoints.promote.other.concurrent_read
     inst [0 or "afc_cluster:data"] value 0
     inst [1 or "afc_cluster:bin"] value 0

gfs2.tracepoints.promote.other.concurrent_write
     inst [0 or "afc_cluster:data"] value 0
     inst [1 or "afc_cluster:bin"] value 0

gfs2.tracepoints.promote.other.protected_read
     inst [0 or "afc_cluster:data"] value 0
     inst [1 or "afc_cluster:bin"] value 0

gfs2.tracepoints.promote.other.protected_write
     inst [0 or "afc_cluster:data"] value 0
     inst [1 or "afc_cluster:bin"] value 0

gfs2.tracepoints.promote.other.exclusive
     inst [0 or "afc_cluster:data"] value 0
     inst [1 or "afc_cluster:bin"] value 0

# pminfo -f gfs2.tracepoints.demote_rq.requested

gfs2.tracepoints.demote_rq.requested.remote
     inst [0 or "afc_cluster:data"] value 0
     inst [1 or "afc_cluster:bin"] value 0

gfs2.tracepoints.demote_rq.requested.local
     inst [0 or "afc_cluster:data"] value 0
     inst [1 or "afc_cluster:bin"] value 0

# pminfo -f gfs2.tracepoints.log_flush.total]

gfs2.tracepoints.log_flush.total
     inst [0 or "afc_cluster:data"] value 0
     inst [1 or "afc_cluster:bin"] value 0

Le tableau suivant décrit la liste complète des mesures de performance fournies par le paquetage pcp-pmda-gfs2 pour les systèmes de fichiers GFS2.

Cette procédure décrit les instructions à suivre pour installer une configuration PCP minimale afin de collecter des statistiques sur Red Hat Enterprise Linux. Cette configuration implique l'ajout du nombre minimum de paquets sur un système de production nécessaire pour collecter des données en vue d'une analyse ultérieure.

L'archive tar.gz de la sortie pmlogger qui en résulte peut être analysée à l'aide d'autres outils PCP et comparée à d'autres sources d'informations sur les performances.