J'utilise un dérivé spécifique de FreeNAS 9.3.
Mon problème a commencé lorsque j'ai installé un nouveau châssis JBOD pour ajouter deux nouveaux vdevs à mon pool, et 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 s'allumaient et s'éteignaient, de manière répétée, toutes les minutes.
J'ai remplacé la carte et maintenant, d'après la plupart des mesures, les disques fonctionnent bien, mais ZFS me donne toujours des erreurs de somme de contrôle extrêmement étranges lorsque j'affiche les données suivantes zpool status . Je pense qu'il y a eu quelques mauvaises écritures de CoW lorsque j'ai eu les problèmes de puissance du SAS.
Le premier châssis avec le CPU, le disque de démarrage, la RAM, etc., se connecte au premier châssis d'extension JBOD via mini-SAS, et le deuxième châssis d'extension JBOD est relié en guirlande au premier châssis d'extension JBOD, également via mini-SAS.
- [Châssis 1 : disque de démarrage, deux disques SSD L2ARC, 11/11 disques RAIDZ3-0, 1/11 disques RAIDZ3-1] -->mini-SAS vers le châssis 2
- [Châssis 2 : 10/11 disques de RAID Z3-1, 6/11 disques du RAID Z3-2] -->mini-SAS vers le 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 sont pas clairement liées à un contrôleur ou à un châssis, mais j'ai l'impression que lorsque j'avais ces problèmes d'alimentation, les données écrites sur les différents nouveaux disques étaient mal écrites sur les deux nouveaux disques virtuels.
Mes HBA ont un bon firmware LSI - tous sont sur 20.00.04.00 ou 20.00.08.00.
J'ai échangé les câbles mini-SAS et essayé d'utiliser d'autres ports, sans succès.
La sortie de zpool status montre des erreurs de somme de contrôle qui s'accumulent sur les deux nouveaux vdevs, et après un scrub, un redémarrage, ou un zpool clear , en fin de compte zpool status marque ces disques virtuels comme étant dégradés. Ce qui est étrange, c'est qu'il marque également certains des lecteurs appartenant à ces vdevs comme dégradés, mais leur nombre d'erreurs réel des disques individuels est tous de 0. zdb montre que les disques individuels sont marqués comme dégradés parce qu'ils ont trop d'erreurs de somme de contrôle, même si tous leurs comptes d'erreurs de somme de contrôle sont en fait à 0. Ce qui est également étrange, c'est que les erreurs de somme de contrôle au niveau du pool montrent un nombre inférieur aux erreurs de somme de contrôle des deux disques virtuels problématiques ajoutés ensemble.
zpool status -v affiche de façon persistante une erreur permanente dans un instantané mappé sur un 0x0 inode qui a été supprimé depuis longtemps, mais qui ne semble pas pouvoir être effacé par de multiples nettoyages, redémarrages, ou zpool clear . De plus, d'autres erreurs permanentes apparaissent et disparaissent, parfois uniquement sous la forme d'inodes hexadécimaux, et d'autres fois sous la forme de snapshots récents. Je ne trouve aucun 0x0 con lsof .
Je pense 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 remettre mon pool dans un état sain sans détruire mes données. Je soupçonne que quelque part, ZFS itère sur ces instantanés fantômes corrompus et provoque à la fois les erreurs bizarres de somme de contrôle et les états dégradés sur les disques virtuels.
J'ai des sauvegardes LTO "froides" de la plupart de mes données importantes, mais sinon, si je ne peux pas réparer mon pool, je me prépare à installer un deuxième serveur, à tout décharger sur le deuxième serveur "chaud", à détruire mon pool au niveau supérieur, puis à le recharger à partir de la sauvegarde à chaud.
Voici le résultat 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 de FreeNAS, j'ai essayé de copier le fichier System dataset pool de pool pour freenas-boot et a ensuite essayé d'utiliser zfs destroy pour supprimer le pool copie de pool/.system et en laissant le freenas-boot copie intacte. J'ai pu utiliser zfs destroy pour tout effacer à l'intérieur pool/.system figurant sur la liste des zfs list mais en essayant de détruire pool/.system con zfs destroy Le Shell a renvoyé l'erreur : Cannot iterate filesystems: I/O error . J'ai essayé zfs destroy en pool/.system avec le -f , -r et -R conformément à la directive Documentation Oracle ZFS en vain.
J'ai commencé un nouveau gommage. Peut-être qu'en éliminant le contenu des 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 resilver chaque disque qui apparaît 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 resilvérisé deux disques, mais je rencontre maintenant un problème dans lequel le resilvérisation d'un disque supplémentaire fait que les autres disques que j'ai déjà resilvérisés recommencent à se resilvériser en même temps. Je crois que il pourrait s'agir d'un bogue de ZFS lié aux tâches d'instantanés périodiques J'ai supprimé ma tâche d'instantané périodique et détruit tous mes instantanés, mais j'hésite à essayer de rééquilibrer un autre des disques dégradés de peur que tous les disques rééquilibrés précédemment ne le soient à nouveau, ce qui me laisserait sans aucune redondance, au point d'avoir un pool défectueux.
Après avoir désactivé mes tâches d'instantanés périodiques et supprimé tous mes instantanés, j'ai essayé d'effacer un disque et de le réenregistrer, mais les trois disques que j'avais déjà réenregistrés ont recommencé à le faire. Maintenant, je suis presque certain que j'aurais deux disques différents pour chaque unité de disque virtuelle RAID-Z3 problématique qui se réinitialiserait, donc si j'essaie de réinitialiser d'autres disques, je perdrai la redondance dans chacune des unités de disque virtuelle problématiques et mon pool sera défectueux.
Un autre comportement bizarre est que la vérification zpool status -v augmente en fait le nombre d'erreurs de somme de contrôle du pool de manière incrémentielle, mais la vérification de la somme de contrôle de l'utilisateur est plus difficile. zpool status ne le fait pas. C'est un peu comme si le -v lui-même itère sur le mécanisme qui provoque les erreurs de somme de contrôle.
L'utilisation de zdb -c sur mon pool peut-elle "réparer" ces erreurs de métadonnées ?
