Red Hat Training

A Red Hat training course is available for Red Hat Enterprise Linux

GFS 2

Red Hat Enterprise Linux 6

Red Hat Global File System 2

Édition 7

Résumé

Cet ouvrage fournit des informations sur la configuration et la maintenance de GFS2 (Red Hat Global File System 2) pour Red Hat Enterprise Linux 6.

Introduction

Ce manuel fournit des informations sur la configuration et la maintenance de Red Hat GFS2 (Red Hat Global File System 2), inclus dans le module complémentaire Resilient Storage.

1. Audience

Cet ouvrage est principalement destiné aux administrateurs de système Linux qui sont familiarisés avec les activités suivantes :
  • Les procédures d'administration de système Linux, y compris la configuration du noyau
  • L'installation et la configuration des réseaux de mémoire partagée, comme Fibre Channel SAN

3. Nous avons besoin de vos commentaires !

Si vous trouvez une erreur de typographie dans ce manuel, ou si vous pensez à une façon de l'améliorer, faîtes-nous en part ! Veuillez soumettre un rapport dans Bugzilla : http://bugzilla.redhat.com/ en face du produit Red Hat Enterprise Linux 6 et du composant doc-Global_File_System_2. Quand vous soumettez un rapport de bogue, n'oubliez pas de mentionner le numéro d'identification du manuel : rh-gfs2(EN)-6 (2011-05-19T15:15).
Si vous pouvez nous faire des suggestions sur la manière d'améliorer la documentation, essayez d'être aussi spécifique que possible dans vos descriptions. Si vous avez trouvé une erreur, indiquer le numéro de section et le texte avoisinant de façon à ce que nous puissions la retrouver facilement.

Chapitre 1. Présentation générale de GFS2

Le système de fichiers GFS2 se trouve dans le module complémentaire Resilient Storage. Il s'agit d'un système de fichiers qui fait directement l'interface avec le système de fichiers du noyau Linux (couche VFS). Lorsqu'il est implémenté en tant que système de fichiers de cluster,GFS2 emploie des métadonnées distribuées et plusieurs journaux. Red Hatsupporte l'utilisation de systèmes de fichiers GFS2 seulement tels qu'ils sont implémentés dans le module complémentaire High Availability.

Note

Malgré que le système de fichiers GFS2 puisse être mis en place dans un système autonome ou en tant que partie d'une configuration de cluster, pour la version Red Hat Enterprise Linux 6, Red Hat ne prend plus en charge l'utilisation de GFS2 en tant que système de fichiers à nœud simple. Red Hat ne prend pas en charge un certain nombre de systèmes de fichiers à nœud simple de haute-performance, qui sont optimisés pour une utilisation en nœud simple, et qui ont donc, en général, des temps système inférieurs par rapport à un système de fichiers clusterisé. Red Hat recommande que vous utilisiez ces systèmes de fichiers de préférence par rapport aux systèmes GFS2 si vous n'avez besoin que d'un seul nœud pour monter le système de fichiers.
Red Hat continuera de prendre en charge les systèmes de fichiers GSF2 en single-node pour monter des instantanés de systèmes de fichiers clusterisés (par exemple, pour les sauvegardes).

Note

Red Hat ne prend pas en charge l'utilisation de GFS2 pour les déploiements de systèmes de fichiers supérieurs à 16 nœuds.
GFS2 est basé sur une architecture de 64-bit, qui peut, en théorie, accommoder un système de fichiers de 8 EB. La taille maximum prise en charge de système de fichiers GFS2 est de 100 To pour du matériel 64-bit. Cependant, la taille maximum actuellement prise en charge de système de fichiers GFS2 est de 16 To pour du matériel 32-bit. Si votre système requiert des systèmes de fichiers GFS2 plus larges, contacter votre représentant de service Red Hat.
Quand vous déterminerez la taille de votre système de fichiers, considérez vos besoins de recouvrement. Exécutez la commande fsck.gfs2 sur un système très large peut prendre longtemps et consommer beaucoup de mémoire. De plus, en cas de défaillance d'un disque ou d'un sous-système de disque, le temps de récupération est limité par la vitesse de votre media de sauvegarde. Pour toute information sur le montant de mémoire requis pour la commande fsck.gfs2, voir Section 3.11, « Réparer un système de fichiers ».
Quand ils sont configurés dans un cluster, les nœuds GFS2 de Red Hat peuvent être configurés et gérés par des outils de gestion et de configuration High Availability Add-On. Red Hat GFS2 fournit alors le partage des données entre les nœuds GFS2 d'un cluster, avec affichage unique de l'espace-nom du système de fichiers à travers les nœuds GFS2. Cela permet aux process qui se trouvent sur des nœuds différents de partager des fichiers GFS2 de la même façon que les process d'un même nœud peuvent partager des fichiers sur un système de fichiers local, sans aucune différence discernable. Pour obtenir des informations sur le module complémentaire High Availability, voir Configurer et gérer un cluster dans Red Hat.
Malgré le fait qu'un système de fichiers GFS2 puisse être utilisé en dehors de LVM, Red Hat supporte seulement les systèmes de fichiers qui ont été créés sur un volume logique CLVM. CLVM est inclus dans le module complémentaire Resilient Storage. Il s'agit d'une implémentation niveau-cluster de LVM, activée par le démon CLVM clvmd, qui gère les volumes logiques d'un cluster. Le démon facilite l'utilisation de LVM2 pour gérer les volumes logiques à travers un cluster, permettant ainsi à tous les nœuds d'un cluster de partager les volumes logiques. Pour obtenir des informations sur le gestionnaire de volumes LVM, voir Administration des gestionnaires de volumes logiques.
Le module de noyau gfs2.ko implémente le système de fichiers GFS2 et est chargé dans les nœuds de cluster GFS2.

Note

Quand vous configurez un système de fichiers GFS2 dans un système de fichiers de cluster, vous devez veiller à ce que tous les nœuds du cluster aient accès aux zones de stockage en commun. Les configurations de cluster asymétriques dans lesquelles certains nœuds ont accès au stockage partagé et pas d'autres, ne sont pas prises en charge. Cela ne signifie pas que tous les nœuds puissent monter le système de fichiers.
Ce chapitre fournit des informations de base, simplifiées de fond pour vous aider à comprendre GFS2. Il comprend les sections suivantes:

1.1. Fonctionnalités nouvelles ou modifiées

Cette section liste les fonctionnalités nouvelles ou modifiées du système de fichiers GFS2 et la documentation GFS2 incluse dans les versions initiale et suivantes dans Red Hat Enterprise Linux 6.

1.1.1. Fonctionnalités nouvelles ou modifiées dans Red Hat Enterprise Linux 6.0

Red Hat Enterprise Linux 6.0 inclut la documentation suivante et les modifications ou mises à jour de fonctionnalités suivantes :
  • Dans Red Hat Enterprise Linux 6, Red Hat ne prend plus en charge l'utilisation de GFS2 en tant que système de fichiers en nœud simple.
  • Dans Red Hat Enterprise Linux 6, la commande gfs2_convert pour passer du système de fichiers GFS à GFS2 a été amélioré. Pour obtenir davantage d'informations sur cette commande, voir Annexe B, Convertir un système de fichier de GFS vers GFS2.
  • Red Hat Enterprise Linux 6 prend en charge les options de montage discard, nodiscard, barrier, nobarrier, quota_quantum, statfs_quantum, et statfs_percent. Pour obtenir davantage d'informations sur le montage d'un système de fichiers GFS2, voir Section 3.2, « Monter un système de fichiers ».
  • La version Red Hat Enterprise Linux 6 de ce document contient une nouvelle section, Section 1.4, « GFS2 Node Locking ». Cette section décrit les systèmes de fichiers GFS2 de l'intérieur.

1.1.2. Fonctionnalités nouvelles ou modifiées dans Red Hat Enterprise Linux 6.1

Red Hat Enterprise Linux 6.1 inclut la documentation suivante et les modifications ou mises à jour de fonctionnalités suivantes :

1.2. Avant d'installer GFS2

Avant que vous installiez et configuriez GFS2, prenez note des caractéristiques principales suivantes de vos systèmes de fichiers GFS2:
Noeuds GFS2
Détermine les nœuds de montage des systèmes de fichiers GFS2 dans le cluster.
Nombre de systèmes de fichiers
Déterminez combien de systèmes de fichiers GFS2 doivent être créés au départ. (davantage de systèmes de fichiers peuvent être ajoutés par la suite.)
Nom du système de fichier
Détermine un nom unique pour chaque système de fichiers. Le nom doit être unique pour tous les systèmes de fichiers lock_dlm à travers le cluster. Chaque nom de système de fichiers devra être sous forme de variable de paramètre. Par exemple, cet ouvrage utilise les noms de systèmes de fichiers mydata1 et mydata2 dans certains exemples de procédures.
Journaux
Déterminer le nombre de journaux pour vos systèmes de fichiers GFS2. Un journal estrequis pour chaque nœud qui monte un système de fichiers GFS2. GFS2vous permet d'ajouter dynamiquement des journaux un peu plus tard quand des serveurs supplémentaires montent un système de fichiers. Pour plus d'informations sur l'ajout de journaux à un système de fichier GFS2, voir Section 3.7, « Ajouter les journaux au système de fichiers ».
Périphériques de stockage de mémoire et partitions
Déterminez les périphériques de stockage de mémoire et les partitions à utiliser pour créer des volumes logiques (via CLVM) au sein du système de fichiers.

Note

Vous pourrez constater des problèmes de performance avec GFS2 lorsque les opérations créer et supprimer sont émises depuis plus d'un nœud dans le même répertoire et en même temps. Si cela provoque des problèmes de performances de votre système, vous devezlocaliser la création du fichier et les suppressions par un nœud vers les répertoires spécifiques àce nœud autant que possible.

1.3. Différences entre GFS et GFS2

Cette section liste les améliorations et les changements de GFS2 par rapport à GFS.
Pour migrer de GFS à GFS2, vous devrez convertir vos systèmes de fichiers GFS en GFS2 par la fonction gfs2_convert. Pour davantage d'informations sur le sujet, consulter Annexe B, Convertir un système de fichier de GFS vers GFS2.

1.3.1. Noms des commandes GFS2

En général, la fonctionnalité de GFS2 est identique à celle de GFS. Les noms des commandes de systèmes, cependant, mentionnent GFS2 au lieu de GFS. Tableau 1.1, « Les commandes GFS et GFS2 » montre les équivalences entre les commandes GFS et GFS2.

Tableau 1.1. Les commandes GFS et GFS2

Commande GFS Commande GFS2 Description
mount mount Monte un système de fichier. Le système détermine si le système de fichiers est de type GFS ou GFS2. Pour davantage d'informations sur les options de montage GFS2, voir la page man gfs2_mount(8).
umount umount Démonter un système de fichiers
fsck
gfs_fsck
fsck
fsck.gfs2
Vérifier et réparer un système de fichiers démonté.
gfs_grow gfs2_grow Agrandir un système de fichiers monté
gfs_jadd gfs2_jadd Ajouter un journal à un système de fichiers monté
gfs_mkfs
mkfs -t gfs
mkfs.gfs2
mkfs -t gfs2
Créer un système de fichiers sur un périphérique de stockage de données.
gfs_quota gfs2_quota Gèrer les quota sur un système de fichiers monté.
gfs_tool gfs2_tool Configurer, accorder, ou collecter des informations sur un système de fichier.
gfs_edit gfs2_edit Afficher, imprimer, ou éditer les structures internes du système de fichier. La commandegfs2_edit peut être utilisée pour les systèmes de fichiers GFS ou pour le système de fichiers GFS2.
gfs_tool setflag jdata/inherit_jdata chattr +j (à préférer) Active la journalisation sur fichier ou répertoire.
setfacl/getfacl setfacl/getfacl Définir ou obtenir les listes de contrôle d'accès (ACL) pour un fichier ou un répertoire.
setfattr/getfattr setfattr/getfattr Définir ou obtenir les attributs étendus d'un fichier.
Pour obtenir une liste complète des options supportées par les commandes du système de fichiers GFS2, voir les pages man de ces commandes.

1.3.2. Différences supplémentaires entre GFS et GFS2

Cette section résume les différences supplémentaires entre l'administration GFS et GFS2 qui n'est pas décrite dans Section 1.3.1, « Noms des commandes GFS2 ».

Noms d'acheminement contexte-dépendants

Les systèmes de fichiers GFS2 ne fournissent pas de support pour les noms d'emplacements contexte-dépendants (CPDNs), ce qui vous permet de créer les liens symboliques qui mènent à des destinations multiples de fichiers et de répertoires. Pour cette fonction dans GFS2, vous pouvez utiliser l'option bind de la commande mount. Pour obtenir davantage d'informations sur les points de montage de liaison ou sur les noms de chemins d'accès dépendants du contexte dans GFS2, voir Section 3.12, « Noms de chemins Contexte-dépendants et Montage associés ».

Module gfs2.ko

Le module de noyau qui implémente le système de fichiers GFS est gfs.ko. Le module de noyau qui implémente le système de fichiers GFS2 est gfs2.ko.

Activer la mise à exécution des quota dans GFS2

Dans les systèmes de fichier GFS2, l'exécution des quotas est désactivée par défaut et doit être activée explicitement. Pour obtenir des informations sur l'activation ou la désactivation des quotas, voir Section 3.5, « Gestion des Quotas GFS2 ».

Journalisation des données

Les systèmes de fichiers GFS2 supportent la commande chattr pour définir ou effacer le drapeau j sur un fichier ou sur un répertoire. Définir le drapeau +j sur un fichier a pour effet d'activer la journalisation des données sur ce fichier. Définir le drapeau +j sur un répertoire se traduit "inherit jdata", c'est à dire que tous les fichiers et répertoires créés par la suite dans ce répertoire seront journalisés. La meilleure façon d'activer ou se désactiver la journalisation des données sur un fichier est en utilisant la commande chattr.

Ajouter les journaux dynamiquement

Dans les systèmes de fichiers GFS, les journaux sont des métadonnées intégrées qui existent en dehors du système de fichiers, ce qui nécessite d'étendre la taille du volume logique qui contient le système de fichiers avant d'y ajouter des journaux. Dans les systèmes de fichiers GFS2, les journaux peuvent être ajoutés dynamiquement au fur et à mesure que les serveurs supplémentaires montent un système de fichiers, tant qu'il reste de l'espace dans le système de fichiers pour ces fichiers supplémentaires. Pour plus d'informations sur le rajout de journaux dans le système de fichiers GFS2, voir Section 3.7, « Ajouter les journaux au système de fichiers ».

paramètre atime_quantum retiré

Le système de fichiers GFS2 ne prend pas en charge le paramètre réglable atime_quantum, qui peut être utilisé par le système de fichiers GFS pour spécifier la fréquence des mises à jour de atime. Au lieu de cela, GFS@ supporte les options de montage relatime et noatime. L'option de montage relatime est recommandée pour conseillée pour obtenir un comportement similaire comme si on définissait le paramètre atime_quantum dans GFS.

data= option de la commande de montage

Quand vous montez les systèmes de fichiers GFS2, vous pouvez spécifier l'option data=ordered ou data=writeback de la commande mount. Quand data=ordered est défini, les données utilisateur qui ont été modifiées par une transaction sont vidées dans le disque avant que la transaction soit validée sur le disque. Cela devrait empêcher l'utilisateur de voir les blocs non initialisés dans un fichier suite à une mise en échec. Quand data=writeback est défini, les données utilisateur sont inscrites sur le disque à n'importe quel moment après avoir été souillées. Cela n'apporte pas la même garantie d'homogénéité que le mode ordered, mais devrait être plus légèrement plus rapide pour certaines charges de travail. La valeur par défaut correspond au mode ordered mode.

La commande gfs2_tool

