sterbender ZFS Pool meldet seltsame Dinge

-Nuke-

-Nuke-

Well-Known Member
Hallo,

in einem RAID-Z2 Pool sterben bei mir gerade mehrere Platten gleichzeitig. Die Frage ist jetzt, wie ich das hier zu verstehen habe:

zpool status:
Code: 
  pool: datatank
 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: https://openzfs.github.io/openzfs-docs/msg/ZFS-8000-8A
  scan: resilvered 6.76M in 00:00:04 with 0 errors on Thu Jan 11 16:02:09 2024
config:

        NAME               STATE     READ WRITE CKSUM
        datatank           DEGRADED     0     0     0
          raidz2-0         DEGRADED     0     0     0
            gpt/datadisk1  ONLINE       0     0  263K
            gpt/datadisk2  ONLINE       0     0  252K
            gpt/datadisk3  ONLINE       0     0  307K
            gpt/datadisk4  ONLINE       0     0  321K
            gpt/datadisk5  ONLINE       0     0  319K
            gpt/datadisk6  FAULTED     94    85     0  too many errors
            gpt/datadisk7  FAULTED     28 4.97K     0  too many errors
            gpt/datadisk8  ONLINE       0     0  325K

errors: 18 data errors, use '-v' for a list

18 data errors also. Gut, jetzt wollte ich, wie da steht, eine Liste haben...
zpool status -v:
Code: 
  pool: datatank
 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: https://openzfs.github.io/openzfs-docs/msg/ZFS-8000-8A
  scan: resilvered 6.76M in 00:00:04 with 0 errors on Thu Jan 11 16:02:09 2024
config:

        NAME               STATE     READ WRITE CKSUM
        datatank           DEGRADED     0     0     0
          raidz2-0         DEGRADED     0     0     0
            gpt/datadisk1  ONLINE       0     0  263K
            gpt/datadisk2  ONLINE       0     0  252K
            gpt/datadisk3  ONLINE       0     0  307K
            gpt/datadisk4  ONLINE       0     0  321K
            gpt/datadisk5  ONLINE       0     0  319K
            gpt/datadisk6  FAULTED     94    85     0  too many errors
            gpt/datadisk7  FAULTED     28 4.97K     0  too many errors
            gpt/datadisk8  ONLINE       0     0  325K

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

Nun gut... keine sehr ergiebige Liste. xD
zpool status -v:
Code: 
pool: datatank
state: DEGRADED
status: One or more devices are faulted in response to persistent errors.
        Sufficient replicas exist for the pool to continue functioning in a
        degraded state.
action: Replace the faulted device, or use 'zpool clear' to mark the device
        repaired.
  scan: resilvered 6.76M in 00:00:04 with 0 errors on Thu Jan 11 16:02:09 2024
config:

        NAME               STATE     READ WRITE CKSUM
        datatank           DEGRADED     0     0     0
          raidz2-0         DEGRADED     0     0     0
            gpt/datadisk1  ONLINE       0     0  263K
            gpt/datadisk2  ONLINE       0     0  252K
            gpt/datadisk3  ONLINE       0     0  307K
            gpt/datadisk4  ONLINE       0     0  321K
            gpt/datadisk5  ONLINE       0     0  319K
            gpt/datadisk6  FAULTED     94    85     0  too many errors
            gpt/datadisk7  FAULTED     28 4.97K     0  too many errors
            gpt/datadisk8  ONLINE       0     0  325K

errors: No known data errors

Äh was? Jetzt ist wieder alles OK? Gibt es noch einen anderen Weg da irgendwo nachzuschauen?
 
In meinem NAS hatte ich öfter mal das Problem, dass ich Disk Faults bekomme weil der Connector von der Power-Schiene am Plattenkäfig locker war. Weder MOLEX noch SATA Power halten da besonders gut. :mad:

Wenn Du so etwas ausschließen kannst würde ich so schnell wie möglich die Platten Tauschen. Dein RAID ist ja nun einen Ausfall vom Totalschaden weg. Beim Resilvern muss er dann ja komplett alle Daten lesen und wird Dir alle Fehler entweder liefern oder sie werden sich auflösen.
 
Ich muss gerade noch überlegen was ich tun will. Ob ich da jetzt noch die Platten tausche, oder gleich ein ganz neues System hinstelle. Frage ist aber mehr, ob jetzt wirklich Dateien beschädigt sind, oder nicht.

