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 :

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.