La commande gfs2_tool supporte un ensemble d'options distinct pour GFS2, différent de ce que la commande gfs_tool supporte pour GFS :
  • La commande gfs2_tool supporte un paramètre journals qui imprime des informations sur les journaux configurés actuellement, y compris de nombreux journaux contenus dans le système de fichiers.
  • La commande gfs2_tool ne supporte pas le drapeau counters, que la commande gfs_tool utilise pour afficher les statistiques de GFS.
  • La commande gfs2_tool ne supporte pas le drapeau inherit_jdata. Pour marquer une répertoire comme "inherit jdata", il faudra définir le drapeau jdata sur le répertoire ou bine, vous pourrez utiliser la commande chattr pour définir le drapeau +j sur le répertoire. La commande chattr est la meilleure façon d'activer ou de désactiver la journalisation des données sur un fichier.

La commande gfs2_edit

La commande gfs2_edit supporte un ensemble d'options distinct pour GFS2 par rapport à la commande gfs_edit utilisée pour GFS. Pour obtenir des informations sur les options spécifiques supportées par chaque version de la commande, voir les pages man gfs2_edit et gfs_edit.

1.3.3. Améliorations de performance GFS2

Il existe plusieurs fonctionnalités dans les systèmes de fichiers GFS2 qui ne résultent pas en une différence entre les systèmes de fichiers GFS dans l'interface utilisateur, mais qui contribuent à améliorer la performance du système.
Un système de fichiers GFS2 offre les améliorations de performance de systèmes de fichiers suivantes :
  • Meilleure performance pour les utilisations intenses au sein d'un répertoire unique.
  • Opérations E/S synchronisées plus rapides
  • Lectures cache plus rapides (pas de surcharge de système imputable au verrouillage)
  • Direct E/S plus rapides pour les fichiers préalloués (dans la mesure où la taille des E/S est suffisamment importante, soient des blocs de 4M)
  • Opérations E/S plus rapides en général
  • L'exécution de la commande df est bien plus rapide, à cause de la plus grande rapidité d'exécution des appels statfs.
  • Le mode atime a été amélioré pour réduire le nombre d'opérations E/S d'écriture générées par atime si on compare avec GFS.
Les systèmes de fichiers GFS2 fournissent un support plus conventionnel et plus large des façons suivantes :
  • GFS2 fait partie du noyau en amont (intégré dans 2.6.19).
  • GFS2 supporte les caractéristiques suivantes :
    • Les attributs SELinux étendus.
    • la configuration des attributs lsattr() et chattr() par les appels standard () ioctl
    • horodatage en nanosecondes
Un système de fichiers GFS2 offre les améliorations suivantes au niveau de l'efficacité interne d'un système de fichier.
  • GFS2 utilise moins de mémoire de noyau
  • GFS2 ne requiert pas de numéros de génération de métadonnées.
    L'allocation de métadonnées GFS2 ne requiert pas de lectures. Les copies des blocs de métadonnées dans des journaux multiples sont gérés par des blocs d'annulation (revoking blocks) du journal avant verrouillage.
  • GFS2 comprend un gestionnaire log qui n'est pas familiarisé avec les changements de quota ou les inodes non reliées.
  • Les commandes gfs2_grow et gfs2_jadd utilisent le verrouillage pour éviter que plusieurs entités soient actionnées même temps.
  • Le code ACL a été simplifié pour les commandes creat() et mkdir().
  • Les inodes non liés, les changements de quota et les changements statfs sont récupérés sans avoir besoin de remonter le journal.

1.4. GFS2 Node Locking