Aktuell läuft ein Vollbackup, solange fasse ich das System erst mal nicht an :D
 
Nach dem Backup disk7 (weil die die meisten Fehler hat) tauschen (Notizzettel dran, dass das disk7 ist und auf die Seite legen, ggf. brauchen wir sie später noch), resilver, gucken was passiert.
Wenn alles gut bis hierher, disk6 tauschen, gleiches Prozedere.
Viel Glück! :)


Edit:
Achja, smartctl -x beider disks wäre noch interessant zu sehen. Eventuell haben die disks selber keinen Oberflächenfehler, zwei disks gleichzeitig sterbend ist doch etwas fischig.
 
die beiden Platten sind ja schon nicht mehr ONLINE.
Da können sie auch keinen Beitrag mehr zum Pool leisten und ich denke, die können dann auch gleichzeitig getauscht werden, weil es keine Sicherheit mehr bringt, eine FAULTED Platte im Pool zu lassen.
Denke ich zumindest mal.
 
Faulted heißt nicht offline und je nachdem ob man es nach dem resilver noch braucht und nach Beschädigungsgrad der Platte kann es sein, dass man noch benötigte Bits runterkratzen kann. Gerade auch mit Blick auf den Temperaturwechsel und wenn sie dann neu anläuft....'wenn'. ;)
Btw. der resilver wird nicht schneller bei zwei gleichzeitig getauschten, er läuft trotzdem pro Platte einmal durch.

Es kann natürlich auch sein, dass ein physischer Wackler oder in der Spannungsversorgung besteht...dann besteht auch die Möglichkeit, dass der pool nach erneutem scrub plötzlich wieder healthy ist.
 
Hallo...

ein Backup (zuerst) ist immer sinnvoll... erstmal durchlaufen lassen. Ich hatte mal einen Sun Server mit 48 Platten. Und alle 2-4 Monate fiel eine Platte aus. Der lief zu Anfang unter Solaris, später unter FreeBSD... egal. Platte gewechselt, resilvert und alles war wieder okay... Ich hatte nie Datenverlust, obwohl ich zum Ende hin fast 50% der Platten verloren habe...

VG Norbert
 
Der Server ruhte jetzt eine Weile. Ich habe jetzt angefangen die Platten zu tauschen. Echt krass, ein Resilver einer (!) 4TB Platte dauerte 1.5 - 2 Tage (!).

Nunja. Nun war der Pool allgemein immer noch etwas verwirrt. Sagte es gäbe Datenfehler, ohne diese aber auflisten zu können. Die Doku empfiehlt auch nach einem Resilver ein Scrub zu machen. Also den Scrub gestartet. Heute komme ich von Arbeit nach Hause, schaue nach:

gpt/datadisk5 REMOVED

-_- Ist beim Scrub einfach noch eine Platte ausgestiegen. Ich bin mir aktuell unsicher, ob es wirklich an den Platten liegt oder ob da der Controller / die Kabel / der Plattenkäfig hier noch eine Rollle spielt. Aber zumindest bei den beiden Platten die ich getauscht hatte, meldete FreeBSD auch direkt am SATA Anschluss des Boards relativ schnell Fehler mit dem Gerät.

Aber auch hier vermutlich eine kleine Bestätigung. Wenn eine WD Red Platte einer Charge aussteigt, dann leben die Platten der gleichen Charge vermutlich auch nicht mehr lange.
 
Vllt. ein Status-Update. Habe es lange schleifen lassen. Ich hab jetzt das WE die letzte Platte getauscht. Sind jetzt also allesamt neue Platten. ZFS scrub meint weiterhin gegen Ende des Vorgangs (so bei 95% oder so), dass viele Checksum-Errors auf allen (!) Platten aufgetreten seien. Es wird auch weiterhin berichtet, dass Dateien fehlerhaft seien, ohne diese auflisten zu können. Es ist aber auch nicht sporadisch, sondern immer erst gegen Ende des Scrubs. Ich hatte gehofft, dass sich ZFS wieder selbst zusammenreißt, wenn alle Platten getauscht sind. Kann natürlich ein Hardwaredefekt am Controller, Kabel oder Festplattenkäfig sein, auf der anderen Seite ist die Stelle an der die Fehler auftreten eigentlich immer die Gleiche. Auch seltsam.

