zpool defekt

[pchris]

Seit ein paar Tagen ist mein zpool kaputt.

Folgendes dürfte passiert sein: Am 4. August hat der Rechner zum ersten Mal unterwartet neugestartet. Grund dafür war ein panic:

Aug  4 07:44:46 sonne savecore[856]: reboot after panic: general protection fault
[...]
Aug  4 07:48:32 sonne kernel: Fatal trap 9: general protection fault while in kernel mode
Aug  4 07:48:32 sonne kernel: cpuid = 0; apic id = 00
Aug  4 07:48:32 sonne kernel: instruction pointer    = 0x20:0xffffffff80ef04e6
Aug  4 07:48:32 sonne kernel: stack pointer            = 0x28:0xfffffe00580310b0
Aug  4 07:48:32 sonne kernel: frame pointer            = 0x28:0xfffffe00580310f0
Aug  4 07:48:32 sonne kernel: code segment        = base 0x0, limit 0xfffff, type 0x1b
Aug  4 07:48:32 sonne kernel:             = DPL 0, pres 1, long 1, def32 0, gran 1
Aug  4 07:48:32 sonne kernel: processor eflags    = interrupt enabled, resume, IOPL = 0
Aug  4 07:48:32 sonne kernel: current process        = 1009 (syncthing)
Aug  4 07:48:32 sonne kernel: trap number        = 9
Aug  4 07:48:32 sonne kernel: panic: general protection fault
Aug  4 07:48:32 sonne kernel: cpuid = 0
Aug  4 07:48:32 sonne kernel: time = 1628055991
Aug  4 07:48:32 sonne kernel: KDB: stack backtrace:
Aug  4 07:48:32 sonne kernel: #0 0xffffffff80c0ae35 at kdb_backtrace+0x65
Aug  4 07:48:32 sonne kernel: #1 0xffffffff80bbf0eb at vpanic+0x17b
Aug  4 07:48:32 sonne kernel: #2 0xffffffff80bbef63 at panic+0x43
Aug  4 07:48:32 sonne kernel: #3 0xffffffff8108f941 at trap_fatal+0x391
Aug  4 07:48:32 sonne kernel: #4 0xffffffff8108edc7 at trap+0x67
Aug  4 07:48:32 sonne kernel: #5 0xffffffff81066d48 at calltrap+0x8
Aug  4 07:48:32 sonne kernel: #6 0xffffffff80eeb4b4 at zone_alloc_item+0x54
Aug  4 07:48:32 sonne kernel: #7 0xffffffff80eede2f at keg_alloc_slab+0x7f
Aug  4 07:48:32 sonne kernel: #8 0xffffffff80ef071d at keg_fetch_slab+0x12d
Aug  4 07:48:32 sonne kernel: #9 0xffffffff80ef0341 at zone_fetch_slab+0x61
Aug  4 07:48:32 sonne kernel: #10 0xffffffff80ef0429 at zone_import+0x69
Aug  4 07:48:32 sonne kernel: #11 0xffffffff80eec547 at uma_zalloc_arg+0x3c7
Aug  4 07:48:32 sonne kernel: #12 0xffffffff8249fd81 at abd_alloc+0x111
Aug  4 07:48:32 sonne kernel: #13 0xffffffff824a5418 at arc_hdr_alloc_pabd+0x98
Aug  4 07:48:32 sonne kernel: #14 0xffffffff824a27ad at arc_hdr_alloc+0x11d
Aug  4 07:48:32 sonne kernel: #15 0xffffffff824a2479 at arc_alloc_buf+0x29
Aug  4 07:48:32 sonne kernel: #16 0xffffffff824b1617 at dbuf_read+0x6d7
Aug  4 07:48:32 sonne kernel: #17 0xffffffff824d0dc4 at dmu_tx_check_ioerr+0x94
Aug  4 07:48:32 sonne kernel: Uptime: 2m12s
Aug  4 07:48:32 sonne kernel: Dumping 684 out of 6024 MB:..3%..12%..22%..31%..43%..52%..61%..71%..82%..92%
Aug  4 07:48:32 sonne kernel: Dump complete
Aug  4 07:48:32 sonne kernel: Automatic reboot in 15 seconds - press a key on the console to abort
Aug  4 07:48:32 sonne kernel: Rebooting...

Seit diesem Zeitpunkt sind eine Menge dieser Neustarts passiert. In /var/log/messages sind dann noch diese Einträge mir aufgefallen. Von denen gibt es seit 7. August jede Menge:

Aug  7 00:10:00 sonne ZFS[1245]: vdev state changed, pool_guid=$2615562109488913857 vdev_guid=$3207959982596511126
Aug  7 00:10:01 sonne ZFS[1246]: vdev state changed, pool_guid=$2615562109488913857 vdev_guid=$15886684296650302335

Jedenfalls sind beide vorhandenen zpools defekt. "system" funktioniert noch soweit. Das Betriebssystem bootet derzeit noch ganz normal. Aber auf den "daten" pool ist nicht mehr zugreifbar:

  pool: daten
 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 Do.  5 Aug. 04:26:04 2021
    should correct the problem.  Approximately 5 seconds of data
    must be discarded, irreversibly.  Recovery can be attempted
    by executing 'zpool clear -F daten'.  A scrub of the pool
    is strongly recommended after recovery.
   see: http://illumos.org/msg/ZFS-8000-72
  scan: scrub repaired 0 in 0 days 13:19:48 with 0 errors on Sat Jul 17 16:27:45 2021
config:

    NAME        STATE     READ WRITE CKSUM
    daten       FAULTED      0     0     2
      mirror-0  ONLINE       0     0     8
        ada1    ONLINE       0     0     8
        ada0    ONLINE       0     0     8

  pool: system
 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://illumos.org/msg/ZFS-8000-8A
  scan: scrub repaired 0 in 0 days 00:09:51 with 0 errors on Sat Jul 17 03:17:51 2021
config:

    NAME             STATE     READ WRITE CKSUM
    system           ONLINE       0     0     0
      mirror-0       ONLINE       0     0     0
        gpt/system0  ONLINE       0     0     0
        gpt/system1  ONLINE       0     0     0

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

Ein zpool clear -F daten habe ich bereits probiert. Aber es war leider nicht erfolgreich: cannot clear errors for daten: I/O error.

Was kann ich jetzt noch tun?

 

[medV2]

Schau mal was smartctl -a zu den beiden Platten ada0 und ada1 sagt. Vielleicht ist da eine defekt, dann könnte es helfen die zuerst replacen und dann den clear versuchen.

Wenn du kein Backup hast und die Daten wichtig für dich sind: Zuerst mit dd - oder wenn das zickt dd_rescue - ein Backup von ada0 und 1 machen!

 

[Yamagi]

reboot after panic: general protection fault

Ein General Protecion Fault ist ein Hinweis - aber kein Beweis - darauf, dass ein kaputtes Gerät Daten außerhalb seiner DMA-Zone quer durch den RAM geschrieben hat. An so einen Mist habe ich auch schon Pools verloren, zuletzt durch eine ältere PCI-Karte für die der "Almost PCI"-Slot des Mainboards etwas zu "Almost" war... Leider ist sowas schwer nachzuvollziehen, genauso gut kann es ein Alphateilchen an der falschen Stelle gewesen sein. Man muss es aber im Hinterkopf behalten, vor allem sollte man wenn möglich die Platten für eventuelle Wiederherstellungsversuche an andere Hardware stecken.

 

[turrican]

Prüf mal mit smartctl deine Festplattendevices (smartctl -a /dev/<device>) und schau folgende Were an:

5 Reallocated_Sector_Ct
196 Reallocated_Event_Count
197 Current_Pending_Sector
198 Offline_Uncorrectable

Die Werte sollten idealerweise auf 0 stehen; wenn deine Platten speziell bei 197 und 198 Werte >0 haben, dann solltest du die Platten vorsichtshalber ersetzen.

 

[pchris]

Die SMART Werte schauen gut aus. Bei allen vier Platten sind die erwähnten Werte genau 0. Es sind auch keine Errors geloggt.

Ich habe mir jetzt einmal zwei neue Festplatten bestellt. Auf diese werde ich dann die bestehenden Daten kopieren. Und weitere Versuche dann nur auf den Kopien durchführen.
Andere Hardware hab ich im Moment nicht direkt zur Hand. Aber der Rechner, bei dem das passiert ist, könnte schön langsam eh erneuert werden (da steckt noch ein Pentium D drin). Viellecht ziehe ich hier die Hardware-Neuanschaffung vor.

 