Afin d'obtenir la meilleure performance possible d'un système de fichier GFS2, il est trèsimportant de comprendre la théorie de base de son fonctionnement. Un système de fichiers à nœud simple est installé le long d'un cache. L'objet estd'éliminer le temps de latence d'accès au disque lorsque vous utilisez des données fréquemment demandées.Dans Linux, le cache de page (et historiquement le cache des tampons) fournit cettefonction de mise en cache.
Avec GFS2. chaque nœud a son propre cache de page qui peut contenir certaines portions des données sur-disque. GFS2 utilise le mécanisme de verrouillage nommé glocks (qui se prononce J-Lok) pour conserver l'intégrité du cache entre les nœuds. Le sous-système glock fournit une fonction de gestion de cache qui repose sur DLM distributed lock manager (gestionnaire du verrouillage distribué) , en tant que couche de communication sous-jacente.
Les glocks garantissent une protection pour le cache sur la base-inode, donc il y a un verrou par inode qui est utilisé pour contrôler la couche de mise en cache. Si le glock est octroyé en mode partagé (mode de verrouillage DLM), alors les données qui se trouvent sous ce glock pourront être mises en cache sur un ou plusieurs nœuds à la fois, de façon à ce que les nœuds puissent avoir un accès local aux données.
Si le glock est octroyé en mode exclusif (mode de verrouillage DLM : EX), alors un seul nœud peut mettre les données en cache sous ce glock. Ce mode est utilisé par toutes les opérations qui modifient les données (comme write d'appel de système).
Si un autre nœud demande un glock qui ne peut pas être octroyé immédiatement, alors le DLM enverra un message au nœud ou aux nœuds qui contiennent actuellement les glocks bloquant la nouvelle demande, pour leur demander d'abandonner leurs verrous. Abandonner les glocks peut être un long processus (aux standards de la plupart les opérations de systèmes de fichiers). Pour abandonner un glock partagé, vous devrez simplement invalider le cache, ce qui est relativement rapide proportionnellement à la quantité de données mises en cache.
Pour abandonner un glock exclusif, vous devrez vider un journal, et inscrire à nouveau toutes les données modifiées dans le disque, suivies par l'invalidation comme pour le glock partagé.
La différence entre un système de fichiers à nœud simple et GFS2, c'est qu'un système de fichiers à nœud simple ne possède qu'un seul cache et GFS2 possède un cache séparé sur chaque nœud. Dans les deux cas, la latence d'accès aux données mises en cache est du même ordre de magnitude, mais la latence pour accéder à des données non mises en cache est bien plus élevée dans GFS2 si un autre nœud a déjà mis ces mêmes données en cache.

Note

Compte tenue la façon dont la mise en cache GFS2 opère, on obtient de meilleurs résultats avec une des actions suivantes :
  • L'inode est utilisée en mode lecture seulement dans tous les nœuds.
  • Une inode est écrite ou modifiée à partir d'un seul nœud uniquement.
Notez que l'insertion ou la suppression d'entrées d'un répertoire pendant la création d'un fichier comptent comme une écriture sur l'inode du répertoire.
Il est possible de ne pas respecter cette règle si ce n'est pas trop fréquemment. Si vous ignorez cette règle, la performance s'en ressentira.
Si vous mmap() un fichier sur GFS2 avec un mappage lecture/écriture, mais que vous ne faîtes que de lire, cela ne comptera uniquement que comme une lecture. Mais sur GFS, cela compte en tant qu'écriture, donc GFS2 est bien plus adaptable avec la commande mmap() I/O.
Si vous n'installez pas les paramètres noatime mount, alors les lectures vont également résulter en écritures pour mettre les horodatages de fichiers à jour. Nous recommandons que tous les utilisateurs GFS2 montent leurs fichiers avec noatime à moins que pour des raisons particulières, vous ayez besoin de atime.

1.4.1. Réglage de la performance avec GFS2

Il est normalement possible d'altérer la façon dont une application, qui peut causer des problèmes, stocke ses données pour obtenir un avantage considérable de performance.
Un serveur email est un exemple typique d'application compliquée qui peut causer problème. Ils sont souvent situés dans un répertoire spool qui contient des fichiers pour chaque utilisateur (mbox), ou avec un répertoire pour chaque utilisateur contenant un fichier pour chaque message (maildir). Quand les requêtes arrivent par IMAP, l'arrangement idéal est de donner à chaque utilisateur une affinité à un nœud particulier. Ainsi, les requêtes d'affichage ou de suppression de messages email seront plutôt servies par le cache sur ce nœud en particulier. Évidemment, si ce nœud échoue, alors la session pourra être redémarrée sur un nœud différent.
Quand le courrier arrive par SMTP, alors les nœuds individuels sont configurés pour pouvoir faire passer le courrier d'un utilisateur à un nœud particulier par défaut. Si le nœud par défaut n'est pas activé, alors le message sera sauvegardé directement dans le pool de courrier de l'utilisateur par le nœud récipient. Ce concept est destiné à conserver certains groupes de fichiers en cache sur un seul nœud normalement, mais de permettre un accès direct en cas d'échec.
Cette configuration permet la meilleure utilisation possible du cache de page de GSF2, et rendent les échecs transparents dans l'application, soit en imap ou en smtp.
La sauvegarde est souvent problématique. Si possible, il est largement préférable de sauvegarder les charges de travail de chaque nœud directement plutôt du nœud qui met en cache ce groupe d'inodes particulier. Si vous possédez un script de sauvegarde qui exécute à un moment précis, et que ce moment semble coïncider avec une Spike dans le temps de réponse d'une application s'exécutant sur GFS2, alors, il y a une bonne chance que le cluster ne profite pas efficacement du cache de page.
De toute évidence, si vous êtes dans la position (enviable) de pouvoir stopper l'application pour pouvoir faire une sauvegarde, alors ce ne sera pas un problème. Mais, si la sauvegarde n'est exécutée que sur un seul nœud, alors une fois complétée, une grande portion du système sera mis en cache sur ce nœud, accompagné d'un pénalité de performance pour les accès ultérieurs d'autres nœuds. Cela peut être mitigé, dans une certaine mesure, si vous mettez le cache de page VFS dans le nœud de sauvegarde après que la sauvegarde soit terminée, à l'aide de la commande suivante :
echo -n 3 >/proc/sys/vm/drop_caches
Ce n'est cependant pas une solution aussi satisfaisante que de faire attention à ce que la charge de travail de chaque nœud soit partagée, en lecture à travers le cluster, ou accessible largement à partir d'un simple nœud.

1.4.2. Réglage de la performance GFS2 par le Lump Dock GFS2

Si la performance de votre cluster souffre de la mauvaise utilisation de la mise en cache GFS2, vous observerez sans doute des temps d'attente I/O augmenter. Vous pouvez utiliser les informations de vidage de verrou (lock dump) de GFS2 pour trouver quelle est la cause du problème.
On peut trouver l'information de vidage de verrou (lock dump) dans le fichier debugfs situé sur le chemin d'accès suivant, en assumant que debugfs soit monté sur /sys/kernel/debug/:
/sys/kernel/debug/gfs2/fsname/glocks
Le contenu de ce fichier se présente sous une série de lignes. Chaque ligne qui commence par G: représente un glock, et les lignes suivantes, en retrait d'un espace unique, représentent un élément d'information concernant le glock qui se trouve sous leurs yeux dans le fichier.
La meilleure façon d'utiliser le fichier debugfs est d'utiliser la commande cat pour en extraire une copie de tout le fichier (cela peut prendre un moment si vous possédez beaucoup de RAM et d'inodes mises en cache) quand l'application rencontre des problèmes, et regarder les résultats un peu plus tard.

Note

Il peut être utile de faire deux copies du fichier debugfs, quelques secondes, voire une minute ou deux l'une de l'autre. En comparant les informations des deux demandes de traçage se rapportant au même numéro de glock, vous saurez si la charge de travail progresse (c'est à dire qu'elle est juste ralentie) ou si elle a été bloquée (ce qui correspondrait toujours à un bogue et devrait être signalé au support Red Hat immédiatement).
Les lignes du fichier debugfs qui commencent par H: (holders) représentent des demandes de verrouillage accordées, ou en attente d'être accordée. Le champ indicateur des détenteurs (holders) ligne f: montre quel : drapeau « W » fait référence à une attente de demande, le drapeau « H » fait référence à une demande accordée. Les glocks qui ontun grand nombre de demandes d'attente sont sans doute ceux qui ont un problème de contentieux particulier.
Tableau 1.2, « Indicateurs glock » explique ce que signifient les différents indicateurs glock et Tableau 1.3, « Marqueurs de détenteurs de glock » explique ce qui signifient les différents indicateurs de marqueurs glock.

Tableau 1.2. Indicateurs glock

Marqueur Nom Signification
d Abaissement de niveau en attente Une requête (distante) abaissée d'un niveau différée
D Régression Requête de régression (locale ou distante)
f Log flush Le journal doit être validé avant de produire ce glock
F Frozen (gelé) Les réponses en provenance de nœuds distants sont ignorées - recouvrement en progrès
i Invalidation en cours En cours d'invalidation des pages sous ce glock
I Initial Activé quand le verrou DLM est associé à ce glock
l Verrouillé Le glock est en cours de changer d'état
p Régression en progrès Le glock est entrain de répondre à la demande de régression
r Réponse en attente Réponse reçue d'un nœud distant en attente de traitement
y Dirty Les données ont besoin d'être vidées dans le disque avant de libérer ce glock

Tableau 1.3. Marqueurs de détenteurs de glock

Marqueur Nom Signification
a Async N'attendez pas le résultat glock (cherchera le résultat plus tard)
A Any Tout mode de verrouillage compatible est acceptable
c No cache Si déverrouillé, abaisser d'un niveau le verrou DLM immédiatement
e Pas d'expiration Ignore les requêtes d'annulation de verrous à venir
E exact Doit posséder un mode de verrouillage exact
F First Défini quand le détenteur est le premier à obtenir ce verrou
H Holder (détenteur) Indique que le verrou demandé a été octroyé
p Priorité Mettez le détenteur (holder) en début de file d'attente
t Try Un verrou "try"
T Try 1CB Un verrou "lock" qui envoie un rappel
W Wait Définir en attendant qu'une requête soit complétée
Si vous identifiez un glock qui pose problème, l'étape suivante consiste à trouver à quel inode il se rapporte. Le numéro de glock (n: sur la ligne G: ) l'indique. Vous le trouverez sous la forme type/numéro et si type correspond à 2, alors le numéro est un numéro d'inode. Pour retrouver l'inode, vous pourrez exécuter find -inum nombre avec le nombre correspondant au numéro d'inode converti du format hexadécimal du fichier de glocks en décimale.

Note

Si vous exécutez la commande find sur un système de fichiers quand il expérimente des problèmes de conflit de verrouillage, vous risquez d'aggraver le problème. Il serait judicieux de stopper l'application avant d'exécuter la commande find quand vous cherchez des inodes en conflit.
Tableau 1.4, « Types de glock » indique ce que signifient les différents types de glock.

Tableau 1.4. Types de glock

Nombre de types Type de verrou Utilisation
1 Trans Verrou de transaction
2 Inode données et métadonnées d'inode
3 Rgrp Métadonnées de groupe de ressources
4 Meta Superblock
5 Iopen Dernière détection de l'inode (et la plus proche)
6 Flock flock(2) syscall
8 Quota Opérations de quota
9 Journal Journal mutex
Si le glock qui a été identifié était d'un type différent, il est sans doute de type 3: (groupe de ressources). Si vous voyez un nombre significatif deprocessus en attente pour d'autres types de glock sous charge normale, alors veuillez le rapporter au Support Red Hat.
Si vous voyez un certain nombre de demandes d'attente en file d'attente sur un verrou de groupe ressources, il peut y avoir un certain nombre de raisons pour cela. L'une d'entre elles, c'est qu'il y a un grandnombre de nœuds par rapport au nombre de groupes de ressources dans le fichiersystème. Une autre raison, c'est que le système de fichiers peut être presque complet (nécessitant,en moyenne, des recherches plus longues pour trouver des blocs libres). La situation, dans les deux cas,peut être améliorée en ajoutant plus de stockage et en utilisant la commande gfs2_grow pour étendre le système de fichier.

Chapitre 2. Guide de démarrage

Ce chapitre décrit les procédures nécessaires à l'installation initiale de GFS2 et comprend les sections suivantes :

2.1. Tâches préliminaires

Avant d'installer Red Hat GFS2, notez bien les caractéristiques clé des nœuds GSF2 (consulter Section 1.2, « Avant d'installer GFS2 »). Aussi, veillez à ce que les horloges soient synchronisées sur les nœuds GFS2. Il est recommandé d'utiliser le logiciel NTP (Network Time Protocol) fourni dans votre distribution Red Hat Enterprise Linux.

Note

Les horloges de système des nœuds GFS2 doivent être synchronisées à quelques minutes prêt, afin d'éviter toute mise à jour inutile de l'horodateur de l'inode. Toute mise à jour inutile de l'horodateur de l'inode aura un effet néfaste important sur le niveau de performance du cluster.

2.2. Tâches d'installation initiales

L'installation initiale GFS2 consiste aux tâches suivantes :
  1. Installation des volumes logiques.
  2. Création d'un système de fichiers GFS2.
  3. Montage des systèmes de fichiers.
Suivre ces étapes pour installer GFS2 au départ.
  1. A l'aide de LVM, créer un volume logique pour chaque système de fichiers GFS2 Red Hat.

    Note

    Vous pouvez utiliser les scripts init.d inclus dans la suite Red Hat Cluster Suite pour automatiser l'activation et pour désactiver les volumes logiques. Pour davantage d'informations sur les scripts init.d, veuillez vous référer à Configurer et Gérer un Cluster Red Hat.
  2. Créer des systèmes de fichiers GFS2 sur les volumes logiques créés au cours de la première étape. Choisissez un nom unique pour chaque système de fichier. Pour plus d'informations sur la création d'un système de fichiers GFS2, consulter Section 3.1, « Créer un système de fichier ».
    Vous pouvez utiliser n'importe lequel des formats suivants pour créer un système de fichiers GFS2 clusterisé :
    mkfs.gfs2 -p lock_dlm -t ClusterName:FSName -j NumberJournals BlockDevice
    mkfs -t gfs2 -p lock_dlm -t LockTableName -j NumberJournals BlockDevice
    Pour obtenir plus d'informations sur la création de systèmes de fichiers GFS2, consulter Section 3.1, « Créer un système de fichier »
  3. À chaque nœud, montez les systèmes de fichiers GFS2. Pour obtenir plus d'informations sur le montage d'un système de fichiers, consulter Section 3.2, « Monter un système de fichiers ».
    Utilisation des commandes :
    mount BlockDevice MountPoint
    mount -o acl BlockDevice MountPoint
    La commande -oacl permet la manipulation des ACL (Access Control List) de fichiers. Si un système de fichiers est monté sans l'option de montage acl-o, les utilisateurs sont autorisés à voir les ACL (avec getfacl), mais ne sont pas autorisés à les modifier (avec setfacl).

    Note

    Vous pouvez utiliser les scripts init.d inclus dans le module complémentaire High Availability de Red Hat pour automatiser le montage et pouvoir libérer les systèmes de fichiers GFS2.

2.3. Déployer un groupement GFS2

Le déploiement d'un système de fichiers clusterisé n'est pas un simple "drop in" (remplacement) d'un déploiement de nœud unique. Nous vous conseillons de prévoir 8 à 12 semaines de test sur les nouvelles installations pour pouvoir tester le système et veiller à ce qu'il opère au niveau de performance qui convient. Pendant ce temps, tout problème fonctionnel ou de performance peut être résolu, et les questions peuvent être soumises à l'équipe de support de Red Hat. Nous recommandons également que les clients qui souhaitent déployer des groupements aient leurs configurations vérifiées par l'équipe de support de Red Hat avant tout déploiement, afin d'éviter tout problème de support possible à venir.

Chapitre 3. Gérer GFS2

Ce chapitre décrit les tâches et les commandes pour gérer GFS2 et comprend les sections suivantes:

3.1. Créer un système de fichier

Vous créez un système de fichiers avec la commande mkfs.gfs2. Vous pouvez utiliser la commande mkfs avec l'option -t gfs2 spécifiée. Le système de fichier sera créé sur un volume LVM activé. Les informations suivantes sont requises pour exécuter la commande mkfs.gfs2 :
  • Nom d'un protocole/module de verrouillage (le protocole de verrouillage d'un cluster est lock_dlm)
  • Nom d'un cluster (opérant dans le cadre d'une configuration groupée)
  • Nombre de journaux (un journal est requis pour chaque nœud susceptible d'être monté dans le système de fichiers)
Quand vous créez un système de fichiers GFS2, vous pouvez utiliser la commande mkfs.gfs2 directement, ou bien vous pouvez utiliser la commande mkfs avec le paramètre -t spécifiant un système de fichiers de type gfs2, suivi des options de système de fichier GFS2.

Note

Une fois que vous aurez créé un système de fichiers GFS2 avec la commande mkfs.gfs2, vous ne pourrez pas diminuer la taille du système de fichiers. Vous pourrez, cependant, augmenter la taille d'un système de fichier existant par la commande gfs2_grow, comme expliqué dans Section 3.6, « Agrandir un système de fichiers ».

Utilisation

Quand vous créez un système de fichiers GFS2 clusterisé, vous pouvez utiliser un des formats suivants :
mkfs.gfs2 -p LockProtoName -t LockTableName -j NumberJournals BlockDevice
mkfs -t gfs2 -p LockProtoName -t LockTableName -j NumberJournals BlockDevice
Quand vous créez un système de fichier GFS2 local, vous pouvez utiliser un des formats suivants :

Note

Dans Red Hat Enterprise Linux 6, Red Hat ne prend pas en charge l'utilisation de GFS2 en tant que système de fichiers en nœud simple.
mkfs.gfs2 -p LockProtoName -j NumberJournals BlockDevice
mkfs -t gfs2 -p LockProtoName -j NumberJournals BlockDevice

Avertissement

Assurez-vous d'être bien familiarisés avec l'utilisation des paramètres LockProtoName et LockTableName. La mauvaise utilisation des paramètres LockProtoName et LockTableName pourrait entraîner la corruption du système de fichiers ou de l'espace verrouillé.
LockProtoName
Préciser le nom du protocole de verrouillage à utiliser. Le protocole de verrouillage à utiliser pour un cluster est lock_dlm.
LockTableName
Ce paramètre est précisé dans le système de fichiers GFS2 dans une configuration groupée. Ce paramètre est composé de deux parties séparées par deux points (sans espace) comme suit :ClusterName:FSName
  • ClusterName, nom du cluster pour lequel le système de fichiers GFS2 a été créé.
  • FSName, le nom du système de fichiers peut comporter de 1 à 16 caractères de long, et son nom doit être unique parmi tous les noms de systèmes de fichiers lock_dlm au sein du cluster, et pour tous les systèmes de fichiers (lock_dlm et lock_nolock) sur chaque nœud local.
Number
Précise le nombre de journaux à créer dans la commande mkfs.gfs2. Un journal est requis pour chaque nœud qui monte le système de fichiers. Pour les systèmes de fichiers GFS2, vous pouvez ajouter des journaux supplémentaires par la suite sans pour autant augmenter la taille du système de fichiers, comme vous le montre Section 3.7, « Ajouter les journaux au système de fichiers ».
BlockDevice
Précise un volume physique ou logique.

Exemples

Dans cet exemple, lock_dlm est le protocole de verrouillage utilisé par le système de fichiers, puisqu'il s'agit d'un système de fichiers clusterisé. Le nom du cluster est alpha, et le nom du système de fichiers est mydata1. Le système de fichiers contient huit journaux et est créé dans /dev/vg01/lvol0.
mkfs.gfs2 -p lock_dlm -t alpha:mydata1 -j 8 /dev/vg01/lvol0
mkfs -t gfs2 -p lock_dlm -t alpha:mydata1 -j 8 /dev/vg01/lvol0
Dans ces exemples, un second système de fichiers lock_dlm est créé, et peut être utilisé dans le groupement alpha. Le nom du système de fichiers est mydata2. Le système de fichiers contient huit journaux et est créé dans /dev/vg01/lvol1.
mkfs.gfs2 -p lock_dlm -t alpha:mydata2 -j 8 /dev/vg01/lvol1
mkfs -t gfs2 -p lock_dlm -t alpha:mydata2 -j 8 /dev/vg01/lvol1

Toutes Options

Tableau 3.1, « Options de commande: mkfs.gfs2 » décrit les options de commande mkfs.gfs2 (marqueurs et paramètres).

Tableau 3.1. Options de commande: mkfs.gfs2

Marqueur Paramètre Description
-c Mégaoctets Configurez la taille initiale des fichiers de changement de quotas pour chaque journal en Mégaoctets.
-D Active la sortie de débogage.
-h Help. Affiche les options disponibles.
-J Mégaoctets Précise la taille du journal en mégaoctets. La taille d'un journal par défaut est de 128 mégaoctets. La taille minimum est de 8 mégaoctets. Les journaux de plus grande taille améliorent la performance, quoiqu'ils utilisent plus de mémoire que les petits journaux.
-j Number Précise le nombre de journaux à créer dans la commande mkfs.gfs2. Un journal est requis pour chaque nœud qui monte le système de fichiers. Si cette option n'est pas spécifiée, un seul journal sera créé. Pour les systèmes de fichiers GFS2, vous pouvez ajouter des journaux supplémentaires par la suite sans pour autant augmenter la taille du système de fichiers.
-O Évite que la commande mkfs.gfs2 ne demande une confirmation avant d'écrire le système de fichiers.
-p LockProtoName
Précise le nom du protocole de verrouillage à utiliser. Les protocoles de verrouillage reconnus sont :
lock_dlm — Le module standard de verrouillage requis pour un système de fichiers groupés.
lock_nolock — utilisé quand GFS2 agit en tant que système de fichiers local (un seul nœud).
-q Repos. N'affiche rien.
-r Mégaoctets Spécifie la taille des groupes de ressources en mégaoctets. La taille de groupe de ressource minimum est de 32 Mo. La taille maximale de groupe de ressources est 2048 Mo. Une grandetaille de groupe de ressources peut améliorer les performances sur les systèmes de fichiers très volumineux. Si ce n'est pas spécifié, mkfs.gfs2 choisit la taille du groupe de ressources sur la base de la taille du système de fichiers : les systèmes de fichiers de taille moyenne auront des groupes de ressources de 256 MB et les systèmes de fichiers plus gros auront des RG plus gros afin d'obtenir une meilleure performance.
-t LockTableName
Un identifiant unique qui précise le champ de la table de verrouillage lorsque vous utilisez le protocolelock_dlm; le protocolelock_nolock n'utilise pas ce paramètre.
Ce paramètre comporte deux points de séparation (sans espace) comme suit: ClusterName:FSName.
ClusterName est le nom du cluster pour lequel le système de fichiers GFS2 a été créé; seuls les membres de ce cluster ont le droit d'utiliser ce système de fichiers. Le nom du cluster est défini dans le fichier /etc/cluster/cluster.conf via Cluster Configuration Tool et affiché dans Cluster Status Tool dans le GUI de gestion des clusters de Red Hat Cluster Suite.
FSName, le nom du système de fichiers peut comporter de 1 à 16 caractères de long, et son nom doit être unique parmi tous les noms de systèmes de fichiers au sein du cluster.
-u Mégaoctets Précise la taille initiale de chaque fichier d'étiquettes non relié pour chaque journal.
-V Affiche l'information version de commande.

3.2. Monter un système de fichiers

Avant de monter un système de fichiers, le système de fichiers doit exister (voir Section 3.1, « Créer un système de fichier »), vous devez activer le volume dans lequel se trouve le système de fichiers, et le groupement de support et les systèmes de verrouillage doivent avoir été démarrés (voir Configurer et gérer un cluster Red Hat). Une fois que toutes ces conditions ont été remplies, vous pourrez monter votre système de fichiers GFS2 à la manière de tout autre système de fichiers.

Note

Les tentatives de montage de systèmes de fichiers GFS2 quand le Cluster Manager (cman) n'a pas été démarré produisent le message d'erreur suivant :
[root@gfs-a24c-01 ~]# mount -t gfs2 -o noatime /dev/mapper/mpathap1 /mnt
gfs_controld join connect error: Connection refused
error mounting lockproto lock_dlm
Pour manipuler les ACL de fichiers, vous devez monter le système de fichiers à l'aide de 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 à voir les ACL (avec getfacl), mais ne sont pas autorisés à les configurer (avec setfacl).

Utilisation

Monter sans manipulations ACL
mount BlockDevice MountPoint
Monter avec manipulations ACL
mount -o acl BlockDevice MountPoint
-o acl
option spécifique-GFS2 autorisant la manipulation de fichiers ACL.
BlockDevice
Précise le périphérique en mode bloc où le système de fichiers GFS2 se situe.
MountPoint
Précise le répertoire où le système de fichiers GFS2 devrait être monté.

Exemple

Dans cet exemple, le système de fichiers GFS2 de /dev/vg01/lvol0 est monté sur le répertoire /mygfs2.
mount /dev/vg01/lvol0 /mygfs2

Utilisation totale

mount BlockDevice MountPoint -o option
L'argument -o option se compose d'options propres à GFS2 (voir Tableau 3.2, « Options de montage spécifiques-GFS2 ») ou des options acceptables selon les standards d'option de Linux mount -o options, ou un mélange des deux. Les paramètres multiples d'option sont séparés par une virgule, sans espaces.

Note

La commande mount est une commande du système Linux. En plus d'utiliser les options spécifiques-GFS2 décrites dans cette section, vous pouvez utiliser d'autres options standards, mount (comme par exemple, -r). Pour davantage d'informations sur les options de commandes Linuxmount, se référer à la page man mount.
Tableau 3.2, « Options de montage spécifiques-GFS2 » décrit les valeurs disponibles de -o option spécifiques GFS2, qui sont passées à GFS2 au moment du montage.

Note

Ce tableau comprend des descriptions d'options qui sont utilisées avec les systèmes de fichiers locaux uniquement. Notez, cependant, que dans Red Hat Enterprise Linux 6, Red Hat ne supporte pas l'utilisation de GFS2 à nœudsimple. Red Hat continuera à soutenir les systèmes de fichiers GFS2 à nœud unique pour le montage des instantanés de systèmes de fichiers de cluster (par exemple, pour des fins de sauvegarde).

Tableau 3.2. Options de montage spécifiques-GFS2

Option Description
acl Permet la manipulation des ACL (Access Control List) de fichiers. Si un système de fichiers est monté sans l'option de montage acl les utilisateurs sont autorisés à voir les ACL (avec getfacl), mais ne sont pas autorisés à les modifier (avec setfacl).
data=[ordered|writeback] Lorsque data=ordered est défini, les données d'utilisateur modifiées par unetransaction sont évacuées vers le disque avant que l'opération soit validée sur ledisque. Cela devrait empêcher l'utilisateur de voir les blocs non initialisés dans unfichier après un crash. Quand le mode data=writeback est défini, les données d'utilisateur sont écrites sur le disque après que le disque ait été souillé. Cela nefournit pas la même garantie de cohérence qu'en mode ordered, mais il devrait être légèrement plus rapide pour certaines charges de travail. La valeur par défautest le mode ordered.
ignore_local_fs
Attention: cette option ne devrait pas être utilisée quand les systèmes de fichiers GFS2 sont partagés.
Oblige GFS2 à traiter le système de fichiers comme un système de fichiers multi-hôtes. Le marqueur localflocks est automatiquement activé par lock_nolock.
localflocks
Attention : cette option ne devrait pas être utilisée quand les systèmes de fichiers GFS2 sont partagés.
Indique au GFS2 de laisser la couche VFS (Virtual File Sytem) effectuer 'flock et fcntl.' Le marqueur localflocks est automatiquement activé par lock_nolock.
lockproto=LockModuleName Permet à l'utilisateur de préciser quel protocole de verrouillage utiliser dans le système de fichiers. Si LockModuleName n'est pas précisé, le nom du protocole de verrouillage est lu par le superbloc du système de fichiers.
locktable=LockTableName Permet à l'utilisateur de spécifier quelle table de verrouillage utiliser dans le système de fichiers.
quota=[off/account/on] Active/désactive les quotas pour un système de fichiers donné. Indiquer que les quotas soient dans account amène les statistiques d'utilisation par UID/GID à être correctement maintenus dans le système de fichiers, les valeurs limites ou d'avertissement sont ignorées. La valeur par défaut est off.
errors=panic|withdraw Quand errors=panic est spécifié, les erreurs de système de fichiers vont créer une panique de noyau. Le comportement par défaut, qui revient à spécifier errors=withdraw, consiste à retirer (withdraw) le système du système de fichiers et à le rendre inaccessible jusqu'au prochain démarrage; dans certains cas, le système est toujours en cours d'exécution. Pour obtenir des informations sur la fonction 'withdraw', voir Section 3.14, « La fonctionnalité GFS2 Withdraw ».
discard/nodiscard Entraîne GFS2 à générer des demandes I/O de blocs qui ont été libérées. Elles peuvent être utilisées par du matériel particulier pour les allocations dynamiques ou systèmes semblables.
barrier/nobarrier Entraîne GFS2 à émettre des barrières I/O au moment du vidage du journal. La valeur par défaut est on. Cette option est automatiquement fermée off si le périphérique sous-jacent ne supporte pas les barrières I/O. Il est hautement recommandé d'utiliser GFS2 à tout instant, à moins que le dispositif de blocs soit conçu de façon à ne pas pouvoir perdre son contenu de cache en écriture (par exemple, si en UPS ou s'il n'a pas de cache en écriture).
quota_quantum=secs Définit le nombre de secondes pour lesquels un changement dans les informations de quotas peutrester sur un nœud avant d'être écrites dans le fichier de quotas. C'est lavoie privilégiée pour définir ce paramètre. La valeur est un nombre entier desecondes supérieures à zéro. La valeur par défaut est de 60 secondes. Les valeurs moindresentraînent des mises à jour plus rapides des lazy quotas et une moindre probabilitéde dépasser son quota. Les valeurs élevées rendent les opérations impliquant des quotas, plus rapides et plus efficaces.
statfs_quantum=secs Paramétrer statfs_quantum à 0 est la meilleure façon de configurer la version lente de statfs. La valeur par défaut est de 30s, ce qui fixe la durée maximum avant que les changements de statfs soient synchronisés dans le fichier statfs du master. On peut l'ajuster pour accueillir des valeurs de statfs plus rapides et moins précises. Quand cette option est fixée à 0, statfs rapportera toujours les valeurs réelles.
statfs_percent=value Procure une limite au changement de pourcentage d'information maximum de statfs sur une base locale, avant d'être à nouveau synchronisé dans le fichier du master, même si le délai a expiré. Si le paramètre de statfs_quantum est 0, alors cette configuration sera ignorée.

3.3. Démonter un système de fichiers

Le système de fichiers GFS2 peut être démonté de la même manière que n'importe quel système de fichiers Linux, en utilisant la commande umount.

Note

La commande umount est une commande de système Linux . Des informations sur cette commande peuvent être trouvées dans les pages man de la commande Linux umount.

Utilisation

umount MountPoint
MountPoint
Précise le répertoire où le système de fichiers GFS2 est monté actuellement.

3.4. Considérations spéciales à prendre en compte lorsqu'on monte des systèmes de fichiers GFS2

Les systèmes de fichiers GFS2, qui ont été installés manuellement plutôt qu'automatiquementgrâce à une entrée dans le fichier fstab, ne seront pas connus du système quand les systèmes de fichiers sont démontés à l'arrêt du système. En conséquence,le script GFS2 ne démontera pas le système de fichiers GFS2. Après que lescript d'arrêt du système soit exécuté, le processus de fermeture standard tue tous les processus d'utilisateur restants, y compris l'infrastructure du cluster et tente de démonter le système de fichiers. Cette opération échouera sans l'infrastructure du cluster et le système sera suspendu.
Pour empêcher le système d'être suspendu quand les systèmes de fichiers sont démontés, vous devrez soit :
  • Utiliser une entrée dans le fichier fstab pour monter le système de fichiers GFS2.
  • Si un système de fichiers a été monté manuellement par la commande mount, veillez à démonter le système de fichiers manuellement par la commande umount avant de redémarrer ou de fermer le système.
Si votre système est suspendu au moment du démontage pendant la fermeture du système dans ces conditions, redémarrez le système. Vous ne perdrez sans doute aucune données puisque le système de fichiers a déjà été synchronisé pendant le processus de fermeture.

3.5. Gestion des Quotas GFS2

Les quotas des systèmes de fichiers sont utilisés pour limiter le montant d'espace qu'un utilisateur ou une groupe d'utilisateurs peut emprunter dans un système de fichiers. Un groupe ou utilisateur ne possède pas de limite de quotas avant qu'il ait été défini. Quand un système de fichiers GFS2 est monté par l'option quota=on ou quota=account, GFS2 enregistre l'espace de chaque usager ou groupe, même lorsque l'espace est illimité. GFS2 met à jour les informations sur les quotas de manière transactionnelle de façon à ce que les systèmes d'utilisation de quotas n'aient pas besoin d'être reconstruits en cas de crash du système.
Pour éviter un ralentissement de la performance, un nœud GFS2 synchronise les mises à jour dans le fichier de quotas périodiquement. Le signal "fuzzy" permet aux utilisateurs ou groupes d'excéder légèrement leur limite. En vue de minimiser cet effet, GFS2 réduit la période de synchronisation dynamique au fur et à mesure que la "hard" limite de quotas approche.

Note

Dans Red Hat Enterprise Linux 6.1, GFS2 prend en charge les fonctionnalités de quotas standard de Linux. Pour en bénéficier, vous devrez installer le RPM quota. C'est la meilleure façon d'administrer les quotas sur GFS2 et devra être utilisée pour tous les nouveaux déploiements de GFS2 qui utilisent les quotas. Cette section documente la gestion des quotas GFS2 par ces fonctionnalités.
Dans les versions plus anciennes de Red Hat Enterprise Linux, GFS2 a besoin de la commande gfs2_quota pour gérer les quotas. Pour obtenir des informations sur la commande gfs2_quota, voir Annexe A, Gestion des quotas GFS2 par la commande gfs2_quota.

3.5.1. Configurer les quotas de disque

Pour fixer les quotas de disque, procédez aux étapes suivantes :
  1. Définir les quotas en mode "enforcement" ou "accounting".
  2. Initialiser la base de données de quota par des informations d'utilisation de blocs courantes.
  3. Indiquer les politiques de quota. (en mode "accounting", ces politiques ne sont pas respectées.)
Chaque étape sera discutée en détails dans les sections suivantes :

3.5.1.1. Configurer les quota en mode "enforcement" ou "accounting" (calcul des quotas)

Dans les systèmes de fichiers GFS2, le contrôle des quota est désactivé par défaut. Pour activer le contrôle des quotas pour un système de fichiers, monter le système de fichiers avec l'option quota=on spécifiée.
Il est possible d'enregistrer l'utilisation du disque et de mettre en place un système de calcul de quota pour chaque utilisateur ou chaque groupe sans avoir à forcer les valeurs fermes ou d'avertissement. Dans ce but, monter le système de fichiers avec l'option quota=account spécifiée.
Utilisation
Pour monter un système de fichiers avec le contrôle de quotas activé, monter le système de fichiers avec l'option quota=on spécifiée.
mount -o quota=on BlockDevice MountPoint
Pour monter un système de fichiers avec le contrôle de quotas désactivé, même si les limites ne sont pas contrôlées, monter le système de fichiers avec l'option quota=account spécifiée.
mount -o quota=account BlockDevice MountPoint
Pour monter un système de fichiers avec le contrôle de quotas désactivé, monter le système de fichiers avec l'option quota=off spécifiée. C'est la configuration par défaut.
mount -o quota=off BlockDevice MountPoint
quota={on|off|account}
on - précise que les quotas sont activés quand le système de fichiers est monté.
off - précise que les quotas sont désactivés quand le système de fichiers est monté.
account -précise que les statistiques d'utilisation d'un groupe ou d'un utilisateur sont maintenues dans le système de fichiers, même si les limites de quotas ne sont pas appliquées.
BlockDevice
Précise le périphérique en mode bloc où le système de fichiers GFS2 se situe.
MountPoint
Précise le répertoire où le système de fichiers GFS2 devrait être monté.
Exemples
Dans cet exemple, le système de fichiers GFS2 de /dev/vg01/lvol0 est monté sur le répertoire /mygfs2 avec les quotas activés.
mount -o quota=on /dev/vg01/lvol0 /mygfs2
Dans cet exemple, le système de fichiers GFS2 de /dev/vg01/lvol0 est monté sur le répertoire /mygfs2 avec les quotas "accounting" maintenus, mais non appliqués.
mount -o quota=account /dev/vg01/lvol0 /mygfs2

3.5.1.2. Créer les fichiers de base de données de quotas

Après que chaque système de fichier soit monté, pourvu de ses quotas, le système est capable de fonctionner avec des quotas de disques. Cependant, le système de fichiers lui-même n'est pas prêt à prendre en charge les quotas. L'étape suivante consiste à exécuter la commande quotacheck.
La commande quotacheck examine les systèmes de fichiers avec quotas activés, et construit une table de l'utilisation actuelle du disque par système de fichiers. Le tableau est alors utilisé pour mettre à jour la copie d'utilisation du disque du système d'exploitation. De plus, les fichiers de quotas de disque du système sont mis à jour.
Pour créer les fichiers de quotas sur le système de fichiers, utiliser l'option -u et les options -g de la commande quotacheck; ces deux options doivent être spécifiées pour que les quotas de groupe et d'utilisateur puissent être initialisés. Par exemple, si les quotas sont activés pour le système de fichiers home, créez les fichiers pour le répertoire /home :
quotacheck -ug /home

3.5.1.3. Allouer les quotas par utilisateur

La dernière étape consiste à assigner les quotas de disque par la commande edquota. Notez que si vous avez monté votre système de fichiers en mode "accounting" (avec l'option quota=account), les quotas ne sont pas appliqués.
Pour configurer le quota pour l'utilisateur, en tant que root, utiliser la commande suivante :
edquota username
Procédez à cette étape pour chaque utilisateur qui a besoin d'un quota. Ainsi, si un quota est activé dans /etc/fstab pour la partition /home (/dev/VolGroup00/LogVol02 dans l'exemple ci-dessous) et que la commande edquota testuser est exécutée, vous verrez ce qui suit dans l'éditeur configuré par défaut dans le système :
Disk quotas for user testuser (uid 501):   
Filesystem                blocks     soft     hard    inodes   soft   hard
/dev/VolGroup00/LogVol02  440436        0        0

Note

L'éditeur de texte défini par la variable d'environnement EDITOR est utilisé par edquota. Pour changer l'éditeur, définir la variable d'environnement EDITOR dans votre fichier ~/.bash_profile vers le chemin d'accès de l'éditeur de votre choix.
La première colonne correspond au nom du système de fichiers qui contient un quota activé. La seconde colonne montre combien de blocs l'utilisateur utilise actuellement. Les deux colonnes suivantes sont utilisées pour fixer des limites de soft ou hard blocs pour l'utilisateur sur son système de fichiers.
La limite de soft bloc détermine le montant maximum de d'espace disque pouvant être utilisé.
La limite hard bloc correspond au montant maximum d'espace disque qu'un utilisateur ou un groupe peuvent utiliser. Une fois que la limite est atteinte, on ne peut pas utiliser d'espace supplémentaire.
Le système de fichiers GFS2 ne conserve pas les quotas pour les inodes, donc ces colonnes ne s'appliquent pas aux systèmes de fichiers GFS2 et seront vides.
Si une valeur est fixée à 0, cette limite n'est pas définie. Dans l'éditeur de texte, changer les limites qui vous souhaitez. Ainsi :
Disk quotas for user testuser (uid 501):   
Filesystem                blocks     soft     hard    inodes   soft   hard
/dev/VolGroup00/LogVol02  440436   500000   550000
Pour vous assurer que le quota utilisateur a bien été défini, utiliser la commande :
quota testuser

3.5.1.4. Assigner les quotas par groupe

Les quotas peuvent aussi être assignés sur la base d'un groupe. Notez que si vous avez monté votre système de fichiers en mode 'accounting' (avec account=on), les quotas ne seront pas appliqués.
Pour définir un quota de groupe pour le groupe devel (le groupe doit pouvoir exister avant que vous puissiez définir le quota de groupe), utiliser la commande suivante :
edquota -g devel
Cette commande affiche le quota existant pour le groupe dans l'éditeur de texte :
Disk quotas for group devel (gid 505):   
Filesystem                blocks    soft     hard    inodes   soft   hard
/dev/VolGroup00/LogVol02  440400       0        0
Le système de fichiers GFS2 ne maintient pas de quotas pour les inodes, donc ces colonnes ne s'appliquent pas aux systèmes de fichiers GFS2 et resteront vides. Modifier ces limites, puis sauvegardez le fichier.
Pour vérifier que le quota de groupe a bien été défini, utiliser la commande suivante :
quota -g devel

3.5.2. Gérer les quotas de disque

Si les quotas sont mis en œuvre, ils devront être maintenus, surtout sous une forme qui permette de voir si les quotas sont dépassés et de vérifier qu'ils soient exacts.
Bien entendu, si les utilisateurs dépassent constamment leur quota ou leur limite, un administrateur de système aura un choix limité suivant le type d'utilisateur ou suivant l'impact de l'espace disque sur leur travail. L'administrateur pourra soit aider l'utilisateur à déterminer comment utiliser moins d'espace disque ou augmenter le quota de disque de l'utilisateur.
Vous pouvez créer un rapport d'utilisation de disque en exécutant l'utilitaire repquota. Ainsi, la commande repquota /home produit cette sortie :
*** 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 un rapport d'utilisation de disque pour tous les systèmes de fichiers dont les quotas sont activés (-a), utiliser la commande suivante :
repquota -a
Le rapport d'activité est relativement facile à lire, mais nous devons vous expliquer quelques points. Le -- affiché après chaque utilisateur est une façon rapide de déterminer si les limites de blocs ont été dépassés. Si la soft limite a été dépassée, un + apparaîtra à la place du premier - dans la sortie. Le second - indique la limite de l'inode, mais les systèmes de fichiers GFS2 ne supportent pas les limites d'inode, donc conserve -. Les systèmes de fichiers GFS2 ne supportent pas la période de grace, donc la colonne grace reste vide.
Notez que la commande repquota n'est pas supportée avec NFS, quel que soit le système de fichiers sous-jacent.

3.5.3. Contrôler l'exactitude des quotas

Si vous activez les quota sur votre système de fichiers au bout d'un certain temps, après avoir exécuté sans quotas, vous devrez exécuter la commande quotacheck pour créer, vérifier, et réparer les fichiers de quota. De plus, vous souhaiterez sans doute exécuter la commande quotacheck si vous pensez que vos fichiers de quotas ne sont pas exacts, ce qui peut se produire quand un système de fichiers est pas démonté nettement, suite à un crash de système.
Pour obtenir davantage d'informations sur la commande quotacheck, voir la page man quotacheck.

Note

Exécutez quotacheck quand le système est relativement calme sur tous les nœuds, car l'activité du disque risque de rejeter les valeurs de quota calculées.

3.5.4. Synchroniser les quota par la commande quotasync

GFS2 abrite les informations sur les quotas au sein de son propre fichier interne situé sur le disque. Un nœud GFS2 ne met pas ce fichier quota à jour pour chaque écriture de système de fichier; plutôt, il procède à la mise à jour toutes les 60 secondes. Ceci est nécessaire pour éviter toute contention entre les nœuds qui s'inscrivent sur le fichier de quotas, ce qui entraînerait un ralentissement de la performance.
Au fur et à mesure qu'un utilisateur ou un groupe approche sa limite de quota, GFS2 réduit, de façon dynamique, le temps de mise à jour entre ses fichiers-quota, afin d'éviter de dépasser la limite. La période normale entre les synchronisations est un paramètre accordable, quota_quantum, et peut être changé en utilisant la commande gfs2_tool. La période par défaut est de 60 secondes. Aussi, le paramètre quota_quantum doit être déterminé sur chaque nœud et à chaque fois que le système de fichiers est monté. (les changements de paramètres quota_quantum ne sont pas persistants entre les démontages.)
Vous pouvez utiliser la commande quotasync pour synchroniser l'information de quotas d'un nœud sur un fichier de quotas sur-disque entre les mises à jour automatiques effectuées par GFS2.

Utilisation

Synchronisation des informations sur les quotas
quotasync [-ug] -a|mntpnt...
u
Sync les fichiers de quotas d'utilisateur.
g
Sync les fichiers de quotas de groupe
a
Sync tous les systèmes de fichiers dont les quotas sont actuellement activés et qui supportent la sync. Si -a n'est pas défini, un point de montage de système devra être spécifié.
mntpnt
Précise le système de fichiers GFS2 pour lequel les actions s'appliquent.
Réglage du système entre les synchronisations
gfs2_tool settune MountPoint quota_quantum Seconds
MountPoint
Précise le système de fichiers GFS2 pour lequel les actions s'appliquent.
Seconds
Précise la nouvelle période entre les synchronisations de fichiers-quota ordinaires par GFS2. Des valeurs moindres peuvent augmenter la contention et ralentir la performance.

Exemples

Cet exemple synchronise l'information sur les quotas dirty mis en cache du nœud dont il dépend vers le fichier de quotas sur-disque pour le système de fichiers /mnt/mygfs2.
# quotasync -ug /mnt/mygfs2
Cet exemple change la période par défaut entre les mises à jour de fichiers-quotas ordinaires à une heure (3600 secondes) pour le système de fichiers /mygfs2 sur un nœud unique.
gfs2_tool settune /mnt/mygfs2 quota_quantum 3600

3.5.5. Références

Pour obtenir plus d'informations sur les quotas de disques, voir les pages man de commandes suivantes :
  • quotacheck
  • edquota
  • repquota
  • quota

3.6. Agrandir un système de fichiers

La commande gfs2_grow est utilisée pour agrandir le système de fichiers GFS2 après que le périphérique où se situe le système de fichiers ait été agrandi. Exécuter la commande gfs2_grow sur un système de fichiers GFS2 existant remplit tout l'espace qui reste entre le bout du système de fichiers courant et le bout du périphérique qui contient l'extension nouvellement initialisée du système de fichiers. Lorsque l'opération de remplissage est terminée, l'index de ressource du système de fichiers est mis à jour. Tous les nœuds du groupement peuvent alors utiliser l'espace supplémentaire généré.
La commande gfs2_grow doit être exécutée sur un système de fichiers montés, mais n'a seulement besoin d'être exécutée que sur un nœud du cluster. Tous les autres nœuds peuvent alors percevoir que l'agrandissement a eu lieu et peuvent utiliser ce nouvel espace libre automatiquement.

Note

Une fois que vous avez créé un système de fichiers GFS2 par la commande mkfs.gfs2, vous ne pourrez pas diminuer la taille du système de fichiers.

Utilisation

gfs2_grow MountPoint
MountPoint
Précise le système de fichiers GFS2 pour lequel les actions s'appliquent.

Commentaires

Avant d'exécuter la commande gfs2_grow :
  • Sauvegardez vos données importantes sur le système de fichiers.
  • Déterminer le volume utilisé par le système de fichiers à agrandir en exécutant la commande df MountPoint.
  • Augmenter le volume du cluster sous-jacent par LMV. Pour davantage d'information sur la façon d'administrer les volumes LVM, voir LVM Administrator's Guide
Après avoir exécuté la commande gfs2_grow, exécuter la commande df pour vérifier que l'espace libéré est maintenant disponible dans le système de fichiers.

Exemples

Dans cet exemple, le système de fichiers de répertoire /mygfs2fs est agrandi.
[root@dash-01 ~]# gfs2_grow /mygfs2fs
FS: Mount Point: /mygfs2fs
FS: Device:      /dev/mapper/gfs2testvg-gfs2testlv
FS: Size:        524288 (0x80000)
FS: RG size:     65533 (0xfffd)
DEV: Size:       655360 (0xa0000)
The file system grew by 512MB.
gfs2_grow complete.

Utilisation totale

gfs2_grow [Options] {MountPoint | Device} [MountPoint | Device]

MountPoint
Précise le répertoire où le système de fichiers GFS2 est monté.
Device
Précise le nœud du périphérique du système de fichiers.
Tableau 3.3, « Options spécifiques-GFS2 disponibles en cours d'agrandissement d'un système de fichiers » décrit les options spécifiques à GSF2 qui peuvent être utilisées quand on agrandit un système de fichiers GFS2.

Tableau 3.3. Options spécifiques-GFS2 disponibles en cours d'agrandissement d'un système de fichiers

Option Description
-h Assistance. Affiche un court message d'utilisation
-q Calme. Diminue le niveau de verbosité
-r MegaBytes Précise la taille du nouveau groupe de ressources. La taille par défaut est de 256Mo.
-T Test. Effectue tous les calculs, mais n'inscrit aucune donnée sur le disque et n'agrandit pas le système de fichiers.
-V Affiche l'information version de commande.

3.7. Ajouter les journaux au système de fichiers

La commande gfs2_jadd est utilisée pour ajouter des journaux à un système de fichiers GFS2. Vous pouvez ajouter des journaux à un système de fichiers GFS2 dynamiquement, à n'importe quel point, sans agrandir le volume logique sous-jacent. La commande gfs2_jadd doit être exécutée sur un système de fichiers monté, mais il devra n'être exécuté que sur un nœud dans le cluster. Tous les autres nœuds comprendront que l'expansion a eu lieu.

Note

Si un système de fichiers GFS2 est complet, la commande gfs2_jadd échouera,même si le volume logique contenant le système de fichiers a été agrandi etest plus grand que le système de fichiers. C'est parce que dans un système de fichier GFS2, les journaux correspondent à des fichiers simples et non pas à des métadonnées intégrées, donc simplement agrandirle volume logique sous-jacent ne fournira pas d'espace pour les journaux.
Avant d'ajouter des journaux à un système de fichiers GFS, vous pouvez utiliser l'option journals de la commande gfs2_tool pour trouver combien de journaux sont contenus dans le système de fichiers GFS2 actuellement. L'exemple suivant affiche le nombre et la taille des journaux du système de fichiers qui sont montés sur /mnt/gfs2.
[root@roth-01 ../cluster/gfs2]# gfs2_tool journals /mnt/gfs2
journal2 - 128MB
journal1 - 128MB
journal0 - 128MB
3 journal(s) found.

Utilisation

gfs2_jadd -j Number MountPoint
Number
Précise le nombre de nouveaux journaux à ajouter.
MountPoint
Précise le répertoire où le système de fichiers GFS2 est monté.

Exemples

Dans cet exemple, un journal est ajouté au système de fichiers sur le répertoire /mygfs2.
gfs2_jadd -j1 /mygfs2
Dans cet exemple, deux journaux ont été ajoutés dans le répertoire /mygfs2.
gfs2_jadd -j2 /mygfs2

Utilisation totale

gfs2_jadd [Options] {MountPoint | Device} [MountPoint | Device]
MountPoint
Précise le répertoire où le système de fichiers GFS2 est monté.
Device
Précise le nœud du périphérique du système de fichiers.
Tableau 3.4, « Options spécifiques-GFS2 disponibles quand on ajoute des journaux » décrit les options spécifiques à GFS2 qui peuvent être utilisées quand on ajoute des journaux supplémentaires à un système de fichiers GFS2.

Tableau 3.4. Options spécifiques-GFS2 disponibles quand on ajoute des journaux

Marqueur Paramètre Description
-h Assistance. Affiche un message court d'utilisation
-J Mégaoctets Précise la taille des nouveaux journaux en megaoctets. La taille du journal par défaut est de 128 mégaoctets. La taille minimum est de 32 mégaoctets. Pour ajouter des journaux de tailles différentes au système de fichiers, la commande gfs2_jadd doit être exécutée pour chaque taille de journal. La taille spécifiée est arrondie à l'inférieur de façon à représenter un multiple de la taille du segment de journal qui aura été spécifié au moment où le système de fichiers a été créé.
-j Number Précise le nombre de nouveaux journaux à ajouter par la commande gfs2_jadd. La valeur par défaut est de 1.
-q Calme. Diminue le niveau de verbosité
-V Affiche l'information version de commande.

3.8. Journalisation des données

Normalement, GFS2 n'inscrit que les métadonnées dans son journal. Les contenus de fichier sont donc inscrits par la sync périodique du noyau qui purge les tampons des systèmes de fichiers. Un appel fsync() sur un fichier a pour effet d'inscrire les données du fichier immédiatement sur le disque. L'appel revient lorsque le disque rapporte que toutes les données ont été inscrites en toute sécurité.
La journalisation des données peut entraîner une réduction du temps de sync fsync pourles très petits fichiers parce que les données du fichier sont inscrites dans le journal en plus des métadonnées. Cet avantage se réduit rapidement quand la taille du fichier augmente.Les écritures à des fichiers de moyenne ou grande taille seront beaucoup plus lentes avec la journalisation de donnéesactivée.
Les applications qui dépendent de fsync() pour synchroniser les données de fichier pourraient être améliorées en utilisant la journalisation des données. La journalisation des données peut être activée automatiquement pour tout fichier GFS2 créé dans un répertoire balisé (et dans tous ses sous-répertoires). Les fichiers existants d'une longueur nulle peuvent également avoir la journalisation des données activée.
L'activation de la journalisation de données sur un répertoire définit le répertoire "inherit jdata", qui indique que tous les fichiers et répertoires créés par la suite dansce répertoire sont journalisés. Vous pouvez activer et désactiver la journalisation de données surun fichier par la commande chattr.
Les commandes suivantes désactivent la journalisation des données sur le fichier /mnt/gfs2/gfs2_dir/newfile et vérifient ensuite si le marqueur a été installé correctement.
[root@roth-01 ~]# chattr +j /mnt/gfs2/gfs2_dir/newfile
[root@roth-01 ~]# 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 le marqueur a été installé correctement.
[root@roth-01 ~]# chattr -j /mnt/gfs2/gfs2_dir/newfile
[root@roth-01 ~]# lsattr /mnt/gfs2/gfs2_dir
------------- /mnt/gfs2/gfs2_dir/newfile
Vous pouvez également utiliser la commande chattr pour définir le marqueur j sur le répertoire. Quand vous fixez ce marqueur sur un répertoire, tous les fichiers et répertoires créés par la suite dans ce répertoire seront journalisés. Le groupe de commandes suivantes créent un marqueur j sur le répertoire gfs2_dir, puis contrôle que le marqueur a bien été défini correctement. Ensuite, les commandes créent un nouveau fichier intitulé newfile dans le répertoire /mnt/gfs2/gfs2_dir, puis contrôlent que le marqueur j a bien été défini pour ce fichier. Comme le marqueur j a été défini pour le répertoire, le newfile devrait avoir sa journalisation activée.
[root@roth-01 ~]# chattr -j /mnt/gfs2/gfs2_dir
[root@roth-01 ~]# lsattr /mnt/gfs2
---------j--- /mnt/gfs2/gfs2_dir
[root@roth-01 ~]# touch /mnt/gfs2/gfs2_dir/newfile
[root@roth-01 ~]# lsattr /mnt/gfs2/gfs2_dir
---------j--- /mnt/gfs2/gfs2_dir/newfile

3.9. Configurer les mises à niveau atime

Chaque inode de fichier ou de répertoire comprend trois dates qui lui sont associées:
  • ctime — La dernière fois que le statut de l'inode a été changé
  • mtime — La dernière fois que les données du fichier (répertoire) ont été modifiées
  • atime — La dernière fois que les données du fichier (répertoire) ont été accédées
Si les mises à jour atime sont activées de la même façon qu'elles le sont par défaut sur les systèmes de fichiers GFS2 et autres fichiers Linux, alors à chaque fois qu'un fichier est lu, son inode a besoin d'être mis à jour.
Comme peu d'applications utilisent l'information fournie par atime, ces mises à jour peuvent exiger une quantité importante de trafic d'écriture ou de verrouillage de fichier. Ce trafic peut dégrader la performance ; par conséquent, il peut être préférable de désactiver ou de réduire lesfréquence des mises à jour de atime.
Il existe deux méthodes pour réduire les effets des mises à jour de la commande atime :
  • Montez les fichiers avec relatime (atime relatif), qui met à jour atime si la mise à jour de atime précédente est plus ancienne que la mise à jour de mtime ou de ctime.
  • Montez les fichiers avec noatime, qui désactive les mises à jour de atime sur ce système de fichiers.

3.9.1. Montez les fichiers avec relatime

On peut spécifier l'option de montage de Linux relatime (atime relatif) quand on monte le système de fichiers. Elle indique si atime est mis à jour quand la dernière mise à jour de atime est plus ancienne que la mise à jour de mtime ou de ctime.

Utilisation

mount  BlockDevice MountPoint -o relatime
BlockDevice
Précise le périphérique en mode bloc où le système de fichiers GFS2 se situe.
MountPoint
Précise le répertoire où le système de fichiers GFS2 devrait être monté.

Exemple

Dans cet exemple, le système de fichiers GFS2 se trouve sur /dev/vg01/lvol0 et il est monté sur le répertoire /mygfs2. Les mises à jour de atime n'auront lieu que si la dernière mise à jour de atime est plus ancienne que la mise à jour de mtime ou de ctime.
mount /dev/vg01/lvol0 /mygfs2 -o relatime

3.9.2. Monter les fichiers avec noatime

On peut spécifier l'option de montage de Linux noatime quand le système de fichiers est monté, ce qui désactive les mises à jour de atime sur le système de fichiers.

Utilisation

mount BlockDevice MountPoint -o noatime
BlockDevice
Précise le périphérique en mode bloc où le système de fichiers GFS2 se situe.
MountPoint
Précise le répertoire où le système de fichiers GFS2 devrait être monté.

Exemple

Dans cet exemple, le système de fichiers GFS2 se trouve sur /dev/vg01/lvol0 et il est monté sur le répertoire /mygfs2 avec les mises à jour de atime désactivées.
mount /dev/vg01/lvol0 /mygfs2 -o noatime

3.10. Suspendre toute activité sur un système de fichier

Vous pouvez suspendre toute activité sur un système de fichiers en utilisant la commande gfs2_tool freeze. La suspension de l'activité écriture permet l'utilisation des snapshots de sauvegarde des périphériques de matériel pour entrer le système de fichiers dans un état cohérent. La commande gfs2_tool unfreeze termine la suspension.

Utilisation

Start Suspension
gfs2_tool freeze MountPoint
End Suspension
gfs2_tool unfreeze MountPoint
MountPoint
Précise le système de fichiers.

Exemples

Cet exemple suspend l'écriture dans un système de fichiers/mygfs2.
gfs2_tool freeze /mygfs2
Cet exemple suspend l'écriture dans un système de fichiers/mygfs2.
gfs2_tool unfreeze /mygfs2

3.11. Réparer un système de fichiers

Quand les nœuds échouent dans le système de fichiers monté, la journalisation du système de fichiers vous permet une récupération rapide. Cependant, si un périphérique de stockage perd en puissance ou est disconnecté physiquement, il peut y avoir une corruption de fichier. (la journalisation ne peut pas être utilisée pour une récupération suite à un échec de sous-système de stockage). Suite à ce type de corruption, vous pouvez rétablir le système de fichiers GFS2 par la commande fsck.gfs2.

Avertissement

La commande fsck.gfs2 ne doit exécuter que dans un système de fichiers qui est démonté sur tous les nœuds.

Note

Si vous avez déjà utilisé la commande gfs_fsck sur les systèmes de fichiers GFS, veuillez noter que la commande fsck.gfs2 est légèrement différente des versions plus anciennes de gfs_fsck des façons suivantes :
  • Appuyer sur les touches Ctrl+C tout en exécutant fsck.gfs2 interrompt le traitement et affiche une invitation vous demandant si vous souhaiter annuler la commande, ignorer le reste de la passe en cours, ou poursuivez vos activités de traitement.
  • Vous pouvez augmenter le niveau de verbosité en utilisant le marqueur -v. Ajouter un second marqueur -v augmente le niveau à nouveau.
  • Vous pouvez diminuer le niveau de verbosité en utilisant le marqueur -q. L'ajout d'un second marqueur -q augmente le niveau à nouveau.
  • L'option -n ouvre un système de fichiers en lecture-seule et répond no (non) à n'importe quelle requête automatiquement. L'option fournit un moyen de tester la commande pour qu'elle révèle des erreurs sans permettre pour autant à la commandefsck.gfs2 de prendre effet.
Référez-vous à la page man fsck.gfs2 pour obtenir des informations supplémentaires sur les autres options de commande.
Pour pouvoir exécuter la commande fsck.gfs2, vous avez besoin d'une mémoire systèmeau-delà de la mémoire utilisée pour le système d'exploitation et le noyau. Chaquebloc de mémoire dans le système de fichier GFS2 lui-même nécessite environ 5bits de mémoire supplémentaire, ou de 5/8 d'un octet. Donc, pour estimer le nombre d'octetsde mémoire, vous devrez exécuter la commande fsck.gfs2 survotre système de fichiers, vous devrez déterminer combien de blocs du système de fichiers sont contenus etmultiplier ce nombre par 5/8.
Par exemple, pour déterminer approximativement la quantité de mémoire nécessaire pour exécuter fsck.gfs2 sur un système de fichiers GFS2 de 16TB avec une taille de bloc de 4K, déterminer tout d'abord le nombre de blocs de mémoire contenus par le système de fichiers en divisant 16Tb par 4K :
 17592186044416 / 4096 = 4294967296
Comme ce système de fichiers contient 4294967296 blocs, multipliez ce nombre par 5/8 pour déterminer le nombre d'octets de mémoire requis :
4294967296 * 5/8 = 2684354560
Ce système de fichiers a besoin de 2.6Go approximativement pour pouvoir exécuter la commande fsck.gfs2. Notez que si la taille du bloc est de 1K, vous aurez besoin de quatre fois ce montant de mémoire pour exécuter la commande fsck.gfs2, soient environ 11Go.

Utilisation

fsck.gfs2 -y BlockDevice
-y
Le marqueur -y fait que toutes les questions auront pour réponse yes (oui). Avec le marqueur -y spécifié, la commande fsck.gfs2 ne vous invite pas à donner une réponse avant de procéder aux changements.
BlockDevice
Précise le périphérique en mode bloc où le système de fichiers GFS2 se situe.

Exemple

Dans cet exemple, le système de fichiers GFS2 résidant sur le périphérique en mode bloc /dev/testvol/testlv est réparé. Toutes les demandes de réparation sont automatiquement adressées par yes.
[root@dash-01 ~]# 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

3.12. Noms de chemins Contexte-dépendants et Montage associés

Les systèmes de fichiers ne fournissent pas de support pour les noms d'emplacements contexte-dépendants (CPDNs), ce qui vous permet de créer les liens symboliques qui mènent à des destinations de fichiers et de répertoires multiples. Pour cette fonction dans GFS2, vous pouvez utiliser l'option bind de la commande mount.
L'option bind de la commande mount vous permet de remonter une partie d'une hiérarchie de fichiers vers un emplacement différent tandis qu'elle est toujours dans son emplacement d'origine. Le format de cette commande suit.
mount --bind olddir newdir
Après avoir exécuté cette commande, le contenu du répertoire olddir est disponible dans deux emplacements: olddir et newdir. Vous pouvez également utiliser cette option pour rendre ce fichier disponible dans deux emplacements.
Par exemple, après avoir exécuté les commandes suivantes, le contenu de /root/tmp sera identique au contenu du répertoire monté auparavant /var/log.
[root@menscryfa ~]# cd ~root
[root@menscryfa ~]# mkdir ./tmp
[root@menscryfa ~]# mount --bind /var/log /root/tmp
Sinon, vous pouvez utiliser une entrée dans le fichier /etc/fstab pour le même résultat au moment du montage. L'entrée suivante /etc/fstab amènera à ce que le contenu de /root/tmp soit identique au contenu du répertoire /var/log.
/var/log                /root/tmp               none    bind            0 0
Après avoir monté le système de fichiers, vous pouvez utiliser la commande mount pour voir si le système de fichiers a bien été monté, comme dans l'exemple suivant.
[root@menscryfa ~]# mount | grep /tmp
/var/log on /root/tmp type none (rw,bind)
Avec un système de fichier qui supporte les noms de chemins contexte-dépendants, vous avez peut-être pu définir le répertoire /bin dans un nom d'emplacement contexte-dépendant, qui se résoudrait aux emplacements ci-dessous, suivant le système d'architecture.
/usr/i386-bin
/usr/x86_64-bin
/usr/ppc64-bin
Vous pouvez obtenir la même fonctionnalité en créant un répertoire vide /bin. Puis, en utilisant un script ou un point d'entrée dans le fichier /etc/fstab, vous pouvez monter chaque répertoire de l'architecture individuelle dans le répertoire /bin à l'aide d'une commande mount -bind. Par exemple, vous pouvez utiliser les commandes suivantes dans une ligne de script.
mount --bind /usr/i386-bin /bin
Ou bien, vous pouvez utiliser l'entrée suivante dans le fichier /etc/fstab.
/usr/1386-bin             /bin               none    bind            0 0
Un montage associé peut offrir une plus grande flexibilité pour un nom d'emplacement contexte-dépendant, car vous pouvez utiliser cet attribut pour monter différents répertoires suivant n'importe quel critère que vous aurez déterminé (comme la valeur de %fill pour le système de fichiers). Les noms d'emplacement contexte-dépendants sont plus limités à ce qu'ils englobent. Notez, cependant, que vous aurez besoin d'écrire votre propre script pour effectuer les montages suivant des critères comme la valeur de %fill.

Avertissement

Lorsque vous montez un système de fichiers avec l'option bind et que le système de fichiers original était monté rw, le nouveau système de fichiers sera également monté rw même si vous utilisez le marqueur ro; le marqueur ro est ignoré silencieusement. Dans ce cas, le nouveau système de fichiers pourrait être marqué en tant que ro dans le répertoire /proc/mounts, ce qui pourrait induire à confusion.

3.13. Points de montage associés et Ordre de montage du système de fichiers

Quand vous utilisez l'option bind de la commande mount, vous devrez vous assurer que les systèmes de fichiers sont montés dans l'ordre qui convient. Dans l'exemple suivant, le répertoire /var/log doit être installé avant d'exécuter le point de montage associé sur le répertoire /tmp :
# mount --bind /var/log /tmp
L'ordre des points de montage des systèmes de fichiers est déterminé comme suit :
  • En général, l'ordre de montage des systèmes de fichiers est déterminé par l'ordre dans lequel les systèmes de fichiers apparaissent dans le fichier fstab. Les seules exception sont les systèmes de fichiers qui sont montés avec un marqueur _netdev ou bien les systèmes de fichiers qui ont leur propre script init.
  • Un système de fichiers avec son propre script init est monté plus tard au cours du processus d'initialisation, après les systèmes de fichiers dansfstab.
  • Les systèmes de fichiers montés avec le marqueur _netdev sont montés quand le réseau a été activé dans le système.
Si vous avez besoin de créer un point de montage associé sur lequel monter un système de fichiers GFS2 pour votre configuration, vous pourrez ordonner le fichier fstab comme suit :
  1. Montez des systèmes de fichiers locaux requis pour le point de montage associé.
  2. Faire un montage associé du répertoire où le système de fichiers GFS2 sera monté.
  3. Création d'un système de fichiers GFS2.
Si votre configuration requiert que vous fassiez un montage associé de répertoire local ou de système de fichierssur un système de fichiers GFS2, énumérer les systèmes de fichiers dans le bonordre dans le fichier fstab ne montera pas les systèmes de fichierscorrectement, puisque le système de fichiers GFS2 ne sera pas monté avant que le scriptinit de GSF soit exécuté. Dans ce cas, vous devrez écrire unscript init pour exécuter le montage associé, pour que le montage associé ne prenne pas effet avant que le système de fichiers GFS2 ne soit monté.
Le script suivant est un exemple de script init personnalisé. Le script crée un montage associé de deux répertoires dans deux répertoires du système de fichiers GFS2. Dans cet exemple, il y a un point de montage GFS2 existant à /mnt/gfs2a, qui est monté quand le script init de GFS2 exécute, suite au démarrage du cluster.
Dans cet exemple de script, les valeurs de l'énoncé chkconfig indiquent ce qui suit :
  • 345 indique les niveaux d'exécution auxquels le script va démarrer
  • 29 est la priorité de départ, qui, dans ce cas, indique que le script va exécuter au départ à la suite du script init de GFS2, qui a une priorité de démarrage de 26
  • 73 correspond à la priorité 'stop', qui dans ce cas, indique que le script cessera en cours de fermeture juste avant le script GFS2, qui lui, a une priorité de 74.
Les valeurs de démarrage et d'arrêt indiquent que vous pouvez effectuer manuellement l'action indiquée manuellement en exécutant les commandes service start et service stop. Ainsi, si le script s'intitule fredwilma, alors vous pourrez exécuter la commande service fredwilma start.
Ce script doit être mis dans le répertoire /etc/init.d avec les mêmes permissions que les autres scripts de ce répertoire. Vous pourrez alors exécuter une commande chkconfig on pour relier le script aux niveaux d'exécution demandés. Ainsi, si le script s'intitule fredwilma, vous pourrez exécuter la commande chkconfig fredwilma on.

#!/bin/bash
#
# chkconfig: 345 29 73
# description: mount/unmount my custom bind mounts onto a gfs2 subdirectory
#
#
### BEGIN INIT INFO
# Provides: 
### END INIT INFO

. /etc/init.d/functions
case "$1" in
  start)
	# In this example, fred and wilma want their home directories
	# bind-mounted over the gfs2 directory /mnt/gfs2a, which has
	# been mounted as /mnt/gfs2a
	mkdir -p /mnt/gfs2a/home/fred &> /dev/null
	mkdir -p /mnt/gfs2a/home/wilma &> /dev/null
	/bin/mount --bind /mnt/gfs2a/home/fred /home/fred
	/bin/mount --bind /mnt/gfs2a/home/wilma /home/wilma
        ;;

  stop)
	/bin/umount /mnt/gfs2a/home/fred
	/bin/umount /mnt/gfs2a/home/wilma
        ;;

  status)
        ;;

  restart)
        $0 stop
        $0 start
        ;;

  reload)
        $0 start
        ;;
  *)
        echo $"Usage: $0 {start|stop|restart|reload|status}"
        exit 1