Ich muss das irgendwann noch mal die Tage mit dem damals angelegten Backup abgleichen, aber ich habe auch schon mindestens 2 defekte Dateien gefunden. Ein Video was bei der Hälfte aufhört abzuspielen und ein Bild was sich nicht mehr öffnen lässt. Ist nichts kritisches, aber ist mir eben aufgefallen.

Bin da in der Hinsicht aber nun etwas von den Versprechungen von ZFS enttäuscht. Eigentlich hatte ich ja gehofft mit dem Dateisystem genau so etwas zu vermeiden, oder eben genau zu wissen was denn Schaden genommen hat. Jetzt stehe ich halt hier und weiß im Endeffekt genauso viel als wenn ich ZFS nicht genommen hätte.

Werde dann mal überlegen den Rest der Hardware auch zu tauschen, aber das dürfte vermutlich auch noch etwas dauern.
 
-Nuke- schrieb:
Bin da in der Hinsicht aber nun etwas von den Versprechungen von ZFS enttäuscht. Eigentlich hatte ich ja gehofft mit dem Dateisystem genau so etwas zu vermeiden, oder eben genau zu wissen was denn Schaden genommen hat. Jetzt stehe ich halt hier und weiß im Endeffekt genauso viel als wenn ich ZFS nicht genommen hätte.
Zum Vergrößern anklicken....
Das Gemecker sei dir bei dem Stress gegönnt, jedoch: wenn die Hardware versagt, kann kein Dateisystem zaubern und danach sieht es für mich wirklich aus.
Nichtmal so, als dass es die Platten wären.

Um das mit den Platten abzufedern, stecke ich gerne "gemischte Ware" in die vdevs.

Hast du alle Platten noch? Wäre schade, wenn die noch ok wären und du sie schon entsorgt hättest. WD Red sollte eigentlich recht robust sein.
Über ein Jahr später, immer noch requestiert (:D)
mr44er schrieb:
Achja, smartctl -x beider disks wäre noch interessant zu sehen. Eventuell haben die disks selber keinen Oberflächenfehler, zwei disks gleichzeitig sterbend ist doch etwas fischig.
Zum Vergrößern anklicken....
 
Nene, die angemeckerten Festplatten vom ursprünglichen System waren schon hinüber. Ich hatte sie ja dann nicht an den Controller angeschlossen, sondern direkt ans Board und dort hagelte es dann massive Fehler in dmesg inkl. drop-outs aus dem System. Eine der Platten wird mittlerweile schon gar nicht mehr erkannt.

Und naja, ZFS ist schon mit der Prämisse gestartet, dass es Hardware nicht vertraut und all den ganzen Aufwand betreibt und Fehler erkennt, abfedert und auch meldet, auch wenn die Hardware darunter Blödsinn anstellt. "wenn die Hardware versagt, kann kein Dateisystem zaubern" -> Doch schon, das ist das was ZFS versprochen hatte. Sonst könnte man einen großen Batzen Arbeit den ZFS da veranstaltet auch gleich lassen.
 
Villeicht lohnt es sich wenn wir den ablauf betrachten:

-> Du hattest ein ZFS RAID-Z2, bislang war alles unaffällig, ein regelmäßiger scrub hat keine Fehler gemeldet
-> Dann, Anfang 2024 sind zwei Platten gleichzeitig ausgestiegen
-> Danach hast du mit wechselnden Fehlern probleme beim RESILVER als auch beim Scrub gehabt mit verschiedenen Platten.
-> Als Konsequenz hast du aber nicht auf einen "neuen" System das du intensiv erprobt hast ein Backup, evtl. sogar auf einen neuen ZFS wiederhergestellt, sondern hast weiter mit dem ja irgendwie problematischen Altsystem weiter probier.

Ich bin noch sicher weit entfernt davon wie @mr44er ein ZFS vollprofi zu werden, aber ZFS kann in einen gewissen definierten Rahmen Festplatten- Hardware und eigene Dateisystemfehler diverser art erkennen (!) und einen subteil davon auch ausgleichen. Das ist deutlich mehr als ntfs, ext4 und ufs können.

