ZFS-vdevs sammeln Prüfsummenfehler, einzelne Festplatten jedoch nicht

8

Ich verwende ein herstellerspezifisches Derivat von FreeNAS 9.3.

Meine Probleme begannen, als ich ein neues JBOD-Chassis installierte, um zwei neue vdevs in meinen Pool aufzunehmen, und das Chassis hatte ein schlechtes Board. Während dieser Zeit wurden SAS-Stromversorgungsfehler auf den Laufwerken auf der fehlerhaften Platine festgestellt. Meine neuen Laufwerke wurden effektiv jede Minute wiederholt ein- und wieder ausgeschaltet.

Ich habe die Karte ausgetauscht und jetzt funktionieren die Laufwerke nach den meisten Maßstäben gut, aber ZFS gibt mir beim Anzeigen immer noch äußerst seltsame Prüfsummenfehler zpool status. Ich glaube, es gab einige schlechte CoW-Schreibvorgänge, als ich Probleme mit der SAS-Stromversorgung hatte.

Das erste Gehäuse mit CPU, Boot-Laufwerk, RAM usw. wird über Mini-SAS mit dem ersten JBOD-Erweiterungsgehäuse verbunden, und das zweite JBOD-Erweiterungsgehäuse ist über das erste JBOD-Erweiterungsgehäuse, ebenfalls über Mini-SAS, verkettet.

  • [Gehäuse 1: Boot-Laufwerk, zwei L2ARC-SSDs, 11/11-Laufwerke von RAIDZ3-0, 1/11 Laufwerke von RAIDZ3-1] -> Mini-SAS zu Gehäuse 2
  • [Chassis 2: 10/11-Laufwerke von RAID Z3-1, 6/11-Laufwerke von RAID Z3-2] -> Mini-SAS zu Chassis 3
  • [Chassis 3: 5/11 Laufwerke von RAIDZ3-2, 11/11 Laufwerke von RAIDZ3-3]

Die Prüfsummenfehler werden keinem Controller oder Chassis ordentlich zugeordnet, aber meine Vermutung ist, dass bei diesen Stromproblemen alle Daten, die auf die verschiedenen neuen Festplatten geschrieben wurden, schlecht auf die beiden neuen vdevs geschrieben wurden.

Meine HBAs haben eine gute LSI-Firmware - alle sind am 20.00.04.00 oder 20.00.08.00

Ich habe Mini-SAS-Kabel ausgetauscht und versucht, verschiedene Ports zu verwenden, ohne Erfolg.

Der Ausgang der zpool statuszeigt Prüfsummenstörungen auf den beiden neuen vdevs Akkumulieren und nach entweder ein Peeling, Neustart, oder zpool clear, schließlich zpool statusmarkiert die vdevs als verschlechtert. Was seltsam ist, ist, dass es auch einige der Laufwerke, die zu diesen vdevs gehören, als beeinträchtigt markiert , aber ihre tatsächliche Fehleranzahl der einzelnen Festplatten ist alle 0. Dies zdbzeigt, dass die einzelnen Laufwerke als beeinträchtigt markiert sind, weil sie zu viele Prüfsummenfehler aufweisen, obwohl Alle ihre Prüfsummenfehlerzahlen sind tatsächlich 0. Was auch seltsam ist, ist, dass die Prüfsummenfehler auf Poolebene eine niedrigere Zahl anzeigen als die Prüfsummenfehler aus den beiden zusammengefügten Problem-vdevs.

zpool status -vZeigt dauerhaft einen dauerhaften Fehler in einem Snapshot an, der einem 0x0Inode zugeordnet ist, der schon lange gelöscht wurde, aber nicht durch mehrere Scrubs, Neustarts oder gelöscht werden kann zpool clear. Außerdem werden andere permanente Fehler ein- und ausgeblendet, die manchmal nur als Hexcode-Inodes und manchmal als Teil der letzten Snapshots angezeigt werden. Ich kann keine 0x0mit finden lsof.

Ich glaube, dass die Metadaten im Pool möglicherweise beschädigt werden.

Ich suche nach einer Möglichkeit, diese Phantomschnappschüsse chirurgisch zu entfernen oder meinen Pool auf andere Weise in einen gesunden Zustand zu versetzen, ohne meine Daten zu zerstören. Ich vermute, dass ZFS irgendwo diese beschädigten Phantom-Snapshots durchläuft und sowohl die bizarren Prüfsummenfehler als auch die verschlechterten Zustände auf den vdevs verursacht.

Ich habe "kalte" LTO-Backups von vielen meiner wichtigen Daten, aber wenn ich meinen Pool nicht reparieren kann, bereite ich mich darauf vor, einen zweiten Server einzurichten, alles auf den "heißen" zweiten Server zu verlagern und meinen Pool zu zerstören auf der obersten Ebene, und laden Sie dann aus dem Hot-Backup neu.

Hier ist die Ausgabe von 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>

Über den FreeNAS GUI habe ich versucht , das Kopieren der System dataset poolvon poolüber freenas-bootund dann versuchte , mit zfs destroydem löschen poolKopie pool/.systemund verlassen die freenas-bootintakte Kopie. Ich konnte damit zfs destroyalles löschen, was in pool/.system aufgeführt ist zfs list, aber beim Versuch, pool/.systemmit zu zerstören zfs destroy, gab die Shell den Fehler zurück : Cannot iterate filesystems: I/O error. Ich habe versucht , zfs destroyauf pool/.systemdem die -f, -rund -RFahnen, gemäß der Oracle ZFS Dokumentation , ohne Erfolg.

Ich begann noch ein Peeling. Wenn Sie möglicherweise den Inhalt pool/.systemder poolKopie von System dataset poolentfernen, kann das Scrub den Metadatenfehler mit dem Phantom-Snapshot beheben pool/.system@auto-20160720.2300-2d.

Ich frage mich, ob es möglich ist, jede Festplatte, die als beeinträchtigt angezeigt wird, einzeln zu sichern, damit die "schlechten" Metadaten, auf die nicht verwiesen wird, aufgegeben werden können. Ich habe zwei Festplatten ausgemustert, aber jetzt stößt ich auf ein Problem, bei dem das Ausgleichen einer zusätzlichen Festplatte dazu führt, dass die anderen Festplatten, die ich bereits ausgemustert habe, gleichzeitig wieder mit dem Ausgleichen beginnen. Ich glaube, es könnte sich um einen ZFS-Fehler handeln, der mit periodischen Snapshot-Aufgaben zusammenhängt , und ich habe meine periodische Snapshot-Aufgabe gelöscht und alle meine Snapshots zerstört, aber ich zögere aus Angst, noch einen der herabgesetzten Laufwerke zu widerlegen dass alle zuvor ausfallsicheren Festplatten wieder ausfallsicher werden, so dass ich keine Redundanz mehr habe und schließlich einen fehlerhaften Pool habe.

Nachdem ich meine regelmäßigen Snapshot-Aufgaben deaktiviert und alle meine Snapshots gelöscht hatte, versuchte ich, eine Festplatte zu löschen und sie dann auszulagern, aber die drei Festplatten, die ich bereits ausgemustert hatte, begannen erneut auszulagern. Jetzt bin ich mir fast sicher, dass ich pro RAID-Z3-vdev-Problem zwei verschiedene Festplatten haben würde, die ausfallsicher sind. Wenn ich also versuche, weitere Festplatten auszulagern, verliere ich die Redundanz in jedem der problem-vdevs und meinem Pool wird fehlerhaft.

Ein anderes bizarres Verhalten ist, dass das Überprüfen zpool status -vdie Anzahl der Prüfsummenfehler des Pools schrittweise erhöht, das Überprüfen zpool statusjedoch nicht. Es ist fast so, als würde das -vFlag selbst über den Mechanismus iterieren, der Prüfsummenfehler verursacht.

Würde die Verwendung zdb -cin meinem Pool diese Metadatenfehler irgendwie "beheben" können?

freebsd  zfs  freenas  zpool  checksum 
— user260467
quelle
Können Sie die tatsächliche Ausgabe des 'zpool status' angeben, damit wir sie sehen können?
— Allan Jude
@AllanJude Ich habe gerade die Ausgabe von hinzugefügt zpool status -v.
— user260467
Ich habe neue Informationen über meinen Versuch , hinzugefügt durch Zerstören der Phantom Snapshot zu löschen pool/.systeminnerhalb des pool‚s System dataset pool.
— user260467
Ich habe einige Informationen hinzugefügt, die theoretisch über das Löschen jedes beschädigten Laufwerks und das Resilvering nacheinander theoretisieren.
— user260467
Ich habe Informationen darüber hinzugefügt, wie die bereits ausgelagerten Laufwerke wieder belastbar werden, wenn ich versuche, ein neues Laufwerk zu sichern.
— user260467

Antworten:

4

Die 0x0und andere Hexadezimalzahlen werden anstelle von Dateinamen und anderen Objekten angezeigt, wenn Metadaten beschädigt sind. Wenn Sie es nicht loswerden können, indem Sie die betroffenen Objekte zerstören (ich habe verstanden, dass es sich um Schnappschüsse handelt), ist der Schaden wahrscheinlich zu groß, um repariert zu werden. In diesem Fall würde ich den Pool aus dem Backup wiederherstellen, insbesondere wenn Sie weitere seltsame Effekte haben, wie z. B. das Erscheinen und Verschwinden defekter Metadaten.

Informationen zu den Methoden zur Behebung der meisten Probleme finden Sie im ZFS-Administratorhandbuch hier . ZFS bietet Ihnen jedoch auch eine URL, unter der Sie bei der Eingabe nach Lösungen suchen können zpool status.

— Martin Sugioarto
quelle
Gibt es Spezialisten wie OpenZFS-Entwickler, die wissen, wie die Metadaten chirurgisch repariert werden können? Wo könnte ich suchen? Eine Datenmigration wäre sehr kostspielig. Wenn sie vermieden werden kann, lohnt es sich möglicherweise, einen Spezialisten zu bezahlen, auch wenn sie nominell teuer erscheint.
— user260467
2
@ user260467 Nicht ganz Empfehlungen, eher Ideen ... * Sie könnten Entwicklernamen + E-Mail-Adressen von git abrufen : github.com/freebsd/freebsd/tree/master/sys/cddl/contrib/… oder einen Fehlerbericht einreichen, in dem Sie gefragt werden Hilfe: bugs.freebsd.org/bugzilla/enter_bug.cgi Wenn Sie mit FreeBSD ZFS kein Glück haben, ist ZFSonLinux möglicherweise besser (aktiv). github.com/zfsonlinux/zfs/issues Einige ServerFault-Benutzer nehmen Jobs an und sehen sich ihre Profile an.
— Ryan Babchishin
Ich markiere dies als die richtige Antwort. Es ist normalerweise nicht kosteneffektiv, einen Pool auf diese Weise chirurgisch zu reparieren. Daher möchte ich den Inhalt des Pools in ein heißes Backup laden, den problematischen Pool zerstören, einen neuen Pool erstellen und neu laden.
— user260467
2
Nur um hier nachzufolgen. Am Ende habe ich den gesamten Pool zerstört und einen völlig neuen erstellt, völlig frisch, und die Festplatten weisen keine Anzeichen von Problemen auf. Bei einem solchen Problem scheint es am besten zu sein, den Pool zu zerstören und aus dem Backup wiederherzustellen.
— user260467
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.