esac

exit 0

3.14. La fonctionnalité GFS2 Withdraw

La fonction GFS2 withdraw est une fonctionnalité d'intégrité de données des systèmes de fichiers GFS2 dans un cluster. Si le module de noyau GFS2 détecte une anomalie dans le système GFS2 suite à une opération I/O, le système de fichiers est rendu disponible dans le cluster. L'opération I/O stoppe et le système patiente pour d'autres erreurs d'opérations I/O, afin d'éviter que le système soit davantage endommagé. Quand cela se produit, vous pouvez stopper les autres services ou applications manuellement, et ensuite, vous pouvez redémarrer et remonter le système de fichiers GFS2 manuellement pour pouvoir relire les journaux. Si le problème persiste, vous pouvez démonter le système de fichiers sur tous les nœuds du cluster et effectuer un recouvrement du système par la commande fsck.gfs2. La fonction Withdraw de GFS est une moindre mesure par rapport à la panique de noyau, qui entrainerait une autre nœud à clôturer le nœud.
Si votre système est configuré avec le script de départ gfs2 activé, et que le système de fichiers GFS2 est inclus dans le fichier /etc/fstab, le système de fichiers GFS2 sera monté à nouveau quand vous redémarrerez. Si le système de fichiers GFS2 s'est retiré pour raison de corruption du système de fichiers, nous vous conseillons d'exécuter la commande fsck.gfs2 avant de remonter le système de fichiers. Dans ce cas, pour empêcher votre système de fichiers de se remonter au démarrage, vous pouvez procéder ainsi :
  1. Désactiver temporairement le script de démarrage sur le nœud affecté par la commande suivante :
    # chkconfig gfs2 off
  2. Redémarrer le nœud affecté, en démarrant le logiciel du cluster. Le système de fichiers GFS2 ne sera pas monté.
  3. Démonter tous les nœuds du système de fichier dans le cluster.
  4. Exécuter la commande fsck.gfs2 sur le système de fichier sur un seul noeud pour éviter toute corruption de système de fichier.
  5. Réactiver temporairement le script de démarrage sur le nœud affecté par la commande suivante :
    # chkconfig gfs2 on
  6. Remonter tous les nœuds du système de fichier GFS2 dans le cluster.