Aber ZFS ist kein Wundermittel, das jede art von "allgemeine Hardwarefehler" löst.
Und in diesem fall ist ja ein teil des versprechens auch eingelöst.
Es hat ja offenbar von anfang an Fehler festgestellt und dir gemeldet. Danach hast du andere Hardware genommen, und ZFS hat wieder Fehler gemeldet beim resilvern und Scrub später. Was nahelegt das entweder ein noch größeres Hardwareproblem existiert, oder das ZFS hat durch die ggf. schleichenden Fehler ein problem. Letzteres wäre sicher unschön - aber es scheint das ja erkannt zu haben was meiner Erfahrung nach deutlich mehr ist als klassische Dateisysteme können.
 
CommanderZed schrieb:
Villeicht lohnt es sich wenn wir den ablauf betrachten:

-> Du hattest ein ZFS RAID-Z2, bislang war alles unaffällig, ein regelmäßiger scrub hat keine Fehler gemeldet
-> Dann, Anfang 2024 sind zwei Platten gleichzeitig ausgestiegen
-> Danach hast du mit wechselnden Fehlern probleme beim RESILVER als auch beim Scrub gehabt mit verschiedenen Platten.
Zum Vergrößern anklicken....

Dabei gilt es zu bedenken, dass ZFS an dem Punkt "zwei Platten sind ausgestiegen" schon Dateifehler meldete, ohne sie mir aufzulisten zu können. Nur um dann ein paar Minuten später zu sagen "ne doch alles OK" (also bzgl. Dateifehler, nicht ausgefalllene Platten). An der Stelle hatte ich noch absolut gar nichts mit dem System angestellt. Ein Ausstieg von 2 Platten in einem RAID-Z2 ist nicht schön, sollte aber an sich noch kein Totalschaden sein.

Wie gesagt, ich schließe ein Fehler an anderer Hardware ja nicht aus. Aber naja, ich stelle mir nicht privat einfach zur Sicherheit mal eben für 2500-3000€ einen neuen Server hin "nur um absolut sicher zu sein". Nach dem Tausch der drei ausgefallenen Platten verhielt sich das System an sich auch wieder normal (quasi aber nur als Read-Only betrieben), nur eben mit den Checksum-Fehlern am ganz am Ende eines Scrubs. Also auch keine spontanen Faulted Platten oder sonstige Probleme.

Klar werde ich jetzt wohl um einen neuen Rechner um die Platten nicht drum rum kommen. Letztendlich hab ich von ZFS trotzdem mehr erwartet. Das könnt ihr jetzt natürlich anders sehen, aber der Bruch im Vertrauen ist halt jetzt bei mir nunmal da. Wenn das System sagt "errors: 18 data errors, use '-v' for a list", dann erwarte ich halt hinterher auch eine Liste und nicht "nichts".
 
Wenn du vor dem Tausch auf neue Platten Fehler hattest, die durch ein scrub nicht korrigiert werden konnten, werden die natürlich auch auf die neuen Platten mit übertragen. Da hilft nur das Backup.
 
Schon klar, aber die Erwartungshaltung war halt, dass mir ZFS eben genau sagen kann, was kaputt ist. Einer der Gründe warum ZFS und nicht irgendwas anderes. Im Fehlerfall 20TB+ Backup wiederherstellen kann ich überall, auch generell auf Systemen ohne ZFS oder gar RAID.
 
-Nuke- schrieb:
Schon klar, aber die Erwartungshaltung war halt, dass mir ZFS eben genau sagen kann, was kaputt ist.
Zum Vergrößern anklicken....
das habe ich auch schon mehrfach so erfahren, so lange das noch geht und so lange ich auch nicht einen scrub versuchte. Mit einem scrub verliert man die Dateinamen in Klarschrift und bekommt nur eine merkwürdige Zuordnung in Hex-Code oder so.
Was scrub ganz offenbar aber nicht ist: ein fsck. Da sollte man sich nicht falschen Hoffnungen hingeben. Mein Weg ist deshalb: fehlerhafte Dateien löschen. Sie sind nicht mehr zu reparieren.
 
Also egal ob du dich jetzt für einen anderen HBA oder reinen SATA-Controller entscheidest, wenn du diesen Zustand (disk1-5,8) am neuen nochmal stecken könntest, wäre das ideal:
Code: 
pool: datatank
state: DEGRADED
status: One or more devices are faulted in response to persistent errors.
        Sufficient replicas exist for the pool to continue functioning in a
        degraded state.
action: Replace the faulted device, or use 'zpool clear' to mark the device
        repaired.
  scan: resilvered 6.76M in 00:00:04 with 0 errors on Thu Jan 11 16:02:09 2024
