Ce chapitre décrit les méthodes d'identification et de résolution des pannes de ZFS. Des informations relatives à la prévention des pannes sont également fournies.
Il contient les sections suivantes :
En tant que système de fichiers et gestionnaire de volumes combinés, ZFS peut rencontrer différentes pannes. Ce chapitre commence par une description des différentes pannes, puis explique comment les identifier sur un système en cours d'exécution. Il se conclut en expliquant comment résoudre les problèmes. Le système de fichiers ZFS peut rencontrer trois types d'erreurs de base :
Notez que les trois types d'erreurs peuvent se produire dans un même pool. Une procédure de réparation complète implique de trouver et de corriger une erreur, de passer à la suivante et ainsi de suite.
Si un périphérique est supprimé du système, ZFS détecte que son ouverture est impossible et le met en état REMOVED. En fonction du niveau de réplication des données du pool, ce retrait peut résulter ou non en une indisponibilité de la totalité du pool. Le pool reste accessible en cas de suppression d'un périphérique mis en miroir ou RAID-Z. Un pool peut renvoyer l'état FAULTED. Cela signifie qu'aucune donnée n'est accessible jusqu'à ce que le périphérique soit reconnecté selon les conditions suivantes :
si tous les composants d'un miroir sont supprimés ;
si plusieurs périphériques d'un périphérique RAID-Z (raidz1) sont supprimés ;
si le périphérique de niveau supérieur est supprimé dans une configuration contenant un seul disque.
Le terme " endommagé " fait référence à une grande variété d'erreurs possibles. Les exemples incluent les éléments suivants :
erreurs d'E/S transitoires causées par un disque ou un contrôleur défaillant ;
corruption de données sur disque causée par les rayons cosmiques ;
bogues de pilotes entraînant des transferts de données vers ou à partir d'un emplacement erroné ;
écrasement accidentel de parties du périphérique physique par un utilisateur.
Certaines erreurs sont transitoires, par exemple une erreur d'E/S aléatoire alors que le contrôleur rencontre des problèmes. Dans d'autres cas, les dommages sont permanents, par exemple lors de la corruption sur disque. En outre, même si les dommages sont permanents, cela ne signifie pas que l'erreur est susceptible de se reproduire. Par exemple, si un administrateur écrase une partie d'un disque par accident, aucune panne matérielle ne s'est produite et il est inutile de remplacer le périphérique. L'identification du problème exact dans un périphérique n'est pas une tâche aisée. Elle est abordée plus en détail dans une section ultérieure.
La corruption de données se produit lorsqu'une ou plusieurs erreurs de périphériques (indiquant un ou plusieurs périphériques manquants ou endommagés) affectent un périphérique virtuel de niveau supérieur. Par exemple, la moitié d'un miroir peut subir des milliers d'erreurs sans jamais causer de corruption de données. Si une erreur se produit sur l'autre côté du miroir au même emplacement, les données sont alors endommagées.
La corruption de données est toujours permanente et nécessite une soin particulier lors de la réparation. Même en cas de réparation ou de remplacement des périphériques sous-jacents, les données d'origine sont irrémédiablement perdues. La plupart du temps, ce scénario requiert la restauration des données à partir de sauvegardes. Les erreurs de données sont enregistrées à mesure qu'elles sont détectées et peuvent être contrôlées à l'aide de nettoyages de pools de routine, comme expliqué dans la section suivante. Lorsqu'un bloc corrompu est supprimé, le nettoyage de disque suivant reconnaît que la corruption n'est plus présente et supprime toute trace de l'erreur dans le système.
Il n'existe pas d'utilitaire fsck équivalent pour ZFS. Cet utilitaire remplissait deux fonctions : réparer et valider le système de fichiers.
Avec les systèmes de fichiers classiques, la méthode d'écriture des données est affectée par les pannes inattendues entraînant des incohérences de systèmes de fichiers. Un système de fichiers classique n'étant pas transactionnel, les blocs non référencés, les comptes de liens défectueux ou autres structures de systèmes de fichiers incohérentes sont possibles. L'ajout de la journalisation résout certains de ces problèmes, mais peut entraîner des problèmes supplémentaires lorsque la restauration du journal est impossible. Une incohérence des données sur disque dans une configuration ZFS ne se produit qu'à la suite d'une panne de matérielle (auquel cas le pool aurait dû être redondant) ou en présence d'un bogue dans le logiciel ZFS.
L'utilitaire fsck répare les problèmes connus spécifiques aux systèmes de fichiers UFS. La plupart des problèmes au niveau des pools de stockage ZFS sont généralement liés à un matériel défaillant ou à des pannes de courant. En utilisant des pools redondants, vous pouvez éviter de nombreux problèmes. Si le pool est endommagé suite à une défaillance de matériel ou à une coupure de courant, reportez-vous à la section Réparation de dommages présents dans l'ensemble du pool de stockage ZFS.
Si le pool n'est pas redondant, le risque qu'une corruption de système de fichiers puisse rendre tout ou partie de vos données inaccessibles est toujours présent.
Outre la réparation du système de fichiers, l'utilitaire fsck valide l'absence de problème relatif aux données sur le disque. Cette tâche requiert habituellement le démontage du système de fichiers et en l'exécution de l'utilitaire fsck, éventuellement en mettant le système en mode utilisateur unique lors du processus. Ce scénario entraîne une indisponibilité proportionnelle à la taille du système de fichiers en cours de vérification. Plutôt que de requérir un utilitaire explicite pour effectuer la vérification nécessaire, ZFS fournit un mécanisme pour effectuer une vérification de routine des incohérences. Cette fonctionnalité, appelée nettoyage, est fréquemment utilisée dans les systèmes de mémoire et autres systèmes comme méthode de détection et de prévention d'erreurs pour éviter qu'elles entraînent des pannes matérielles ou logicielles.
Si ZFS rencontre une erreur, soit via le nettoyage ou lors de l'accès à un fichier à la demande, l'erreur est journalisée en interne pour vous donner une vue d'ensemble rapide de toutes les erreurs connues au sein du pool.
La façon la plus simple de vérifier l'intégrité des données est de lancer un nettoyage explicite de toutes les données au sein du pool. Cette opération traverse toutes les données dans le pool une fois et vérifie que tous les blocs sont lisibles. Le nettoyage va aussi vite que le permettent les périphériques, mais la priorité de toute E/S reste inférieure à celle de toute opération normale. Cette opération peut affecter les performances, bien que les données du pool restent utilisables et leur réactivité quasiment la même lors du nettoyage. La commande zpool scrubpermet de lancer un nettoyage explicite. Exemple :
# zpool scrub tank |
La commande zpool status ne permet pas d'afficher l'état de l'opération de nettoyage actuelle. Exemple :
# zpool status -v tank pool: tank state: ONLINE scrub: scrub completed after 0h7m with 0 errors on Tue Tue Feb 2 12:54:00 2010 config: NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 mirror-0 ONLINE 0 0 0 c1t0d0 ONLINE 0 0 0 c1t1d0 ONLINE 0 0 0 errors: No known data errors |
Une seule opération de nettoyage actif par pool peut se produire à la fois.
L'option -s permet d'interrompre une opération de nettoyage en cours. Exemple :
# zpool scrub -s tank |
Dans la plupart des cas, une opération de nettoyage pour assurer l'intégrité des données doit être menée à son terme. Vous pouvez cependant interrompre une telle opération si les performances du système sont affectées.
Un nettoyage de routine garantit des E/S continues pour l'ensemble des disques du système. Cet opération a cependant pour effet secondaire d'empêcher la gestion de l'alimentation de placer des disques inactifs en mode basse consommation. Si le système réalise en général des E/S en permanence, ou si la consommation n'est pas une préoccupation, ce problème peut être ignoré.
Pour de plus amples informations sur l'interprétation de la sortie de zpool status, reportez-vous à la section Requête d'état de pool de stockage ZFS.
Lors du remplacement d'un périphérique, une opération de réargenture est amorcée pour déplacer les données des copies correctes vers le nouveau périphérique. Cette action est une forme de nettoyage de disque. Par conséquent, une seule action de ce type peut être effectuée à un moment donné dans le pool. Lorsqu'une opération de nettoyage est en cours, toute opération de resynchronisation suspend le nettoyage et le redémarre une fois qu'elle a terminé.
Pour de plus amples informations sur la resynchronisation, reportez-vous à la section Affichage de l'état de réargenture.
Les sections suivantes décrivent l'identification et la résolution des problèmes dans les systèmes de fichiers ZFS ou les pools de stockage :
Les fonctions suivantes permettent d'identifier les problèmes au sein de la configuration ZFS :
La commande zpool status permet d'afficher les informations détaillées des pools de stockage ZFS.
Les défaillances de pool et de périphérique sont rapportées par le biais de messages de diagnostics ZFS/FMA.
La commande zpool history permet d'afficher les commandes ZFS précédentes qui ont modifié les informations d'état de pool.
La commande zpool status permet de résoudre la plupart des problèmes au niveau de ZFS. Cette commande analyse les différentes erreurs système et identifie les problèmes les plus sévères. En outre, elle propose des actions à effectuer et un lien vers un article de connaissances pour de plus amples informations. Notez que cette commande n'identifie qu'un seul problème dans le pool, même si plusieurs problèmes existent. Par exemple, les erreurs de corruption de données sont généralement provoquées par la panne d'un périphérique, mais le remplacement d'un périphérique défaillant peut ne pas résoudre tous les problèmes de corruption de données.
En outre, un moteur de diagnostic ZFS diagnostique et signale les défaillances au niveau du pool et des périphériques. Les erreurs liées aux sommes de contrôle, aux E/S, aux périphériques et aux pools font également l'objet d'un rapport lorsqu'elles sont liées à ces défaillances. Les défaillances ZFS telles que rapportées par fmd s'affichent sur la console ainsi que les dans le fichier de messages système. Dans la plupart des cas, le message fmd vous dirige vers la commande zpool status pour obtenir des instructions supplémentaires de récupération.
Le processus de récupération est comme décrit ci-après :
Le cas échéant, la commande zpool history permet d'identifier les commandes ZFS ayant précédé le scénario d'erreur. Exemple :
# zpool history tank History for 'tank': 2010-07-15.12:06:50 zpool create tank mirror c0t1d0 c0t2d0 c0t3d0 2010-07-15.12:06:58 zfs create tank/erick 2010-07-15.12:07:01 zfs set checksum=off tank/erick |
Dans cette sortie, notez que les sommes de contrôle sont désactivées pour le système de fichiers tank/erick. Cette configuration est déconseillée.
Identifiez les erreurs à l'aide des messages fmd affichés sur la console système ou dans le fichier /var/adm/messages.
Obtenez des instructions de réparation supplémentaires grâce à la commande zpool status -x.
Réparez les pannes. Pour ce faire, suivez les étapes suivantes :
Remplacez le périphérique défaillant ou manquant et mettez-le en ligne.
Restaurez la configuration défaillante ou les données corrompues à partir d'une sauvegarde.
Vérifiez la récupération à l'aide de la commande zpool status - x.
Sauvegardez la configuration restaurée, le cas échéant.
Cette section explique comment interpréter la sortie zpool status afin de diagnostiquer le type de défaillances pouvant survenir. Même si la commande effectue automatiquement le travail, vous devez comprendre exactement les problèmes identifiés pour diagnostiquer la panne. Les sections suivantes expliquent comment corriger les différents types de problèmes que vous risquez de rencontrer.
La méthode la plus simple pour déterminer s'il existe des problèmes connus sur le système consiste à exécuter la commande zpool status -x. Cette commande décrit uniquement les pools présentant des problèmes. Si tous les pools du système fonctionnent correctement, la commande affiche les éléments suivants :
# zpool status -x all pools are healthy |
Sans l'indicateur -x, la commande affiche l'état complet de tous les pools (ou du pool demandé s'il est spécifié sur la ligne de commande), même si les pools sont autrement fonctionnels.
Pour de plus amples informations sur les options de ligne de commande de la commande zpool status, reportez-vous à la section Requête d'état de pool de stockage ZFS.
La sortie complète de zpool status est similaire à ce qui suit :
# zpool status tank # zpool status tank pool: tank state: DEGRADED status: One or more devices could not be opened. Sufficient replicas exist for the pool to continue functioning in a degraded state. action: Attach the missing device and online it using 'zpool online'. see: http://www.sun.com/msg/ZFS-8000-2Q scrub: none requested config: NAME STATE READ WRITE CKSUM tank DEGRADED 0 0 0 mirror-0 DEGRADED 0 0 0 c1t0d0 ONLINE 0 0 0 c1t1d0 UNAVAIL 0 0 0 cannot open errors: No known data errors |
Cette sortie est décrite ci-dessous :
Cette section de la sortie zpool status se compose des champs suivants, certains d'entre eux n'étant affichés que pour les pools présentant des problèmes :
Identifie le nom du pool.
Indique l'état de maintenance actuel du pool. Ces informations concernent uniquement la capacité de pool à fournir le niveau de réplication requis.
Décrit les problèmes du pool. Ce champ est absent si aucune erreur n'est détectée.
Action recommandée pour la réparation des erreurs. Ce champ est absent si aucune erreur n'est détectée.
Fait référence à un article de connaissances contenant des informations de réparation détaillées. Les articles en ligne sont mis à jour plus régulièrement que ce guide. Par conséquent, vous devez vous y reporter pour obtenir les procédures de réparation les plus récentes. Ce champ est absent si aucune erreur n'est détectée.
Identifie l'état actuel d'une opération de nettoyage. Ce champ peut indiquer la date et l'heure du dernier nettoyage, un nettoyage en cours ou l'absence de requête de nettoyage.
Identifie les erreurs de données ou l'absence d'erreurs de données connues.
Le champ config de la sortie zpool status décrit la configuration des périphériques inclus dans le pool, ainsi que leur état et toute erreur générée à partir des périphériques. L'état peut être l'un des suivants : ONLINE, FAULTED, DEGRADED, UNAVAILABLE ou OFFLINE. Si l'état n'est pas ONLINE, la tolérance de pannes du pool a été compromise.
La deuxième section de la sortie de configuration affiche des statistiques d'erreurs. Ces erreurs se divisent en trois catégories :
READ : erreurs d'E/S qui se sont produites lors de l'envoi d'une requête de lecture
WRITE : erreurs d'E/S qui se sont produites lors de l'envoi d'une requête d'écriture
CKSUM : erreurs de somme de contrôle signifiant que le périphérique a renvoyé des données corrompues en réponse à une demande de lecture.
Il est possible d'utiliser ces erreurs pour déterminer si les dommages sont permanents. Des erreurs d'E/S peu nombreuses peuvent indiquer une interruption de service temporaire. Si elles sont nombreuses, il est possible que le périphérique présente un problème permanent. Ces erreurs ne correspondent pas nécessairement à la corruption de données telle qu'interprétée par les applications. Si la configuration du périphérique est redondante, les périphériques peuvent présenter des erreurs impossibles à corriger, même si aucune erreur ne s'affiche au niveau du périphérique RAID-Z ou du miroir. Dans ce cas, ZFS a récupéré les données correctes et a réussi à réparer les données endommagées à partir des répliques existantes.
Pour de plus amples informations sur l'interprétation de ces erreurs, reportez-vous à la section Détermination du type de panne de périphérique.
Enfin, les informations auxiliaires supplémentaire sont affichées dans la dernière colonne de la sortie de zpool status. Ces informations s'étendent dans le champ state et facilitent le diagnostic des pannes. Si l'état d'un périphérique est FAULTED, ce champ indique si périphérique est inaccessible ou si les données du périphérique sont corrompues. Si le périphérique est en cours de resynchronisation, ce champ affiche la progression du processus.
Pour de plus amples informations sur le contrôle de la progression de la resynchronisation, reportez-vous à la section Affichage de l'état de réargenture.
La section sur le nettoyage de la sortie zpool status décrit l'état actuel de toute opération de nettoyage explicite. Ces informations sont distinctes de la détection d'erreurs dans le système, mais il est possible de les utiliser pour déterminer l'exactitude du rapport d'erreurs de corruption de données. Si le dernier nettoyage s'est récemment terminé, toute corruption de données existante aura probablement déjà été détecté.
Les messages de fin de nettoyage subsistent après plusieurs réinitialisations du système.
Pour de plus amples informations sur le nettoyage de données et l'interprétation de ces informations, reportez-vous à la section Contrôle de l'intégrité d'un système de fichiers ZFS.
La commande zpool status indique également si des erreurs connues sont associées au pool. La détection de ces erreurs a pu s'effectuer lors du nettoyage des données ou lors des opérations normales. Le système de fichiers ZFS gère un journal persistant de toutes les erreurs de données associées à un pool. Ce journal tourne à chaque fois qu'un nettoyage complet du système est terminé.
Les erreurs de corruption de données constituent toujours des erreurs fatales. Elles indiquent une erreur d'E/S dans au moins une application, en raison de la présence de données corrompues au sein du pool. Les erreurs de périphérique dans un pool redondant n'entraînent pas de corruption de données et ne sont pas enregistrées en tant que partie de ce journal. Par défaut, seul le nombre d'erreurs trouvées s'affiche. Vous pouvez obtenir la liste complète des erreurs et de leurs spécificités à l'aide de l'option zpool status -v. Exemple :
# zpool status -v pool: tank state: UNAVAIL status: One or more devices are faulted in response to IO failures. action: Make sure the affected devices are connected, then run 'zpool clear'. see: http://www.sun.com/msg/ZFS-8000-HC scrub: scrub completed after 0h0m with 0 errors on Tue Feb 2 13:08:42 2010 config: NAME STATE READ WRITE CKSUM tank UNAVAIL 0 0 0 insufficient replicas c1t0d0 ONLINE 0 0 0 c1t1d0 UNAVAIL 4 1 0 cannot open errors: Permanent errors have been detected in the following files: /tank/data/aaa /tank/data/bbb /tank/data/ccc |
La commande fmd affiche également un message similaire dans la console système et le fichier /var/adm/messages. La commande fmdump permet également de réaliser le suivi de ces messages.
Pour de plus amples informations sur l'interprétation d'erreurs de corruption de données, reportez-vous à la section Identification du type de corruption de données.
Outre le suivi permanent des erreur au sein du pool, ZFS affiche également des messages syslog lorsque des événements intéressants se produisent. Les scénarios suivants génèrent des événements pour notifier l'administrateur :
Transition d'état de périphérique – Si l'état d'un périphérique devient FAULTED, ZFS consigne un message indiquant que la tolérance de pannes du pool risque d'être compromise. Un message similaire est envoyé si le périphérique est mis en ligne ultérieurement, restaurant la maintenance du pool.
Corruption de données – En cas de détection de corruption de données, ZFS consigne un message indiquant où et quand s'est produit la détection. Ce message n'est consigné que lors de la première détection. Les accès ultérieurs ne génèrent pas de message.
Défaillances de pool et de périphérique : en cas de défaillance d'un pool ou d'un périphérique, le démon du gestionnaire de pannes rapporte ces erreurs par le biais de messages syslog et de la commande fmdump.
Si ZFS détecte un erreur de périphérique et la corrige automatiquement, aucune notification n'est générée. De telles erreurs ne constituent pas une défaillance de redondance de pool ou de l'intégrité des données. En outre, de telles erreurs sont typiquement dues à un problème de pilote accompagné de son propre jeu de messages d'erreur.
ZFS gère un cache de pools actifs et les configurations correspondantes dans le système de fichiers racine. Si ce fichier de cache est corrompu ou n'est plus synchronisé avec les informations de configuration stockées dans le disque, l'ouverture du pool n'est plus possible. Le système de fichiers ZFS tente d'éviter cette situation, même si des corruptions arbitraires peuvent toujours survenir en raison des caractéristiques du système de fichiers sous-jacent et du stockage. En général, cette situation est due à la disparition d'un pool du système alors qu'il devrait être disponible. Parfois, elle correspond à une configuration partielle, dans laquelle il manque un nombre inconnu de périphériques virtuels de niveau supérieur. Quel que soit le cas, la configuration peut être récupérée en exportant le pool (s'il est visible à tous) et en le réimportant.
Pour de plus amples informations sur l'importation et l'exportation de pools, reportez-vous à la section Migration de pools de stockage ZFS.
Si l'ouverture d'un périphérique est impossible, ce dernier s'affiche dans l'état UNAVAIL dans la sortie de zpool status. Cet état indique que ZFS n'a pas pu ouvrir le périphérique lors du premier accès au pool ou que le périphérique est devenu indisponible par la suite. Si le périphérique rend un périphérique de niveau supérieur indisponible, l'intégralité du pool devient inaccessible. Dans le cas contraire, la tolérance de pannes du pool risque d'être compromise. Quel que soit le cas, le périphérique doit simplement être reconnecté au système pour refonctionner normalement.
Par exemple, après une panne de périphérique, fmd peut afficher un message similaire au suivant :
SUNW-MSG-ID: ZFS-8000-FD, TYPE: Fault, VER: 1, SEVERITY: Major EVENT-TIME: Thu Jun 24 10:42:36 PDT 2010 PLATFORM: SUNW,Sun-Fire-T200, CSN: -, HOSTNAME: neo2 SOURCE: zfs-diagnosis, REV: 1.0 EVENT-ID: a1fb66d0-cc51-cd14-a835-961c15696fcb DESC: The number of I/O errors associated with a ZFS device exceeded acceptable levels. Refer to http://sun.com/msg/ZFS-8000-FD for more information. AUTO-RESPONSE: The device has been offlined and marked as faulted. An attempt will be made to activate a hot spare if available. IMPACT: Fault tolerance of the pool may be compromised. REC-ACTION: Run 'zpool status -x' and replace the bad device. |
Pour afficher des informations détaillées sur le problème du périphérique et sa résolution, utilisez la commande zpool status -x. Exemple :
# zpool status -x pool: tank state: DEGRADED status: One or more devices could not be opened. Sufficient replicas exist for the pool to continue functioning in a degraded state. action: Attach the missing device and online it using 'zpool online'. see: http://www.sun.com/msg/ZFS-8000-2Q scrub: scrub completed after 0h0m with 0 errors on Tue Feb 2 13:15:20 2010 config: NAME STATE READ WRITE CKSUM tank DEGRADED 0 0 0 mirror-0 DEGRADED 0 0 0 c1t0d0 ONLINE 0 0 0 c1t1d0 UNAVAIL 0 0 0 cannot open errors: No known data errors |
Cette sortie indique que le périphérique c1t1d0 manquant ne fonctionne pas. Si vous estimez que le périphérique est défectueux, remplacez-le.
Exécutez ensuite la commande zpool online pour mettre le périphérique remplacé en ligne. Exemple :
# zpool online tank c1t1d0 |
Confirmez ensuite que le pool dont le périphérique a été remplacé fonctionne correctement. Exemple :
# zpool status -x tank pool 'tank' is healthy |
La reconnexion d'un périphérique dépend du périphérique en question. S'il s'agit d'un disque connecté au réseau, la connectivité au réseau doit être restaurée. S'il s'agit d'un périphérique USB ou autre support amovible, il doit être reconnecté au système. S'il s'agit d'un disque local, un contrôleur est peut-être tombé en panne, rendant le périphérique invisible au système. Dans ce cas, il faut remplacer le contrôleur pour que les disques soient à nouveau disponibles. D'autres problèmes existent et dépendent du type de matériel et de sa configuration. Si un disque tombe en panne et n'est plus visible pour le système, le périphérique doit être traité comme un périphérique endommagé. Suivez les procédures décrites dans la section Remplacement ou réparation d'un périphérique endommagé .
Une fois le périphérique reconnecté au système, sa disponibilité peut être détectée automatiquement ou non dans ZFS. Si le pool était précédemment défaillant ou si le system a été réinitialisé en tant que partie de la procédure attach, alors ZFS rebalaye automatiquement tous les périphériques lors de la tentative d'ouverture du pool. Si le pool était endommagé et que le périphérique a été remplacé alors que le système était en cours d'exécution, vous devez indiquer à ZFS que le périphérique est dorénavant disponible et qu'il est prêt à être rouvert à l'aide de la commande zpool online. Exemple :
# zpool online tank c0t1d0 |
Pour de plus amples informations sur la remise en ligne de périphériques, reportez-vous à la section Mise en ligne d'un périphérique.
Cette section explique comment déterminer les types de panne de périphériques, effacer les erreurs transitoires et remplacer un périphérique.
Le terme périphérique endommagé peut décrire un grand nombre de situations :
Bit rot : sur la durée, des événements aléatoires, tels que les influences magnétiques et les rayons cosmiques, peuvent entraîner une inversion des bits stockés dans le disque. Ces événements sont relativement rares mais, cependant, assez courants pour entraîner des corruptions de données potentielles dans des systèmes de grande taille ou de longue durée.
Lectures ou écritures mal dirigées – Les bogues de microprogrammes ou les pannes de matériel peuvent entraîner un référencement incorrect de l'emplacement du disque par des lectures ou écritures de blocs entiers. Ces erreurs sont généralement transitoires, mais un grand nombre d'entre elles peut indiquer un disque défectueux.
Erreur d'administrateur : les administrateurs peuvent écraser par erreur des parties du disque avec des données erronées (la copie de /dev/zero sur des parties du disque, par exemple) qui entraînent la corruption permanente du disque. Ces erreurs sont toujours transitoires.
Interruption temporaire de service : un disque peut être temporairement indisponible, entraînant l'échec des E/S. En général, cette situation est associée aux périphériques connectés au réseau, mais les disques locaux peuvent également connaître des interruptions temporaires de service. Ces erreurs peuvent être transitoires ou non.
Matériel défectueux ou peu fiable : cette situation englobe tous les problèmes liés à un matériel défectueux, y compris les erreurs d'E/S cohérentes, les transports défectueux entraînant des corruptions aléatoires ou des pannes. Ces erreurs sont typiquement permanentes.
Périphérique mis hors ligne : si un périphérique est hors ligne, il est considéré comme ayant été mis hors ligne par l'administrateur, parce qu'il était défectueux. L'administrateur qui a mis ce dispositif hors ligne peut déterminer si cette hypothèse est exacte.
Il est parfois difficile de déterminer la nature exacte de la panne du dispositif. La première étape consiste à examiner le décompte d'erreurs dans la sortie de zpool status. Exemple :
# zpool status -v tpool pool: tpool state: ONLINE status: One or more devices has experienced an error resulting in data corruption. Applications may be affected. action: Restore the file in question if possible. Otherwise restore the entire pool from backup. see: http://www.sun.com/msg/ZFS-8000-8A scrub: scrub completed after 0h0m with 2 errors on Tue Jul 13 11:08:37 2010 config: NAME STATE READ WRITE CKSUM tpool ONLINE 2 0 0 c1t1d0 ONLINE 2 0 0 c1t3d0 ONLINE 0 0 0 errors: Permanent errors have been detected in the following files: /tpool/words |
Les erreurs sont divisées en erreurs d'E/S et en erreurs de sommes de contrôle. Ces deux catégories peuvent indiquer le type de panne possible. Une opération typique renvoie un très petit nombre d'erreurs (quelques-unes sur une longue période). Si les erreurs sont nombreuses, un périphérique est probablement en panne ou sur le point de tomber en panne. Cependant, une erreur provoquée par un administrateur peut également entraîner un grand nombre d'erreurs. Le journal système syslog constitue une autre source d'informations. Si le journal présente un grand nombre de messages SCSI ou de pilote Fibre Channel, il existe probablement de graves problèmes matériels. L'absence de messages syslog indique que les dommages sont probablement transitoires.
L'objectif est de répondre à la question suivante :
Est-il possible qu'une autre erreur se produise dans ce périphérique ?
Les erreurs qui ne se produisent qu'une fois sont considérées transitoires et n'indiquent pas une panne potentielle. Les erreurs suffisamment persistantes ou sévères pour indiquer une panne matérielle potentielle sont considérées comme étant des erreurs fatales. Aucun logiciel automatisé actuellement disponible avec ZFS ne permet de déterminer le type d'erreur. Par conséquent, l'administrateur doit procéder manuellement. Une fois l'erreur déterminée, vous pouvez réaliser l'action adéquate. En cas d'erreurs fatales, effacez les erreurs transitoires ou remplacez le périphérique. Ces procédures de réparation sont décrites dans les sections suivantes.
Même si les erreurs de périphériques sont considérées comme étant transitoires, elles peuvent tout de même entraîner des erreurs de données impossibles à corriger au sein du pool. Ces erreurs requièrent des procédures de réparation spéciales, même si le périphérique sous-jacent est considéré comme étant fonctionnel ou réparé. Pour de plus amples informations sur la réparation d'erreurs de données, reportez-vous à la section Réparation de données endommagées.
Si les erreurs de périphérique sont considérées comme étant transitoires, dans la mesure où il est peu probable qu'elles affectent la maintenance du périphérique, elles peuvent être effacées en toute sécurité pour indiquer qu'aucune erreur fatale ne s'est produite. Pour effacer les compteurs d'erreurs pour les périphériques mis en miroir ou RAID-Z, utilisez la commande zpool clear. Exemple :
# zpool clear tank c1t1d0 |
Cette syntaxe efface toutes les erreurs du périphérique et tout décompte d'erreurs de données associées au périphérique.
Pour effacer toutes les erreurs associées aux périphériques virtuels du pool et tout décompte d'erreurs de données associées au pool, utilisez la syntaxe suivante :
# zpool clear tank |
Pour de plus amples informations relatives à la suppression des erreurs de pool, reportez-vous à la section Effacement des erreurs de périphérique de pool de stockage.
Si le périphérique présente ou risque de présenter une panne permanente, il doit être remplacé. Le remplacement du périphérique dépend de la configuration.
Pour qu'un périphérique puisse être remplacé, l'état du pool doit être ONLINE. Le périphérique doit faire partie d'une configuration redondante ou être fonctionnel (état ONLINE). Si le périphérique fait partie d'une configuration redondante, il doit exister suffisamment de répliques pour permettre la récupération des données correctes. Si deux disques d'un miroir à quatre directions sont défaillants, chaque disque peut être remplacé car des répliques fonctionnelles sont disponibles. Cependant, en cas de panne de deux disques dans un périphérique virtuel RAID-Z à quatre directions (raid-z), aucun disque ne peut être remplacé en l'absence de répliques suffisantes permettant de récupérer les données. Si le périphérique est endommagé mais en ligne, il peut être remplacé tant que l'état du pool n'est pas FAULTED. Toutefois, toute donnée endommagée sur le périphérique est copiée sur le nouveau périphérique, à moins que le nombre de copies des données non endommagées soit déjà suffisant.
Dans la configuration suivante, le disque c1t1d0 peut être remplacé et toute donnée du pool est copiée à partir de la réplique saine, c1t0d0.
mirror DEGRADED c1t0d0 ONLINE c1t1d0 FAULTED |
Le disque c1t0d0 peut également être remplacé, mais un autorétablissement des données est impossible, car il n'existe aucune réplique correcte.
Dans la configuration suivante, aucun des disques défaillants ne peut être remplacé. Les disques ONLINE ne peuvent pas l'être non plus, car le pool lui-même est défaillant.
raidz FAULTED c1t0d0 ONLINE c2t0d0 FAULTED c3t0d0 FAULTED c4t0d0 ONLINE |
Dans la configuration suivante, chacun des disques de niveau supérieur peut être remplacé. Cependant, les données incorrectes seront également copiées dans le nouveau disque, le cas échéant.
c1t0d0 ONLINE c1t1d0 ONLINE |
Si les deux disques sont défectueux, alors tout remplacement est impossible car le pool lui-même est défectueux.
Si la perte d'un périphérique entraîne une défaillance du pool ou si le périphérique contient trop d'erreurs de données dans une configuration non redondante, alors le remplacement du périphérique en toute sécurité est impossible. En l'absence de redondance suffisante, il n'existe pas de données correctes avec lesquelles réparer le périphérique défectueux. Dans ce cas, la seule option est de détruire le pool, recréer la configuration et restaurer les données à partir d'une copie de sauvegarde.
Pour de plus amples informations sur la restauration d'un pool entier, reportez-vous à la section Réparation de dommages présents dans l'ensemble du pool de stockage ZFS.
Après avoir déterminé qu'il est possible de remplacer un périphérique, exécutez la commande zpool replace pour le remplacer effectivement. Exécutez la commande suivante si vous remplacez le périphérique endommagé par un autre périphérique différent :
# zpool replace tank c1t1d0 c2t0d0 |
Cette commande lance la migration de données vers le nouveau périphérique, soit à partir du périphérique endommagé, soit à partir d'autres périphériques du pool s'il s'agit d'une configuration redondante. Une fois l'exécution de la commande terminée, le périphérique endommagé est séparé de la configuration. Il peut dorénavant être retiré du système. Si vous avez déjà retiré le périphérique et que vous l'avez remplacé par un autre dans le même emplacement, utilisez la forme "périphérique unique" de la commande. Exemple :
# zpool replace tank c1t1d0 |
Cette commande formate adéquatement un disque non formaté et resynchronise ensuite les données à partir du reste de la configuration.
Pour de plus amples informations sur la commande zpool replace reportez-vous à la section Remplacement de périphériques dans un pool de stockage.
L'exemple suivant illustre le remplacement d'un périphérique (c1t3d0) du pool de stockage en miroir tank sur un système Oracle Sun Fire x4500. Pour remplacer le disque c1t3d0 par un nouveau au même emplacement (c1t3d0), annulez la configuration du disque avant de procéder au remplacement. Voici les principales étapes à suivre :
Déconnectez le disque (c1t3d0) à remplacer. Vous ne pouvez pas annuler la configuration d'un disque utilisé.
Utilisez la commande cfgadm pour identifier le disque (c1t3d0) dont la configuration doit être annulée et annulez-la. Dans cette configuration en miroir, le pool est endommagé et le disque est hors ligne, mais le pool reste disponible.
Remplacez le disque (c1t3d0). Vérifiez que la DEL bleue Ready to Remove, indiquant que le périphérique est prêt à être retiré, est allumée avant de retirer le lecteur défaillant.
Reconfigurez le disque (c1t3d0).
Mettez le nouveau disque (c1t3d0) en ligne.
Exécutez la commande zpool replace pour remplacer le disque (c1t3d0).
Si vous avez précédemment défini la propriété de pool autoreplace sur on, tout nouveau périphérique détecté au même emplacement physique qu'un périphérique appartenant précédemment au pool est automatiquement formaté et remplacé sans recourir à la commande zpool replace. Cette fonction n'est pas prise en charge sur tous les types de matériel.
Si un disque défectueux est automatiquement remplacé par un disque hot spare, vous devrez peut-être déconnecter le disque hot spare une fois le disque défectueux remplacé. Par exemple, si c2t4d0 reste actif comme disque hot spare actif une fois le disque défectueux remplacé, déconnectez-le.
# zpool detach tank c2t4d0 |
L'exemple suivant explique étape par étape comment remplacer un disque dans un pool de stockage ZFS.
# zpool offline tank c1t3d0 # cfgadm | grep c1t3d0 sata1/3::dsk/c1t3d0 disk connected configured ok # cfgadm -c unconfigure sata1/3 Unconfigure the device at: /devices/pci@0,0/pci1022,7458@2/pci11ab,11ab@1:3 This operation will suspend activity on the SATA device Continue (yes/no)? yes # cfgadm | grep sata1/3 sata1/3 disk connected unconfigured ok <Physically replace the failed disk c1t3d0> # cfgadm -c configure sata1/3 # cfgadm | grep sata1/3 sata1/3::dsk/c1t3d0 disk connected configured ok # zpool online tank c1t3d0 # zpool replace tank c1t3d0 # zpool status tank pool: tank state: ONLINE scrub: resilver completed after 0h0m with 0 errors on Tue Feb 2 13:17:32 2010 config: NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 mirror-0 ONLINE 0 0 0 c0t1d0 ONLINE 0 0 0 c1t1d0 ONLINE 0 0 0 mirror-1 ONLINE 0 0 0 c0t2d0 ONLINE 0 0 0 c1t2d0 ONLINE 0 0 0 mirror-2 ONLINE 0 0 0 c0t3d0 ONLINE 0 0 0 c1t3d0 ONLINE 0 0 0 errors: No known data errors |
Notez que la commande zpool output affiche parfois l'ancien disque et le nouveau sous l'en-tête de remplacement. Exemple :
replacing DEGRADED 0 0 0 c1t3d0s0/o FAULTED 0 0 0 c1t3d0 ONLINE 0 0 0 |
Ce texte signifie que la procédure de remplacement et la resynchronisation du nouveau disque sont en cours.
Pour remplacer un disque (c1t3d0) par un autre disque (c4t3d0), il suffit d'exécuter la commande zpool replace. Exemple :
# zpool replace tank c1t3d0 c4t3d0 # zpool status pool: tank state: DEGRADED scrub: resilver completed after 0h0m with 0 errors on Tue Feb 2 13:35:41 2010 config: NAME STATE READ WRITE CKSUM tank DEGRADED 0 0 0 mirror-0 ONLINE 0 0 0 c0t1d0 ONLINE 0 0 0 c1t1d0 ONLINE 0 0 0 mirror-1 ONLINE 0 0 0 c0t2d0 ONLINE 0 0 0 c1t2d0 ONLINE 0 0 0 mirror-2 DEGRADED 0 0 0 c0t3d0 ONLINE 0 0 0 replacing DEGRADED 0 0 0 c1t3d0 OFFLINE 0 0 0 c4t3d0 ONLINE 0 0 0 errors: No known data errors |
La commande zpool status doit parfois être exécutée plusieurs fois jusqu'à la fin du remplacement du disque.
# zpool status tank pool: tank state: ONLINE scrub: resilver completed after 0h0m with 0 errors on Tue Feb 2 13:35:41 2010 config: NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 mirror-0 ONLINE 0 0 0 c0t1d0 ONLINE 0 0 0 c1t1d0 ONLINE 0 0 0 mirror-1 ONLINE 0 0 0 c0t2d0 ONLINE 0 0 0 c1t2d0 ONLINE 0 0 0 mirror-2 ONLINE 0 0 0 c0t3d0 ONLINE 0 0 0 c4t3d0 ONLINE 0 0 0 |
L'exemple suivant montre comment récupérer les données d'un périphérique de journal défaillant (c0t5d0 ) dans le pool de stockage (pool). Voici les principales étapes à suivre :
Vérifiez la sortie zpool status -x et le message de diagnostic FMA, décrits ici :
Remplacez physiquement le périphérique de journal défaillant.
Mettez le nouveau périphérique de journal en ligne.
Effacez la condition d'erreur du pool.
# zpool status -x pool: pool state: FAULTED status: One or more of the intent logs could not be read. Waiting for adminstrator intervention to fix the faulted pool. action: Either restore the affected device(s) and run 'zpool online', or ignore the intent log records by running 'zpool clear'. scrub: none requested config: NAME STATE READ WRITE CKSUM pool FAULTED 0 0 0 bad intent log mirror ONLINE 0 0 0 c0t1d0 ONLINE 0 0 0 c0t4d0 ONLINE 0 0 0 logs FAULTED 0 0 0 bad intent log c0t5d0 UNAVAIL 0 0 0 cannot open <Physically replace the failed log device> # zpool online pool c0t5d0 # zpool clear pool |
# zpool status -x pool: pool state: FAULTED status: One or more of the intent logs could not be read. Waiting for adminstrator intervention to fix the faulted pool. action: Either restore the affected device(s) and run 'zpool online', or ignore the intent log records by running 'zpool clear'. scrub: none requested config: NAME STATE READ WRITE CKSUM pool FAULTED 0 0 0 bad intent log mirror-0 ONLINE 0 0 0 c0t1d0 ONLINE 0 0 0 c0t4d0 ONLINE 0 0 0 logs FAULTED 0 0 0 bad intent log c0t5d0 UNAVAIL 0 0 0 cannot open <Physically replace the failed log device> # zpool online pool c0t5d0 # zpool clear pool |
Le processus de remplacement d'un périphérique peut prendre beaucoup de temps, selon la taille du périphérique et la quantité de données dans le pool. Le processus de déplacement de données d'un périphérique à un autre s'appelle la resynchronisation. Vous pouvez la contrôler à l'aide de la commande zpool status.
Les systèmes de fichiers traditionnels effectuent la resynchronisation de données au niveau du bloc. Dans la mesure où ZFS élimine la séparation en couches artificielles du gestionnaire de volume, il peut effectuer la resynchronisation de façon bien plus puissante et contrôlée. Les deux avantages de cette fonction sont comme suite :
ZFS n'effectue la resynchronisation que de la quantité minimale de données requises. Dans le cas d'une brève interruption de service (par rapport à un remplacement complet d'un périphérique), vous pouvez effectuer la resynchronisation du disque en quelques minutes ou quelques secondes. Lors du remplacement d'un disque entier, la durée du processus de resynchronisation est proportionnelle à la quantité de données utilisées dans le disque. Le remplacement d'un disque de 500 Go ne dure que quelques secondes si le pool ne contient que quelques giga-octets d'espace utilisé.
La réargenture est un processus fiable qui peut être interrompu, le cas échéant. En cas de mise hors-tension ou de réinitialisation du système, le processus de réargenture reprend exactement là où il s'est arrêté, sans requérir une intervention manuelle.
La commande zpool status permet de visualiser le processus de réargenture. Exemple :
# zpool status tank pool: tank state: DEGRADED status: One or more devices is currently being resilvered. The pool will continue to function, possibly in a degraded state. action: Wait for the resilver to complete. scrub: resilver in progress for 0h0m, 22.60% done, 0h1m to go config: NAME STATE READ WRITE CKSUM tank DEGRADED 0 0 0 mirror-0 DEGRADED 0 0 0 replacing-0 DEGRADED 0 0 0 c1t0d0 UNAVAIL 0 0 0 cannot open c2t0d0 ONLINE 0 0 0 85.0M resilvered c1t1d0 ONLINE 0 0 0 errors: No known data errors |
Dans cet exemple, le disque c1t0d0 est remplacé par c2t0d0. Cet événement est observé dans la sortie d'état par la présence du périphérique virtuel replacing de la configuration. Ce périphérique n'est pas réel et ne permet pas de créer un pool. L'objectif de ce périphérique consiste uniquement à afficher le processus de resynchronisation et à identifier le périphérique en cours de remplacement.
Notez que tout pool en cours de resynchronisation se voit attribuer l'état ONLINE ou DEGRADED car il ne peut pas fournir le niveau souhaité de redondance tant que le processus n'est pas terminé. La resynchronisation s'effectue aussi rapidement que possible, mais les E/S sont toujours programmées avec une priorité inférieure à celle des E/S requises par l'utilisateur afin de minimiser l'impact sur le système. Une fois la resynchronisation terminée, la nouvelle configuration complète s'applique, remplaçant l'ancienne configuration. Exemple :
# zpool status tank pool: tank state: ONLINE scrub: resilver completed after 0h1m with 0 errors on Tue Feb 2 13:54:30 2010 config: NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 mirror-0 ONLINE 0 0 0 c2t0d0 ONLINE 0 0 0 377M resilvered c1t1d0 ONLINE 0 0 0 errors: No known data errors |
L'état du pool est à nouveau ONLINE et le disque défectueux d'origine (c1t0d0) a été supprimé de la configuration.
Les sections suivantes décrivent comment identifier le type de corruption de données et comment réparer les données le cas échéant.
ZFS utilise les données des sommes de contrôles, de redondance et d'auto-rétablissement pour minimiser le risque de corruption de données. Cependant, la corruption de données peut se produire si le pool n'est pas redondant, si la corruption s'est produite alors que le pool était endommagé ou si une série d'événements improbables a corrompu plusieurs copies d'un élément de données. Quelle que soit la source, le résultat est le même : les données sont corrompues et par conséquent inaccessibles. Les actions à effectuer dépendent du type de données corrompue et de leurs valeurs relatives. Deux types de données peuvent être corrompus :
Métadonnées de pool – ZFS requiert une certaine quantité de données à analyser afin d'ouvrir un pool et d'accéder aux jeux de données. Si ces données sont corrompues, le pool entier ou des parties de la hiérarchie du jeu de données sont indisponibles.
Données d'objet – Dans ce cas, la corruption se produit au sein d'un fichier ou périphérique spécifique. Ce problème peut rendre une partie du fichier ou répertoire inaccessible ou endommager l'objet.
Les données sont vérifiées lors des opérations normales et lors du nettoyage. Pour de plus amples informations sur la vérification de l'intégrité des données du pool, reportez-vous à la section Contrôle de l'intégrité d'un système de fichiers ZFS.
Par défaut, la commande zpool status indique qu'une corruption s'est produite, mais n'indique pas à quel endroit. Exemple :
# zpool status monkey pool: monkey state: ONLINE status: One or more devices has experienced an error resulting in data corruption. Applications may be affected. action: Restore the file in question if possible. Otherwise restore the entire pool from backup. see: http://www.sun.com/msg/ZFS-8000-8A scrub: scrub completed after 0h0m with 8 errors on Tue Jul 13 13:17:32 2010 config: NAME STATE READ WRITE CKSUM monkey ONLINE 8 0 0 c1t1d0 ONLINE 2 0 0 c2t5d0 ONLINE 6 0 0 errors: 8 data errors, use '-v' for a list |
Toute erreur indique seulement qu'une erreur s'est produite à un moment donné. Il est possible que certaines erreurs ne soient plus présentes dans le système. Dans le cadre d'une utilisation normale, elles le sont. Certaines interruptions de service temporaires peuvent entraîner une corruption de données qui est automatiquement réparée une fois l'interruption de service terminée. Un nettoyage complet du pool examine chaque bloc actif dans le pool. Ainsi, le journal d'erreur est réinitialisé à la fin de chaque nettoyage. Si vous déterminez que les erreurs ne sont plus présentes et ne souhaitez pas attendre la fin du nettoyage, la commande zpool online permet de réinitialiser toutes les erreurs du pool.
Si la corruption de données se produit dans des métadonnées au niveau du pool, la sortie est légèrement différente. Exemple :
# zpool status -v morpheus pool: morpheus id: 1422736890544688191 state: FAULTED status: The pool metadata is corrupted. action: The pool cannot be imported due to damaged devices or data. see: http://www.sun.com/msg/ZFS-8000-72 config: morpheus FAULTED corrupted data c1t10d0 ONLINE |
Dans le cas d'une corruption au niveau du pool, ce dernier se voit attribuer l'état FAULTED, car le pool ne peut pas fournir le niveau de redondance requis.
En cas de corruption d'un fichier ou d'un répertoire, le système peut tout de même continuer à fonctionner, selon le type de corruption. Tout dommage est irréversible, à moins que des copies correctes des données n'existent sur le système. Si les données sont importantes, vous devez restaurer les données affectées à partir d'une sauvegarde. Vous pouvez pourtant récupérer les données suite à corruption sans avoir à restaurer tout le pool.
En cas de dommages au sein d'un bloc de données de fichiers, le fichier peut être supprimé en toute sécurité. L'erreur est alors effacée du système. Utilisez la commande zpool status -v pour afficher la liste des noms de fichier contenant des erreurs persistantes. Exemple :
# zpool status -v pool: monkey state: ONLINE status: One or more devices has experienced an error resulting in data corruption. Applications may be affected. action: Restore the file in question if possible. Otherwise restore the entire pool from backup. see: http://www.sun.com/msg/ZFS-8000-8A scrub: scrub completed after 0h0m with 8 errors on Tue Jul 13 13:17:32 2010 config: NAME STATE READ WRITE CKSUM monkey ONLINE 8 0 0 c1t1d0 ONLINE 2 0 0 c2t5d0 ONLINE 6 0 0 errors: Permanent errors have been detected in the following files: /monkey/a.txt /monkey/bananas/b.txt /monkey/sub/dir/d.txt monkey/ghost/e.txt /monkey/ghost/boo/f.txt |
La liste des noms de fichiers comportant des erreurs persistantes peut être décrite comme suit :
Si le chemin complet du fichier est trouvé et si le jeu de données est monté, le chemin complet du fichier s'affiche. Exemple :
/monkey/a.txt |
Si chemin complet du fichier est trouvé mais que le jeu de données n'est pas monté, le nom du jeu de données non précédé d'un slash (/) s'affiche, suivi du chemin du fichier au sein du jeu de données. Exemple :
monkey/ghost/e.txt |
Si le nombre d'objet vers un chemin de fichiers ne peut pas être converti, soit en raison d'une erreur soit parce qu'aucun chemin de fichiers réel n'est associé à l'objet, tel que c'est le cas pour dnode_t, alors le nom du jeu de données s'affiche, suivi du numéro de l'objet. Exemple :
monkey/dnode:<0x0> |
En cas de corruption d'un MOS (Meta-Object Set, jeu de méta-objet), la balise spéciale <metadata> s'affiche, suivie du numéro de l'objet.
Si la corruption se situe au sein des métadonnées d'un répertoire ou d'un fichier, vous devez déplacer le fichier vers un autre emplacement. Vous pouvez déplacer en toute sécurité les fichiers ou les répertoires vers un autre emplacement. Cela permet de restaurer l'objet d'origine à son emplacement.
Si les métadonnées du pool sont endommagées et que cela empêche l'ouverture ou l'importation du pool, vous pouvez utiliser les options suivantes :
Tentez de récupérer le pool à l'aide de la commande zpool clear -F ou zpool import -F. Ces commandes tentent d'annuler (roll back) les dernières transactions restantes du pool pour qu'elles reviennent à un fonctionnement normal. Vous pouvez utiliser la commande zpool status pour vérifier le pool endommagé et les mesures de récupération recommandées. Exemple :
# zpool status pool: tpool state: FAULTED status: The pool metadata is corrupted and the pool cannot be opened. action: Recovery is possible, but will result in some data loss. Returning the pool to its state as of Wed Jul 14 11:44:10 2010 should correct the problem. Approximately 5 seconds of data must be discarded, irreversibly. Recovery can be attempted by executing 'zpool clear -F tpool'. A scrub of the pool is strongly recommended after recovery. see: http://www.sun.com/msg/ZFS-8000-72 scrub: none requested config: NAME STATE READ WRITE CKSUM tpool FAULTED 0 0 1 corrupted data c1t1d0 ONLINE 0 0 2 c1t3d0 ONLINE 0 0 4 |
Le processus de récupération comme décrit ci-dessus consiste à utiliser la commande suivante :
# zpool clear -F tpool |
Si vous tentez d'importer un pool de stockage endommagé, des messages semblables aux messages suivants s'affichent :
# zpool import tpool cannot import 'tpool': I/O error Recovery is possible, but will result in some data loss. Returning the pool to its state as of Wed Jul 14 11:44:10 2010 should correct the problem. Approximately 5 seconds of data must be discarded, irreversibly. Recovery can be attempted by executing 'zpool import -F tpool'. A scrub of the pool is strongly recommended after recovery. |
Le processus de récupération comme décrit ci-dessus consiste à utiliser la commande suivante :
# zpool import -F tpool Pool tpool returned to its state as of Wed Jul 14 11:44:10 2010. Discarded approximately 5 seconds of transactions |
Si le pool endommagé se trouve dans le fichier zpool.cache, le problème est détecté lors de l'initialisation du système. Le pool endommagé est consigné dans la commande zpool status. Si le pool ne se trouve pas dans le fichier zpool.cache, il n'est pas importé ou ouvert et des messages indiquant que le pool est endommagé s'affichent lorsque vous tentez de l'importer.
Si le pool ne peut pas être récupéré par le biais de la méthode de récupération ci-dessus, vous devez restaurer le pool et l'ensemble de ses données à partir d'une copie de sauvegarde. Le mécanisme utilisé varie énormément selon la configuration du pool et la stratégie de sauvegarde. Tout d'abord, enregistrez la configuration telle qu'elle s'affiche dans la commande zpool status pour pouvoir le recréer une fois le pool détruit. Ensuite, détruisez le pool à l'aide de la commande zpool destroy -f. Conservez également un fichier décrivant la disposition des jeux de données et les diverses propriétés définies localement dans un emplacement sûr, car ces informations deviennent inaccessibles lorsque le pool est lui-même inaccessible. Avec la configuration du pool et la disposition des jeux de données, vous pouvez reconstruire la configuration complète après destruction du pool. Les données peuvent ensuite être renseignées par la stratégie de sauvegarde ou de restauration de votre choix.
ZFS a été conçu pour être robuste et stable malgré les erreurs. Cependant, les bogues de logiciels ou certains problèmes inattendus peuvent entraîner la panique du système lors de l'accès à un pool. Dans le cadre du processus de réinitialisation, chaque pool doit être ouvert. En raison de ces défaillances, le système effectue des réinitialisations en boucle. Pour pouvoir reprendre les opérations dans cette situation, vous devez indiquer à ZFS de ne pas rechercher de pool au démarrage.
ZFS conserve un cache interne de pools disponibles et de leurs configurations dans /etc/zfs/zpool.cache. L'emplacement et le contenu de ce fichier sont privés et sujets à modification. Si le système devient impossible à initialiser, redémarrez au jalon none à l'aide de l'option d'initialisation -m =none. Une fois le système rétabli, remontez le système de fichiers racine en tant que système accessible en écriture,·puis renommez ou placez le fichier /etc/zfs/zpool.cache à un autre emplacement. En raison de ces actions, ZFS oublie l'existence de pools dans le système, ce qui l'empêche d'accéder au pool défectueux à l'origine du problème. Vous pouvez ensuite passer à un état normal de système en exécutant la commande svcadm milestone all. Vous pouvez utiliser un processus similaire lors de la réinitialisation à partir d'une racine de remplacement pour effectuer des réparations.
Une fois le système démarré, vous pouvez tenter d'importer le pool à l'aide de la commande zpool import. Cependant, dans ce cas, l'erreur qui s'est produite lors de l'initialisation risque de se reproduire car la commande utilise le même mécanisme d'accès aux pools. Si le système contient plusieurs pools, procédez comme suit :
Renommez ou déplacez le fichier zpool.cache vers un autre emplacement comme décrit dans le paragraphe ci-dessus.
Utilisez la commande fmdump -eV pour afficher les pools présentant des erreurs fatales et déterminer ainsi quel pool pose des problèmes.
Importez les pools un à un en ignorant ceux qui posent problème, comme décrit dans la sortie de la commande fmdump.