Un nombre de blocs erroné est un exemple d'incohérence qui provoquerait un retrait de GFS2 retirer. Lorsque le noyau GFS supprime un fichier d'unsystème de fichiers, il supprime systématiquement toutes les données et les métadonnées des blocsassociés à ce fichier. Une fois que c'est fait, il vérifie le nombre de blocs. Sile nombre de blocs correspond à 'un' (ce qui veut dire que tout ce qui reste est l'inode du disque), qui indique une incohérence du système de fichiers puisque le nombre de blocs ne correspondent pas à la liste des blocs trouvés.
Vous pouvez annuler la fonction Withdraw de GFS2 en montant le système de fichiers par l'option -o errors=panic spécifiée. Quand cette option est spécifiée, toute erreur qui entraînerait normalement le système à se retirer (withdraw) causerait une panique de système à la place. Cela stoppe les communications de cluster du nœud, et clôture le nœud.
En interne, la fonction Withdraw de GFS2 opère ainsi : le noyau envoie un message au démon gfs_controld lui demandant de se retirer.La commandegfs_controld démon exécute le programme dmsetup pour mettre la cible d'erreurs du mappeur (device mapper) sous le système de fichiers pour empêcher l'accès au périphérique bloc. Il indique ensuite au noyau que cela a été complété. C'est la raison pour laquelle le support GFS2exige un CLVM sous GFS2, car autrement il ne serait pas possible d'insérer une cible de mappeur.
Le but de la cible erreur du mappeur (device mapper) est de veiller à ce que toutes les opération E/S à venir se transformeront en erreur E/S, ce qui permettra au système de fichiers d'être démonté de façon ordonnée. Ainsi, au moment du retrait (withdraw), il est normal de voir apparaître un certain nombre d'erreurs E/S en provenance du mappeur reportées dans la journalisation.
De temps en temps, le retrait (withdraw) échoue s'il n'est pas possible pour le programme dmsetup d'insérer une cible erreur comme demandé. Cela peut se produire si on manque de mémoire au moment du retrait et que la mémoire ne peut pas être récupérée, à cause du problème qui a créé le retrait pour commencer.
Un retrait n'indique pas forcément qu'il y ait une erreur dans GFS2. Parfois la fonction Withdraw peut être déclenchée par les erreurs E/S du dispositif de blocs qui se trouve en dessous. Il est fortement conseillé de vérifier les journaux pour voir si tel est le cas quand un retrait a lieu.

Chapitre 4. Diagnostiquer et corriger les problèmes dans les systèmes de fichiers GFS2.

Ce chapitre fournit des informations sur des problèmes communs dans GFS2 et comment les résoudre.

4.1. Le système de fichiers GFS2 semble réduire en performance

Vous allez sans doute trouver que votre système de fichiers GFS2 semble moins performant qu'un système de fichiers EXT3. La performance de GFS2 est sans doute affectée par un certain nombre de facteurs dans certains cas d'utilisation. Les informations qui répondent aux questions de performance de GFS2 se trouvent dans ce document.

4.2. Installer NFS sur GFS2

En raison de la complexité grandissante du sous-système de verrouillage de GFS2, et de sa nature clusterisée, installer NFS sur GFS2 requiert certaines précautions et une configuration soignée. Cette section décrit les précautions que vous devez prendre quand vous configurez un service NFS sur un système de fichiers GFS2.

Note

Si le système de fichiers GFS2 est exporté via NFS et que les applications des clients NFS utilisent des verrous POSIX, alors vous devez monter le système de fichiers avec l'option localflocks. L'effet voulu est de forcer les verrous POSIX de chaque serveur à devenir des verrous localisés: c'est-à-dire non clusterisés, indépendants les uns des autres. (Un certain nombre de problèmes existence si GFS2 tente de mettre en œuvre des verrous POSIX à partir de NFS à travers les nœuds d'un cluster). Pour les applications qui s'exécutent sur les clients NFS, les verrous localisés POSIX impliquent que deux clients peuvent tenir le même verrou simultanément si les deux clients font des montages à partir de serveurs différents. Si tous les clients montent NFS à partir du même serveur, alors le problème d'octroi des mêmes verrous par des serveurs séparés indépendamment disparaît.
En plus des considérations de verrouillage, vous devrez prendre en considération ce qui suit quand vous allez configurer un service NFS sur un système de fichiers GFS2.
  • Red Hat ne prend en charge que les configurations du module complémentaire High Availability par NFSv3 avec un verrouillage dans une configuration active/passive, et les caractéristiques suivantes :
    • Le système de fichiers du serveur principal est un système de fichiers GFS2 qui exécute sur 2 à 16 cluster de nœuds.
    • Un serveur NFSv3 est défini comme un service qui explore tout le système de fichiers GFS2 à partir d'un nœud de cluster à la fois.
    • Le serveur NFS peut échouer d'un nœud de cluster à un autre (configuration active/passive).
    • L'accès au système de fichiers GFS2 n'est pas autorisé, sauf par le serveur NFS. Cela inclut à la fois le système de fichiers GFS2 local, et l'accès par Samba ou Samba clusterisé.
    • Il n'y a pas de support de quota NFS sur le système.
    La configuration fournit HA pour le système de fichiers et réduit le temps d'inactivité du système, puisqu'un nœud qui échoue ne résulte pas dans l'obligation d'exécuter la commande fsck quand le serveur NFS est mis en échec d'un nœud à l'autre.
  • L'option NFS fsid= est obligatoire pour les exports NFS de GFS2.
  • En cas de problèmes avec votre cluster (par exemple, le quorum n'a pas été atteint dans le cluster ou les clôtures échouent), les volumes logiques en cluster et le système de fichiers de GFS2 seront bloqués et aucun accès ne sera possible jusqu'à ce que le cluster ait le quorum. Vous devez envisager cette possibilité pour déterminer si une solution simple de basculement telle que celle qui est définie dans cette procédure est la plus appropriée pour votre système.

4.3. Le système de fichiers GFS2 se bloque et un nœud a besoin d'être démarré à nouveau.

Si votre système de fichiers GFS2 se bloque et ne répond pas quand on exécute des commandes dessus, mais que le système se rétablit si on redémarre un nœud spécifique, c'est sans doute indicatif d'un problème de verrouillage ou d'un bogue. Si vous rencontrez les problème, vous devrez collecter les informations suivantes :
  • L'image de vidage de verrouillage de gfs2 pour le système de fichiers sur chaque nœud :
    cat /sys/kernel/debug/gfs2/fsname/glocks >glocks.fsname.nodename
  • L'image de vidage de verrouillage de DLM pour le système de fichiers sur chaque nœud : vous obtiendrez cette information en exécutant la commande dim_tool :
    dlm_tool lockdebug -sv lsname.
    
    Dans cette commande, lsname est le nom de lockspace (espace disponible pour les verrous) utilisé par DML pour le système de fichiers en question. Vous en trouverez la valeur dans la sortie de la commande group_tool.
  • La sortie de la commande sysrq -t.
  • Le contenu du fichier /var/log/messages.
Une fois que vous aurez collecté ces données, vous pourrez ouvrir un ticket dans Red Hat Support et fournir les données que vous aurez collectées.

4.4. Le système de fichiers se bloque et tous les nœuds ont besoin d'être démarrés à nouveau.

Si votre système de fichiers se bloque et ne répond pas quand on exécute des commandes, exigeant de ce fait que l'on redémarre tous les nœuds du cluster avant de l'utiliser, vérifier les points suivants.
  • Vous avez peut-être une clôture défaillante. Les systèmes de fichiers vont se bloquer pour garantir l'intégrité des données en cas de défaillance de la clôture. Vérifiez les journaux de messages pour voir s'il n'y avait pas de clôture défaillante au moment du blocage. Veillez à ce que le clôturage soit configuré correctement.
  • Le système de fichiers s'est peut-être retiré. Cherchez dans les journaux de messages le mot withdraw (se retirer) et regardez si vous voyez des messages ou des calltraces de GFS2 qui pourraient indiquer que le système de fichiers a été retiré. Un retrait de système de fichier est indicatif, soit d'une corruption de système de fichier, d'un échec de stockage, ou un bogue. Démontez le système de fichiers, mettez à jour le package gfs2-utils, et exécutez la commande fsck sur le système de fichiers pour le remettre en service. Ouvrez un ticket dans Red Hat Support. Informez-les de ce qui vous est arrivé avec GFS2, et fournir le sosreport avec les journaux accompagnatifs.
    Pour obtenir davantage d'informations sur la fonction de retrait de la fonction "withdraw", consulter Section 3.14, « La fonctionnalité GFS2 Withdraw ».
  • Cette erreur pourrait indiquer un problème de verrouillage ou un bogue. Collecter des données pendant un de ces épisodes, et ouvrez un ticket dans Red Hat Support, comme décrit dans Section 4.3, « Le système de fichiers GFS2 se bloque et un nœud a besoin d'être démarré à nouveau. ».

4.5. Le système de fichiers GFS2 ne peut pas être monté sur un nœud de cluster nouvellement ajouté.

Si vous ajoutez un nouveau nœud au cluster et que vous réalisez que vous ne pouvez pas monter votre système de fichiers GFS2 sur ce nœud, vous aurez sans doute moins de journaux sur le système de fichiers GFS2 que de nœuds qui tentent d'accéder au système de fichiers GFS2. Vous devriez avoir un journal par hôte GFS2 sur lequel vous avez l'intention de monter le système de fichiers (avec pour exception les systèmes de fichiers GFS2 montés par l'option de montage spectator, puisque ceux-ci n'ont pas besoin de journal). Vous pourrez ajouter des journaux au système de fichiers GFS2 par la commande gfs2_jadd, comme décrit dans Section 3.7, « Ajouter les journaux au système de fichiers ».

4.6. Espace noté comme utilisé dans le système de fichiers vide.

Si vous avez un système de fichiers GFS2 vide, la commande df vous montrera qu'il y a de l'espace utilisé. C'est parce que les journaux de système de fichier GFS2 consomment de l'espace (nombre de journaux * taille de journal) sur le disque. Si vous avez créé un système de fichiers GFS2 avec un grand nombre de journaux ou que vous ayez spécifié une grande taille de journal, alors vous verrez que l'espace (nombre de journaux * taille de journal) déjà utilisé lorsque vous exécutez la commande df . Même si vous n'avez pas spécifié un grand nombre de journaux ou de journaux de grande taille, les petits systèmes de fichiers GFS2 (dans la gamme 1 GB ou moins ) afficheront qu'il y a une grande quantité d'espace utilisée avec la taille de journal GFS2 par défaut.

Annexe A. Gestion des quotas GFS2 par la commande gfs2_quota

À partir de Red Hat Enterprise Linux 6.1, GSF2 supporte les fonctionnalités des quotas Linux standards. Pour les utiliser, vous aurez besoin d'installer le RPM quota. Il s'agit de la meilleure façon d'administrer les quotas dans GSF2 et doit être utilisé pour tous les nouveaux déploiements de GSF2 qui utilisent les quotas. Pour plus d'informations sur l'utilisation des fonctionnalités de quotas Linux standards, voir Section 3.5, « Gestion des Quotas GFS2 ».
Pour les anciennes versions de Red Hat Enterprise Linux, GFS2 exige la commande gfs2_quota pour gérer les quotas. Cette annexe documente l'utilisation de la commande gfs2_quota pour gérer les quotas du système de fichiers GSF2.

A.1. Configurer les quotas avec la commande gfs2_quota

Il y a deux paramétrages possibles de quotas pour chaque ID d'utilisateur (UID) ou ID de groupe (GID): une hard limit et une soft limit.
La 'hard limit' correspond à la quantité d'espace qui peut être utilisée. Le système de fichiers n'autorisera pas l'utilisateur davantage d'espace disque. Une valeur zéro signifie qu'il n'y a aucune limite.
Une 'soft limit' est en général inférieure à la 'hard limit'. Le système de fichiers va indiquer à l'utilisateur ou au groupe le moment ou la 'soft limit' a été atteinte pour qu'il puissent savoir combien d'espace ils utilisent. Une valeur zéro indique qu'il n'a a pas de limite.
Vous pouvez fixer des limites par la commande gsf2_quota. La commande a juste besoin d'être exécutée en nœud simple quand GSF2 est monté.
Les quotas ne sont pas activés par défaut sur les systèmes de fichiers GFS2. Pour activer le nombre de quotas, utiliser la commande quota= de la commande mount quand vous montez un système de fichiers GFS2, comme expliqué dans Section A.4, « Activer/désactiver l'exécution des quotas ».

Utilisation

Setting Quotas, Hard Limit
gfs2_quota limit -u User -l Size -f MountPoint
gfs2_quota limit -g Group -l Size -f MountPoint
Setting Quotas, Warn Limit
gfs2_quota warn -u User -l Size -f MountPoint
gfs2_quota warn -g Group -l Size -f MountPoint
User (utilisateur)
ID d'utilisateur pour limiter ou pour avertir. Peut correspondre au nom d'utilisateur du fichier de mot de passe ou le numéro d'UID.
Group (groupe)
Un ID de groupe pour limiter ou pour avertir. Peut correspondre au nom du groupe du fichier de groupe ou au numéro GID.
Taille
Précise la nouvelle valeur pour limiter ou avertir. La valeur par défaut est en mégaoctets. Les drapeaux -k, -s et -b changent les unités en kilooctets, secteurs, et blocks de systèmes de fichiers, respectivement.
MountPoint
Spécifie le système de fichiers auquel les actions s'appliquent.

Exemples

Cet exemple fixe la 'hard' limite à 1024 mégaoctets (1 gigaoctet) pour Bert sur le système de fichiers /mygfs2.
gfs2_quota limit -u Bert -l 1024 -f /mygfs2
Cet exemple fixe la 'soft' limite à 50 kilobytes pour le groupe dont l'ID est 21 dans le système de fichiers /mygfs2.
gfs2_quota warn -g 21 -l 50 -k -f /mygfs2

A.2. Afficher les limites et utilisations de quotas par la commande gfs2_quota

Un utilisateur ou un groupe particulier peuvent afficher les limites de quotas ou l'état de leur usage actuel par la commande gfs2_quota get. Le contenu entier du fichier de quotas peut également être affiché par la commande gfs2_quota list, dans lequel cas, toutes les ID dont la valeur ou la 'hard' ou 'soft' limite est non-nulle sont listées.

Utilisation

Affichage des limites de quotas pour un utilisateur
gfs2_quota get -u User -f MountPoint
Affichage des limites de quotas pour un groupe
gfs2_quota get -g Group -f MountPoint
Affichage d'un fichier entier de quotas
gfs2_quota list -f MountPoint
User (utilisateur)
Une ID d'utilisateur utilisée pour afficher des informations sur un utilisateur particulier. Peut correspondre au nom d'utilisateur du fichier de mot de passe ou le numéro d'UID.
Group (groupe)
ID de groupe pour afficher des informations sur un groupe particulier. Peut correspondre au nom du groupe du fichier de groupe ou au numéro de GID.
MountPoint
Spécifie le système de fichiers auquel les actions s'appliquent.

Sortie de commande

Les informations de quotas de la commande gfs2_quota sont affichées sous la forme suivante :
user User: limit:LimitSize warn:WarnSize value:Value

group Group: limit:LimitSize warn:WarnSize value:Value

Les chiffres (valeurs) suivante: LimitSize, WarnSize, et Value sont en mégaoctets par défaut. Si vous ajoutez le drapeau -k, -s, ou -b à la ligne de commande, vous changez les unités en kilooctets, secteurs, ou blocks de systèmes de fichiers respectivement.
User (utilisateur)
Un nom d'utilisateur ou une ID associés aux données.
Group (groupe)
Un nom de groupe ou une ID associés aux données.
LimitSize
La 'hard' limite fixée pour l'utilisateur ou pour le groupe. La valeur correspondra à zéro si aucune limite n'a été fixée.
Value
Le montant d'espace disque utilisé par l'utilisateur ou par le groupe.

Commentaires

Quand les informations de quotas sont affichées, la commande gfs2_quota ne résout pas les UID et GID en noms si l'option -n est rajoutée à la ligne de commande.
L'espace alloué aux fichiers cachés de GFS2 peuvent ne pas comprendre les valeurs affichées pour la racine UID et GID, si vous ajoutez l'option -d à la ligne de commande. Cela peut être utile si vous essayez de faire correspondre les nombres de gfs2_quota aux résultats d'une commande du.

Exemples

Cet exemple affiche les informations sur les quotas pour tous les utilisateurs et groupes qui ont une limite définie, ou qui utilisent l'espace disque sur le système de fichiers /mygfs2.
gfs2_quota list -f /mygfs2
Cet exemple affiche des informations sur les quotas en secteurs pour le groupe users sur le système de fichiers /mygfs2.
gfs2_quota get -g users -f /mygfs2 -s

A.3. Synchronisation des fichiers par la commande gfs2_quota

GFS2 stocke toutes les informations sur les quotas dans ses propres disques ou fichiers internes. Un nœud GFS2 ne met pas ce fichier de quotas à jour à chaque fois qu'il y a une écriture sur le système de fichiers; plutôt, et par défaut, il met à jour le fichier de quotas toutes les 60 secondes. Cela est utile pour éviter les contentieux entre les nœuds qui procèdent à des écritures dans le fichier de quotas, et qui pourraient causer un ralentissement de la performance.
Quand un utilisateur ou un groupe approche la limite de quotas, GFS2 réduit dynamiquement la durée entre les mises à jour de son fichier-quotas, pour éviter de dépasser la limite. La durée normale entre les synchronisations de quotas est un paramètre réglable, quota_quantum, et on peut changer sa valeur par défaut de 60 secondes, en utilisant la commande gfs2_tool. Aussi, le paramètre quota_quantum doit être défini pour chaque nœud et à chaque fois que le système est monté. (les changements au paramètre quota_quantum ne sont pas persistants à travers les 'dé-montages'.)
Vous pouvez utiliser la commande gfs2_quota sync pour synchroniser les informations de quotas à partir d'un nœud vers un fichier de quotas de disque, entre les mises à jour automatiques effectuées par GSF2.

Utilisation

Synchronisation des informations sur les quotas
gfs2_quota sync -f MountPoint
MountPoint
Spécifie le système de fichiers auquel les actions s'appliquent.
Réglage du système entre les synchronisations
gfs2_tool settune MountPoint quota_quantum Seconds
MountPoint
Spécifie le système de fichiers auquel les actions s'appliquent.
Seconds
Spécifie la nouvelle durée entre les synchronisations régulières de fichier-quotas par GFS2. Les petites valeurs risquent d'augmenter les contentieux et diminuer la performance.

Exemples

Cet exemple synchronise les informations de quotas du nœud d'exécution vers le système de fichiers /mygfs2.
gfs2_quota sync -f /mygfs2
Cet exemple change le délai par défaut entre les mises à jour de fichier-quota régulières jusqu'à une heure (3600 secondes) pour le système de fichier /mygfs2 sur un simple nœud.
gfs2_tool settune /mygfs2 quota_quantum 3600

A.4. Activer/désactiver l'exécution des quotas

Dans les systèmes de fichiers GSF2, l'exécution des quotas est désactivé par défaut. Pour activer les quotas dans un système de fichiers, monter le système de fichiers avec l'option quota=on précisée.

Utilisation

mount -o quota=on BlockDevice MountPoint
Pour monter un système de fichiers avec les quotas désactivés, monter le système de fichiers avec l'option quota=off spécifiée. Il s'agit de la valeur par défaut.
mount -o quota=off BlockDevice MountPoint
-o quota={on|off}
Précise si les quotas sont actifs ou non, quand le système de fichiers est monté.
BlockDevice
Précise le bloc où réside le système de fichiers GFS2.
MountPoint
Précise le répertoire où le système de fichiers doit être monté.

Exemples

Dans cet exemple, le système de fichiers GFS2 de /dev/vg01/lvol0 est monté sur le répertoire /mygfs2 avec les quotas activés.
mount -o quota=on /dev/vg01/lvol0 /mygfs2

A.5. Activer le calcul des quotas

Il est possible de garder la trace des utilisations de disque et de maintenir les calculs de quotas pour chaque utilisateur et pour chaque groupe, sans avoir à faire respecter les limites ou les valeurs d'avertissement.

Utilisation

mount -o quota=account BlockDevice MountPoint
-o quota=account
Précise si les statistiques d'utilisation par le groupe ou l'utilisateur sont conservés dans le système de fichiers, même si les limites de quotas ne sont pas respectées.
BlockDevice
Précise le bloc où réside le système de fichiers GFS2.
MountPoint
Précise le répertoire où le système de fichiers doit être monté.

Exemple

Dans cet exemple, le système de fichiers de /dev/vg01/lvol0 est monté sur le répertoire /mygfs2 avec le quota de calcul activé.
mount -o quota=account /dev/vg01/lvol0 /mygfs2

Annexe B. Convertir un système de fichier de GFS vers GFS2

Comme Red Hat Enterprise Linux 6 ne prend pas en charge les systèmes de fichiers GFS, vous devez mettre à niveau tous vos systèmes de fichiers GFS en GFS2 à l'aide de la commande gfs2_convert. Notez que vous devez procéder à cette conversion sur un système Red Hat Enterprise Linux 5 avant de le mettre à niveau à Red Hat Enterprise Linux 6.

Avertissement

Avant de convertir le système de fichiers GFS, vous devrez garder une copie de sauvegarde du système de fichiers, car le processus de conversion est irréversible et les erreurs rencontrées en cours de conversion peuvent aboutir à un arrêt brusque du programme et, par conséquence, résulter un un système de fichiers inutilisable.
Avant de convertir le système de fichiers GFS, vous devrez utiliser la commande gfs_fsck pour vérifier le système de fichiers et régler les erreurs.
Si la conversion de GFS en GFS2 est interrompue par une panne d'électricité ou autre, redémarrer l'outil de conversion. Ne tentez pas la commande fsck.gfs2 sur le système de fichiers avant que la conversion soit terminée.

Note

Les systèmes de fichiers GFS2 ne fournissent pas de support pour les noms d'emplacements contexte-dépendants (CPDNs), ce qui vous permet de créer les liens symboliques qui mènent à des destinations multiples de fichiers et de répertoires. Pour cette fonction dans GFS2, vous pouvez utiliser l'option bind de la commande mount.
La commande gfs2_convert identifie les CPDN et les remplace par des répertoires vides du même nom. Pour pouvoir configurer les points de montage de liaison qui puissent remplacer les CPDN, toutefois, vous devez connaître les noms complets des emplacements des liens cibles des CDPN que vous souhaitez remplacer. Avant de convertir votre système de fichiers, vous pouvez utiliser la commande find pour identifier les liens.
La commande suivante liste les liens symboliques qui pointent vers un CDPN hostname :
[root@smoke-01 gfs]# find /mnt/gfs -lname @hostname
/mnt/gfs/log
De même, vous pouvez exécuter la commande find pour les autres CDPN (mach, os, sys, uid, gid, jid). Notez bien que comme les noms de CDPN peuvent avoir la forme @hostname ou {hostname}, vous devrez exécuter la commande find pour chaque variante.
Pour plus d'informations sur les points de montage de liaison et sur les noms d'emplacement dépendant-contexte de GFS2, voir Section 3.12, « Noms de chemins Contexte-dépendants et Montage associés ».
Quand on convertit des systèmes de fichiers remplis ou presque, il est possible qu'il n'y ait pas suffisamment de place disponible pour toutes les structures de données du système de fichiers GFS2. Dans ce cas, la taille de tous les journaux est réduite uniformément, de façon à ce que tout puisse être contenu dans l'espace disponible.
Utiliser la procédure suivante pour convertir un système de fichiers GFS en système de fichiers GFS2.
  1. Sur un système Red Hat Entreprise Linux, gardez une copie de sauvegarde de votre système de fichiers GFS existant.
  2. Démonter tous les nœuds du système de fichier GFS dans le cluster.
  3. Exécuter la commande gfs_fsck sur le système de fichier GFS pour éviter toute corruption de système de fichier.
  4. Exécuter gfs2_convert gfsfilesystem. Le système affichera des avertissements et des questions à confirmer avant de convertir le gfsfilesystem en GFS2.
  5. Mise à niveau à Red Hat Enterprise Linux 6.
L'exemple suivant convertit un système de fichiers GFS en bloc /dev/shell_vg/500g sur un système de fichiers GFS2.
[root@shell-01 ~]#  /root/cluster/gfs2/convert/gfs2_convert /dev/shell_vg/500g 
gfs2_convert version 2 (built May 10 2010 10:05:40)
Copyright (C) Red Hat, Inc.  2004-2006  All rights reserved.

Examining file system..................
This program will convert a gfs1 filesystem to a gfs2 filesystem.
WARNING: This can't be undone.  It is strongly advised that you:

   1. Back up your entire filesystem first.
   2. Run gfs_fsck first to ensure filesystem integrity.
   3. Make sure the filesystem is NOT mounted from any node.
   4. Make sure you have the latest software versions.
Convert /dev/shell_vg/500g from GFS1 to GFS2? (y/n)y
Converting resource groups...................
Converting inodes.
24208 inodes from 1862 rgs converted.
Fixing file and directory information.
18 cdpn symlinks moved to empty directories.
Converting journals.
Converting journal space to rg space.
Writing journal #1...done.
Writing journal #2...done.
Writing journal #3...done.
Writing journal #4...done.
Building GFS2 file system structures.
Removing obsolete GFS1 file system structures.
Committing changes to disk.
/dev/shell_vg/500g: filesystem converted successfully to gfs2.

Annexe C. Historique des révisions

Historique des versions
Version 7-3.4002013-10-31Rüdiger Landmann
Rebuild with publican 4.0.0
Version 7-32012-07-18Anthony Towns
Rebuild for Publican 3.0
Version 2.0-1Thu May 19 2011Steven Levine
Notes de mise à jour initiales de Red Hat Enterprise Linux 6.1
Résout: #549838
Support documentation pour les fonctionnalités de quota standards de Linux dans Red Hat Enterprise Linux 6.1.
Résout : #608750
Décrit plus en profondeur la description de la fonction 'withdraw' (retrait) de GFS2.
Résout : #660364
Corrige les informations sur la taille des systèmes de fichiers GFS2.
Résout : #687874
Ajout d'un nouveau chapitre sur la résolution de pannes dans GFS2.
Résout : #664848
Informations supplémentaires pour trouver des noms de chemins d'accès dépendants du contexte, avant de convertir GFS en GFS2.
Version 1.0-1Wed Nov 15 2010Steven Levine
Notes de mise à jour initiales de Red Hat Enterprise Linux 6

Index

Symboles

, quotas de disque
gestion de
la commande quotacheck, utilisée pour vérifier, Contrôler l'exactitude des quotas

A

Agrandir un système de fichiers, Agrandir un système de fichiers
ajouter une journalisation des données, Ajouter les journaux au système de fichiers
aperçu général, Présentation générale de GFS2
configuration, avant, Avant d'installer GFS2
fonctionnalités, nouvelles ou modifiées, Fonctionnalités nouvelles ou modifiées
atime, configurer les mises à jour , Configurer les mises à niveau atime
monter les fichiers avec noatime , Monter les fichiers avec noatime
monter les fichiers avec relatime , Montez les fichiers avec relatime
audience, Audience

C

commande de montage: mount, Monter un système de fichiers
commande fsck.gfs2, Réparer un système de fichiers
commentaires
informations sur les contacts pour ce manuel, Nous avons besoin de vos commentaires !
configuration, avant, Avant d'installer GFS2
configuration, initiale, Guide de démarrage
tâches préliminaires, Tâches préliminaires
Créer un système de fichier, Créer un système de fichier

G

gérer GFS2, Gérer GFS2
gestion des quotas, Gestion des Quotas GFS2, Configurer les quota en mode "enforcement" ou "accounting" (calcul des quotas), Gestion des quotas GFS2 par la commande gfs2_quota
activer les calculs de quotas, Activer le calcul des quotas
activer/désactiver l'exécution des quotas, Activer/désactiver l'exécution des quotas
affichage des limites de quotas, Afficher les limites et utilisations de quotas par la commande gfs2_quota
définir les quotas, Configurer les quotas avec la commande gfs2_quota
synchronisation des quotas, Synchroniser les quota par la commande quotasync, Synchronisation des fichiers par la commande gfs2_quota
GFS2
atime, configurer les mises à jour, Configurer les mises à niveau atime
monter les fichiers avec noatime , Monter les fichiers avec noatime
monter les fichiers avec relatime , Montez les fichiers avec relatime
fonction Withdraw, La fonctionnalité GFS2 Withdraw
gérer, Gérer GFS2
gestion des quotas, Gestion des Quotas GFS2, Configurer les quota en mode "enforcement" ou "accounting" (calcul des quotas), Gestion des quotas GFS2 par la commande gfs2_quota
activer le calcul des quotas, Activer le calcul des quotas
activer/désactiver l'exécution des quotas, Activer/désactiver l'exécution des quotas
affichage des limites de quota, Afficher les limites et utilisations de quotas par la commande gfs2_quota
définir les quotas, Configurer les quotas avec la commande gfs2_quota
synchronisation des quotas, Synchroniser les quota par la commande quotasync, Synchronisation des fichiers par la commande gfs2_quota
gfs2_grow command, Agrandir un système de fichiers
gfs2_jadd command, Ajouter les journaux au système de fichiers
gfs2_quota command, Gestion des quotas GFS2 par la commande gfs2_quota
glock holder flags, Réglage de la performance GFS2 par le Lump Dock GFS2

I

installation, initiale
tâches initiales, Tâches d'installation initiales
introduction, Introduction
audience, Audience

J

journalisation des données, Journalisation des données

L

la commande mkfs, Créer un système de fichier
la commande quotacheck
vérifier l'exactitude des quotas avec, Contrôler l'exactitude des quotas
la commande unmount, Démonter un système de fichiers

N

node locking, GFS2 Node Locking
noms de chemin dépendant du contexte (CDPN - context-dependent path names), Noms de chemins Contexte-dépendants et Montage associés

O

option acl mount, Monter un système de fichiers
Options spécifiques-GFS2 disponibles en cours d'agrandissement d'un système de fichiers, Utilisation totale
Options spécifiques-GFS2 disponibles quand on ajoute des journaux, Utilisation totale

P

points de montage associés
ordre de montage, Points de montage associés et Ordre de montage du système de fichiers
préface (voir introduction)

R

réglage de la performance, Réglage de la performance avec GFS2
réglage, performance, Réglage de la performance avec GFS2
réparation du système de fichiers, Réparer un système de fichiers

S

suspendre toute activité sur un système de fichier, Suspendre toute activité sur un système de fichier
système de fichier
gestion des quotas
affichage des limites de quotas, Afficher les limites et utilisations de quotas par la commande gfs2_quota
système de fichiers
agrandir, Agrandir un système de fichiers
ajouter des journaux, Ajouter les journaux au système de fichiers
atime, configurer les mises à jour, Configurer les mises à niveau atime
monter les fichiers avec noatime , Monter les fichiers avec noatime
monter les fichiers avec relatime , Montez les fichiers avec relatime
créer, Créer un système de fichier
démonter, Démonter un système de fichiers, Considérations spéciales à prendre en compte lorsqu'on monte des systèmes de fichiers GFS2
gestion des quotas, Gestion des Quotas GFS2, Configurer les quota en mode "enforcement" ou "accounting" (calcul des quotas), Gestion des quotas GFS2 par la commande gfs2_quota
activer les calculs de quotas, Activer le calcul des quotas
activer/désactiver l'exécution des quotas, Activer/désactiver l'exécution des quotas
définir les quotas, Configurer les quotas avec la commande gfs2_quota
synchronisation des quotas, Synchroniser les quota par la commande quotasync, Synchronisation des fichiers par la commande gfs2_quota
journalisation des données, Journalisation des données
noms de chemin dépendant du contexte (CDPN - context-dependent path names), Noms de chemins Contexte-dépendants et Montage associés
ordre de montage, Points de montage associés et Ordre de montage du système de fichiers
points de montage associés, Noms de chemins Contexte-dépendants et Montage associés
réparation, Réparer un système de fichiers
suspendre les activités, Suspendre toute activité sur un système de fichier
système suspendu au démontage, Considérations spéciales à prendre en compte lorsqu'on monte des systèmes de fichiers GFS2

T

tableau
options de montage, Utilisation totale
tableau de montage, Utilisation totale
tableaux
mkfs.gfs2options de commande, Toutes Options
Options spécifiques-GFS2 disponibles quand on ajoute des journaux, Utilisation totale
options spécifiques-GFS2 pour agrandir les systèmes de fichiers, Utilisation totale
tâches initiales
installation, initiale, Tâches d'installation initiales
tâches préliminaires
configuration, initiale, Tâches préliminaires
taille maximum de systèmes de fichiers GFS2, Présentation générale de GFS2
taille maximum, systèmes de fichiers GFS2, Présentation générale de GFS2
types de glock, Réglage de la performance GFS2 par le Lump Dock GFS2

Note légale

Copyright © 2011 Red Hat, Inc. and others.
This document is licensed by Red Hat under the Creative Commons Attribution-ShareAlike 3.0 Unported License. If you distribute this document, or a modified version of it, you must provide attribution to Red Hat, Inc. and provide a link to the original. If the document is modified, all Red Hat trademarks must be removed.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.