[mr44er]

Andere Hardware hab ich im Moment nicht direkt zur Hand.

Es wäre sicherer, die Platten abzuklemmen und den Kopiervorgang auf anderer Hardware durchzuführen. Im ganz dummen Fall, sollte die HW tatsächlich defekt sein, wird die Kopie noch schlimmer. Sofern der Vorgang überhaupt durchläuft. Es kann auch sein, dass du den pool dann gänzlich grillst.
Der system-pool meckert übrigens auch, war das auch schon vor dem crash oder ist das System sogar deswegen gecrasht?

Anderer Vorschlag, wenn du es absolut mit dieser HW versuchen magst: Du hast einen mirror-pool, damit hast du bereits eine Kopie. Ich würde somit eine Münze werfen, eine der beiden Platten ausbauen und vorsorglich wegpacken. Dann eine der neuen Platten dazupacken, replace/resilver und Daumen drücken.

Wenn das schiefgeht, hast du hoffentlich noch ein Kaltbackup?

 

[turrican]

Die SMART Werte schauen gut aus. Bei allen vier Platten sind die erwähnten Werte genau 0. Es sind auch keine Errors geloggt.

Das ist doch schon mal positiv - wobei man auch hier einen etwaigen Festplattendefekt aber auch nicht 100% ausschließen kann.
Könnte auch was auf dem Weg zur Festplatte hin sein - Controllerchip, Kabel, Steckverbindung, die Platine auf der FP selber usw.

Hast du im syslog "CAM status" Errors für diese Devices stehen? Die wurden bei mir mal von einem defekten Kabel verursacht.
Schauen so in der Form aus: (da0:ahcich0:0:0:0): CAM status: Uncorrectable parity/CRC error

 

[PMc]

Ein zpool clear -F daten habe ich bereits probiert. Aber es war leider nicht erfolgreich: cannot clear errors for daten: I/O error.

Was kann ich jetzt noch tun?

Nicht "noch", sondern "zuerst". Zuerst den Pool komplett vergessen und die Hardware zum Funktionieren bringen. Vorher aber noch, falls die Daten wichtig sind: die Daten (oder was davon noch da ist) in Sicherheit bringen, also die Platten (flächenmäßig, mit 'dd', nicht mit zfs-tools) image-kopieren. Besser noch die Platten ausbauen, aber dann ist das System nicht mehr identisch.

Dann diese Checkstops abstellen. Irgendwas an dem Blech ist kaputt (sehr wahrsch. hardwaremäßig), und das muss behoben werden.

Dann kommen die Platten dran. Und zwar unabhängig vom ZFS. ZFS ist ja nur eine logische Struktur auf den Daten - darunterliegend ist die disk einfach eine große Fläche von beliebigen Daten. Wenn also ZFS einen i/o error sieht, dann kann es sein dass die Platte einen i/o error hat (also hardwareproblem), oder auch dass die Daten lesbar und einwandfrei sind, und lediglich logisch keinen Sinn für ZFS ergeben (softwareproblem) - dann muss man den Pool debuggen.
Also, sobald das System wieder einwandfrei funktioniert, schauen ob die Platten sich einwandfrei lesen lassen, mit 'dd', von vorn bis hinten - und dabei mit 'gstat -po' schauen ob die Zeiten so okay sind (manchmal werden die einfach nur langsam wenn der Stromstecker schlecht sitzt).

Wenn das dann soweit alles sichergestellt ist, dann kann man sich das ZFS vornehmen. Dazu gibt es Artikel auf dem Web, wie man mit dem 'zdb' wurschtelt...

 

[pchris]

Ich habe ganz vergessen, mich für die Hinweise zu bedanken.

Was habe ich gemacht:

• Auf anderer Hardware eine 1:1-Kopie mit dd auf eine fabrikneue Festplatte gemacht.
• Auf jener anderen Hardware ein Live-FreeBSD gestartet.
• Ein zpool import -f -F ... hat den Pool dann erfolgreich eingebunden.
• Die zweite neue Festplatte dazugehängt und den Mirror mit dieser Platte resilvert.
• Die beiden neuen Platten in neuangeschaffte Hardware gesteckt.