config:

        NAME               STATE     READ WRITE CKSUM
        datatank           DEGRADED     0     0     0
          raidz2-0         DEGRADED     0     0     0
            gpt/datadisk1  ONLINE       0     0  263K
            gpt/datadisk2  ONLINE       0     0  252K
            gpt/datadisk3  ONLINE       0     0  307K
            gpt/datadisk4  ONLINE       0     0  321K
            gpt/datadisk5  ONLINE       0     0  319K
            gpt/datadisk6  FAULTED     94    85     0  too many errors
            gpt/datadisk7  FAULTED     28 4.97K     0  too many errors
            gpt/datadisk8  ONLINE       0     0  325K

errors: No known data errors

Wahrscheinlich ist das ab hier ab einfacher, den pool neu zu erstellen und mit dem Backup zu befüllen.
Normalerweise bräuchte man ein zweites System bzw. etwas Zeit um jede Komponente einzeln gegenprüfen zu können.
Warum der pool irgendwann mittendrin dann doch keine Fehler mehr meldete, kann daran liegen, dass die fehlerhaften Platten irgendwann ihre wiederholenden Schreibversuche aufgaben und das ist von Modell zu Modell bzw. Firmware unterschiedlich.

Das Fehlerbild könnte auch mit gesunden SMR-Platten so aussehen, das sollten die WD Reds aber nicht sein und dann kommts auch noch drauf an, was für Standbyzeiten (APM) gesetzt sind etc...
 
Das kommt jetzt natürlich viel zu spät, aber bei mir läuft über die Pools regelmäßig nen Scrub rüber. Ein hoch auf cron :)
In Deinem Fall hätte ich die "komischen" Platten gezogen den Pool gelöscht, mit neuen Platten die "komischen" ersetzt, den Pool wieder aufgebaut und das Backup wieder eingespielt.
Alles andere kostet nur sinnlos Nerven. Mit zunehmenden Alter hat man davon immer weniger :)
 
Andy_m4 schrieb:
Ergänzung dazu:
Anstatt das manuell in die crontab einzutragen, kann man es auch über die periodic.conf machen:
daily_scrub_zfs_enable="YES"
Die Tage zwischen "scrubs" kann man mit daily_scrub_zfs_default_threshold setzen, wobei der Default-Wert bei 35 liegt.
Zum Vergrößern anklicken....
Stimmt auffallend. Ich hab das Vorgehen einfach nur stur aus meinem Solaris-Universum übernommen. Hach, lange ist es her...
 
-Nuke- schrieb:
Schon klar, aber die Erwartungshaltung war halt, dass mir ZFS eben genau sagen kann, was kaputt ist. Einer der Gründe warum ZFS und nicht irgendwas anderes. Im Fehlerfall 20TB+ Backup wiederherstellen kann ich überall, auch generell auf Systemen ohne ZFS oder gar RAID.
Zum Vergrößern anklicken....

Da wüsstest vielleicht garnicht, dass du einen Fehler hast ;)

Aber prinzipiell hast du natürlich recht, normal macht ZFS das auch, aber es gibt wohl Fehler - vermutlich in den Metadaten - wo das auch ein ZFS nicht kann. Blöd gelaufen. Du könntest mal ein zdb -b -c auf den Pool schmeißen - das checkt die Metadaten. Aber einer wirklichen Lösung kommst du damit vermutlich auch nicht näher.
 
medV2 schrieb:
Du könntest mal ein zdb -b -c auf den Pool schmeißen - das checkt die Metadaten. Aber einer wirklichen Lösung kommst du damit vermutlich auch nicht näher.
Zum Vergrößern anklicken....

Zumindest hatte er da wieder gegen Ende (1min vor Schluss) ein paar Meldungen wie " "zdb_blkptr_cb: Got error 97 reading <23423, 0, 1, 5>" (irgendwelche Zahlen gerade geschrieben) und dann eine sehr lange Liste von sowas wie "leaked space: vdev 0, offset 0x1c041decd000, size 64462848"
 
Eventuell ist dann tatsächlich nur der freie Speicher betroffen und du siehst keine fehlerhaften Daten, weil du keine hast. Aber hier haben vielleicht andere noch mehr Expertiese.

Was du noch machen kannst: zpool get leaked DATAPOOL
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben