Question ZFS vdevs accumule des erreurs de somme de contrôle, mais pas les disques individuels


J'utilise un dérivé de FreeNAS 9.3 spécifique au fournisseur.

Mes problèmes ont commencé lorsque j'ai installé un nouveau châssis JBOD pour ajouter deux nouveaux vdev à mon pool et que le châssis avait une carte défectueuse. Pendant ce temps, je voyais des erreurs d’alimentation SAS sur les disques de la carte défectueuse - mes nouveaux disques allumaient et éteignaient à nouveau, chaque minute.

J'ai remplacé la carte et maintenant, selon la plupart des mesures, les disques fonctionnent bien, mais ZFS me donne toujours des erreurs de contrôle extrêmement étranges lorsque je vois zpool status. Je pense que CoW a mal écrit lorsque je rencontrais des problèmes d'alimentation avec SAS.

Le premier châssis avec le processeur, le lecteur d'amorçage, la mémoire vive, etc., se connecte au premier châssis d'extension JBOD via mini-SAS et le second châssis d'extension JBOD est connecté en chaîne au premier châssis d'extension JBOD, également via mini-SAS.

  • [Châssis 1: disque d’amorçage, deux disques SSD L2ARC, disques 11/11 de RAIDZ3-0, Disques 1/11 RAIDZ3-1] -> mini-SAS vers châssis 2
  • [Châssis 2: 10/11 disques de RAID Z3-1, 6/11 disques de RAID Z3-2] -> mini-SAS au châssis 3
  • [Châssis 3: 5/11 disques de RAIDZ3-2, 11/11 disques de RAIDZ3-3]

Les erreurs de somme de contrôle ne correspondent pas parfaitement à un contrôleur ou à un châssis, mais mon impression est que, lorsque je rencontrais ces problèmes d'alimentation, les données écrites sur les différents nouveaux disques étaient mal écrites sur les deux nouveaux vdev.

Mes HBA sont sur le bon firmware LSI - tous sont sur 20.00.04.00 ou 20.00.08.00

J'ai échangé des câbles mini-SAS et essayé d'utiliser différents ports, mais en vain.

La sortie de zpool statusaffiche des erreurs de somme de contrôle qui s’accumulent sur les deux nouveaux vdevs, et après un nettoyage, un redémarrage ou zpool clear, finalement zpool status marque ces vdevs comme dégradés. Ce qui est étrange, c’est que cela marque aussi certains des lecteurs qui appartiennent à ces vdev comme étant dégradés, mais leur nombre d’erreurs réel des disques individuels est 0. zdb indique que les lecteurs individuels sont marqués comme dégradés car ils comportent trop d'erreurs de somme de contrôle, même si leur nombre total d'erreurs de contrôle est en réalité égal à 0. Il est également étrange que les erreurs de total de contrôle au niveau du pool affichent un nombre inférieur à celui des deux problèmes vdevs ajoutés ensemble.

zpool status -v affiche de manière persistante une erreur permanente dans un instantané mappé à un 0x0 inode qui a longtemps été supprimé, mais ne semble pas pouvoir être effacé par plusieurs gommages, redémarrages ou zpool clear. En outre, d'autres erreurs permanentes apparaissent et disparaissent, parfois uniquement sous forme d'inodes hexcode, et d'autres fois dans le cadre d'instantanés récents. Je n'en trouve pas 0x0 avec lsof.

Je crois qu'il pourrait y avoir une sorte de corruption de données avec les métadonnées dans le pool.

Je cherche un moyen de supprimer chirurgicalement ces instantanés fantômes ou de redonner à ma piscine son état de santé sans détruire mes données. Je soupçonne que quelque part, ZFS parcourt ces instantanés fantômes corrompus et provoque à la fois les erreurs de checksum bizarres et les états dégradés sur les vdev.

J'ai des sauvegardes LTO "à froid" d'une grande partie de mes données importantes, mais sinon, si je ne peux pas réparer mon pool, je me prépare à configurer un second serveur, tout décharger sur le second serveur "à chaud", détruire mon pool au niveau supérieur, puis rechargez à partir de la sauvegarde à chaud.

Voici la sortie de zpool status -v:

[root@Jupiter] ~# zpool status -v
  pool: freenas-boot
 state: ONLINE
status: One or more devices are configured to use a non-native block size.
        Expect reduced performance.
action: Replace affected devices with devices that support the configured block size, or migrate data to a properly configured pool.
  scan: resilvered 944M in 0h17m with 0 errors on Tue Aug  9 11:56:28 2016
config:

    NAME        STATE     READ WRITE CKSUM
    freenas-boot  ONLINE       0     0     0
      mirror-0  ONLINE       0     0     0
        da46p2  ONLINE       0     0     0  block size: 8192B configured, 8388608B native
        da47p2  ONLINE       0     0     0  block size: 8192B configured, 8388608B native

errors: No known data errors

  pool: pool
 state: DEGRADED
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://illumos.org/msg/ZFS-8000-8A
  scan: scrub in progress since Fri Sep  9 22:43:51 2016
        6.27T scanned out of 145T at 1.11G/s, 35h27m to go
        0 repaired, 4.33% done
config:

    NAME                                            STATE     READ WRITE CKSUM
    pool                                            DEGRADED     0     0   118
      raidz3-0                                      ONLINE       0     0     0
        gptid/ac108605-265c-11e5-9a02-0cc47a599098  ONLINE       0     0     0
        gptid/ac591d4e-265c-11e5-9a02-0cc47a599098  ONLINE       0     0     0
        gptid/ac92fd0d-265c-11e5-9a02-0cc47a599098  ONLINE       0     0     0
        gptid/accd3076-265c-11e5-9a02-0cc47a599098  ONLINE       0     0     0
        gptid/ad067e97-265c-11e5-9a02-0cc47a599098  ONLINE       0     0     0
        gptid/ad46cbee-265c-11e5-9a02-0cc47a599098  ONLINE       0     0     0
        gptid/ad91ba17-265c-11e5-9a02-0cc47a599098  ONLINE       0     0     0
        gptid/adcbdd0a-265c-11e5-9a02-0cc47a599098  ONLINE       0     0     0
        gptid/ae07dc0d-265c-11e5-9a02-0cc47a599098  ONLINE       0     0     0
        gptid/ae494d10-265c-11e5-9a02-0cc47a599098  ONLINE       0     0     0
        gptid/ae93a3a5-265c-11e5-9a02-0cc47a599098  ONLINE       0     0     0
      raidz3-1                                      ONLINE       0     0     0
        gptid/12f6a4c5-c929-11e5-8075-0cc47a599098  ONLINE       0     0     0
        gptid/511ea1f9-1932-11e6-9b1e-0cc47a599098  ONLINE       0     0     0
        gptid/14436fcf-c929-11e5-8075-0cc47a599098  ONLINE       0     0     0
        gptid/14f50aa3-c929-11e5-8075-0cc47a599098  ONLINE       0     0     0
        gptid/159b5654-c929-11e5-8075-0cc47a599098  ONLINE       0     0     0
        gptid/163d682b-c929-11e5-8075-0cc47a599098  ONLINE       0     0     0
        gptid/16ee624e-c929-11e5-8075-0cc47a599098  ONLINE       0     0     0
        gptid/1799dde3-c929-11e5-8075-0cc47a599098  ONLINE       0     0     0
        gptid/184c2ea4-c929-11e5-8075-0cc47a599098  ONLINE       0     0     0
        gptid/18f51c30-c929-11e5-8075-0cc47a599098  ONLINE       0     0     0
        gptid/19a861ea-c929-11e5-8075-0cc47a599098  ONLINE       0     0     0
      raidz3-2                                      DEGRADED     0     0   236
        gptid/5f80fc42-4e00-11e6-b7cf-0cc47a599098  DEGRADED     0     0     0  too many errors
        gptid/60369e0f-4e00-11e6-b7cf-0cc47a599098  DEGRADED     0     0     0  too many errors
        gptid/60e8234a-4e00-11e6-b7cf-0cc47a599098  DEGRADED     0     0     0  too many errors
        gptid/61a235f2-4e00-11e6-b7cf-0cc47a599098  DEGRADED     0     0     0  too many errors
        gptid/62580471-4e00-11e6-b7cf-0cc47a599098  DEGRADED     0     0     0  too many errors
        gptid/6316a38a-4e00-11e6-b7cf-0cc47a599098  DEGRADED     0     0     0  too many errors
        gptid/63d4bce8-4e00-11e6-b7cf-0cc47a599098  DEGRADED     0     0     0  too many errors
        gptid/ebfc2b99-6893-11e6-9b09-0cc47a599098  ONLINE       0     0     0
        gptid/654f143a-4e00-11e6-b7cf-0cc47a599098  DEGRADED     0     0     0  too many errors
        gptid/66236b33-4e00-11e6-b7cf-0cc47a599098  DEGRADED     0     0     0  too many errors
        gptid/66eda3f6-4e00-11e6-b7cf-0cc47a599098  DEGRADED     0     0     0  too many errors
      raidz3-3                                      DEGRADED     0     0   176
        gptid/c77a9da9-4e02-11e6-b7cf-0cc47a599098  ONLINE       0     0     0
        gptid/c83e100e-4e02-11e6-b7cf-0cc47a599098  ONLINE       0     0     0
        gptid/c8fd9ced-4e02-11e6-b7cf-0cc47a599098  DEGRADED     0     0     0  too many errors
        gptid/c9bb21ba-4e02-11e6-b7cf-0cc47a599098  DEGRADED     0     0     0  too many errors
        gptid/ca7a48db-4e02-11e6-b7cf-0cc47a599098  DEGRADED     0     0     0  too many errors
        gptid/cb422329-4e02-11e6-b7cf-0cc47a599098  DEGRADED     0     0     0  too many errors
        gptid/cbfe4c21-4e02-11e6-b7cf-0cc47a599098  ONLINE       0     0     0
        gptid/ccc43528-4e02-11e6-b7cf-0cc47a599098  ONLINE       0     0     0
        gptid/cd93a34c-4e02-11e6-b7cf-0cc47a599098  ONLINE       0     0     0
        gptid/ce622f51-4e02-11e6-b7cf-0cc47a599098  ONLINE       0     0     0
        gptid/cf2591d3-4e02-11e6-b7cf-0cc47a599098  ONLINE       0     0     0
    cache
      gptid/aedd3872-265c-11e5-9a02-0cc47a599098    ONLINE       0     0     0
      gptid/af559c10-265c-11e5-9a02-0cc47a599098    ONLINE       0     0     0

errors: Permanent errors have been detected in the following files:

        <0x357>:<0x2aef3>
        <0x37b>:<0x397285>
pool/.system@auto-20160720.2300-2d:<0x0>

Via l’interface graphique FreeNAS, j’ai essayé de copier le System dataset pool de pool vers freenas-boot et ensuite essayé d'utiliser zfs destroy supprimer le pool copie de pool/.system et en laissant le freenas-boot copie intacte. J'ai pu utiliser zfs destroy tout effacer dans  pool/.system énumérés dans zfs list, mais en essayant de détruire pool/.system avec zfs destroy, le shell a renvoyé l'erreur: Cannot iterate filesystems: I/O error. j'ai essayé zfs destroy sur pool/.system avec le la -f, -r, et -R drapeaux, selon le Documentation Oracle ZFS, en vain.

J'ai commencé un autre gommage. Peut-être éliminer le contenu de pool/.system sur le pool copie de la System dataset pool permettra au scrub d'effacer l'erreur de métadonnées avec l'instantané fantôme pool/.system@auto-20160720.2300-2d.

Je me demande s’il est possible de relancer chaque disque qui se présente comme dégradé, un par un, afin que les "mauvaises" métadonnées qui ne sont pas référencées puissent être abandonnées. J'ai rediffusé deux disques, mais je suis maintenant confronté à un problème en raison duquel la resurvolution de tout disque supplémentaire force les autres disques déjà résiliés à recommencer à résumer en même temps. Je crois il peut s'agir d'un bogue ZFS lié à des tâches d'instantané périodiqueset j'ai pris les devants, supprimé ma tâche d'instantané périodique et détruit tous mes instantanés, mais j'hésite à essayer de résumer un autre disque dégradé, de peur que tous les disques précédemment résiliés ne le soient à nouveau, ce qui me laisse sans toute redondance, éventuellement au point d’avoir un pool défaillant.

Après avoir désactivé mes tâches d'instantanés périodiques et supprimé tous mes instantanés, j'ai essayé de nettoyer un disque, puis de le rediffuser, mais les trois disques que j'avais déjà résiliés ont recommencé à le faire. Maintenant, je suis presque certain que j'aurais deux disques différents pour chaque problème RAID-Z3 vdev qui résilverait. Par conséquent, si j'essayais de réservoir plusieurs disques, je perdrais la redondance dans chacun des problèmes vdevs et mon pool. sera en faute.

Un autre comportement bizarre est que vérifier zpool status -v augmente effectivement le nombre d'erreurs de la somme de contrôle du pool de manière incrémentielle, mais en vérifiant zpool status ne fait pas. C'est presque comme si le -v Le drapeau lui-même est itératif sur tout mécanisme qui cause des erreurs de somme de contrôle.

En utilisant zdb -c sur mon pool en quelque sorte être en mesure de "réparer" ces erreurs de métadonnées?


7
2017-09-08 20:24


origine


Pouvez-vous inclure la sortie réelle de «statut zpool» pour que nous puissions la voir? - Allan Jude
@AllanJude Je viens d'ajouter la sortie de zpool status -v. - user260467
J'ai ajouté de nouvelles informations sur ma tentative d'effacer l'instantané fantôme en détruisant pool/.system dans le poolde System dataset pool. - user260467
J'ai ajouté quelques informations théoriques sur le nettoyage de chaque lecteur dégradé et la résilience, un par un. - user260467
J'ai ajouté des informations sur la façon dont le lecteur déjà résilient résilience lorsque je tente de résilier un nouveau lecteur. - user260467


Réponses:


le 0x0 et d'autres nombres hexadécimaux apparaissent à la place des noms de fichiers et d'autres objets lorsque les métadonnées sont corrompues. Si vous ne pouvez pas vous en débarrasser en détruisant les objets affectés (j'ai cru comprendre qu'ils se réfèrent à des instantanés), les dégâts sont probablement trop importants pour être réparés. Dans ce cas, je restaurerais le pool à partir d'une sauvegarde, en particulier lorsque vous subissez d'autres effets étranges, tels que l'apparition ou la disparition de métadonnées endommagées.

Vous pouvez lire sur les méthodes pour se débarrasser de la plupart des problèmes de la Guide d'administration ZFS ici. Mais ZFS vous donne également une URL où chercher des solutions lorsque vous tapez zpool status.


2
2017-09-08 21:55



Existe-t-il des spécialistes, comme les développeurs OpenZFS par exemple, qui sauraient réparer de manière chirurgicale les métadonnées? Où pourrais-je regarder? Une migration de données coûterait très cher. Si cela peut être évité, cela vaut la peine de payer un spécialiste, même si cela semble nominalement coûteux. - user260467
@ user260467 Pas vraiment des recommandations, mais plutôt des idées ... * vous pouvez extraire les noms des développeurs + adresses e-mail de git: github.com/freebsd/freebsd/tree/master/sys/cddl/contrib/… ou soumettez un rapport de bogue demandant de l'aide: bugs.freebsd.org/bugzilla/enter_bug.cgi Si vous n’avez pas de chance avec FreeBSD ZFS, peut-être que ZFSonLinux serait mieux (actif) github.com/zfsonlinux/zfs/issues Certains utilisateurs de ServerFault acceptent des travaux, consultent leurs profils. - Ryan Babchishin
Je marque ceci comme étant la bonne réponse. Il n'est généralement pas rentable de réparer de manière chirurgicale un pool de cette manière. Je cherche donc à charger le contenu du pool dans une sauvegarde à chaud, à le détruire, à créer un nouveau pool et à le recharger. - user260467
Juste pour suivre ici. J'ai fini par détruire la totalité du pool et en créer un tout nouveau, complètement neuf, et les disques durs ne montrent aucun signe de problème. Avec un problème comme celui-ci, il semble préférable de détruire le pool et de le restaurer à partir d'une sauvegarde. - user260467