ZFS-Fehler ... was ist defekt?

[whiterabbit]

Hallo.
Unser Server meldet seit heute einen Fehler mit einem ZFS-Pool:

zpool status

  pool: zfs-pool-1
 state: ONLINE
status: One or more devices has experienced an unrecoverable error.  An
        attempt was made to correct the error.  Applications are unaffected.
action: Determine if the device needs to be replaced, and clear the errors
        using 'zpool clear' or replace the device with 'zpool replace'.
   see: https://openzfs.github.io/openzfs-docs/msg/ZFS-8000-9P
  scan: scrub repaired 0B in 01:24:00 with 0 errors on Sun Sep 11 01:48:07 2022
config:

        NAME                      STATE     READ WRITE CKSUM
        zfs-pool-1                ONLINE       0     0     0
          raidz2-0                ONLINE       0     0     0
            sda                   ONLINE       0     0     0
            sdb                   ONLINE       0     0     0
            sdc                   ONLINE       0     0     0
            sdd                   ONLINE       0     0     0
        cache
          wwn-0x5001b44bf81eb531  ONLINE    371K  160M     0

errors: No known data errors

Ist da die Cache-Platte defekt oder wie muss man die letzte Zeile interpretieren?
Danke.

 

[scaa]

Was meinst Du was "Keine bekannten Datenfehler" bedeuten könnte?

 

[fireon]

Da sieht man jetzt nichts was nicht passen sollte. Ich würde mir als nächsten Schritte die Smartwerte ansehen. Einen LogTest machen und das ganze beobachten. https://wiki.ubuntuusers.de/Festplattenstatus/

Eben wie alte sind die HDD's, welche Laufzeit, wie wurden sie eingeschalten, gab es viel. schon mal CRC Errors, usw.

Für erste würd ich mal ein

zpool clear zfs-pool-1

machen.

 

[whiterabbit]

Hallo. Den "clear"-Befehl hatte ich natürlich schon ausprobiert -- führte aber zu nichts bzw blieb die Fehlermeldung bestehen

Da der Pool ja mit "no known data errors" in Ordnung zu sein scheint, habe ich mir nun smartclt angesehen. Dort habe ich z.B. das hier gesehen:

Spoiler: Ausgabe von smartctl

smartctl 7.2 2020-12-30 r5155 [x86_64-linux-5.4.124-1-pve] (local build)
Copyright (C) 2002-20, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Vendor:               HGST
Product:              HUC101818CS4204
Revision:             CDB0
Compliance:           SPC-4
User Capacity:        1,800,360,124,416 bytes [1.80 TB]
Logical block size:   512 bytes
Physical block size:  4096 bytes
LU is fully provisioned
Rotation Rate:        10520 rpm
Form Factor:          2.5 inches
Logical Unit id:      0x5000cca02c205a5c
Serial number:        08GKTL2A
Device type:          disk
Transport protocol:   SAS (SPL-3)
Local Time is:        Fri Sep 23 08:39:02 2022 CEST
SMART support is:     Available - device has SMART capability.
SMART support is:     Enabled
Temperature Warning:  Enabled

=== START OF READ SMART DATA SECTION ===
SMART Health Status: OK

Current Drive Temperature:     32 C
Drive Trip Temperature:        85 C

Accumulated power on time, hours:minutes 19289:29
Manufactured in week 35 of year 2018
Specified cycle count over device lifetime:  50000
Accumulated start-stop cycles:  23
Specified load-unload count over device lifetime:  600000
Accumulated load-unload cycles:  794
Elements in grown defect list: 0

Vendor (Seagate Cache) information
  Blocks sent to initiator = 33639477503066112

Error counter log:
           Errors Corrected by           Total   Correction     Gigabytes    Total
               ECC          rereads/    errors   algorithm      processed    uncorrected
           fast | delayed   rewrites  corrected  invocations   [10^9 bytes]  errors
read:          0    15698         0     15698   29808049      93924.215           0
write:         0        0         0         0    1659561      44658.080           0
verify:        0        0         0         0    8322625          0.000           0

Non-medium error count:        0

No Self-tests have been logged

Man sieht dort, dass es auf dieser Platte ja durchaus korrigierte Lesefehler gab -- unter'm Strich aber alles ok zu sein scheint.
Ich weiß nun nicht genau, wie/wo ich den ZFS-Fehler weiter eingrenzen soll.

Nur nochmal zur Sicherheit: Die Angabe bei der Cache Platte ist so richtig? Dort steht bei read/write ja keine 0 ...
Danke nochmal für's Mitdenken!

 

[Dunuin]

Naja, 160 Millionen Schreibfehler sind schon eine Menge. Kein Wunder dass ZFS da meckert. Ist halt die Frage woher die Fehler kommen, wenn es keine sterbende Disk ist. Fehler beim L2ARC sind halt nur nicht so wild, da es nur redundante gecachte Daten sind. Würde ich trotzdem mal die Platte tauschen und gucken ob dann keine neuen Fehler auftauchen.

Mit smartctl -t long /dev/DeineDisk könntest du auch mal einen langen Selbsttest der Disk anordnen.

 

[whiterabbit]

Naja, 160 Millionen Schreibfehler sind schon eine Menge. Kein Wunder dass ZFS da meckert.

Aber die 160 Mio beziehen sich ja auf die Cache-Platte. Wenn ich mich richtig erinnere, kann man die ja schnell aus einem Pool wieder entfernen und dann schauen, ob ohne Cache-Platte weiterhin gemeckert wird, richtig?
Einen langen Selbsttest habe ich auf /dev/sdd bereits angeworfen -- die Fertigstellung dauert aber noch etwas ...

 

[Dunuin]

Wenn dann solltest du die wwn-0x5001b44bf81eb531 mal selbsttesten. Die macht ja die Probleme.
Und dein letzter Scrub ist auch schon 2 Wochen her. Kann durchaus sein, dass da Checksum-Error existieren, die ZFS aber noch nicht kennt, weil die erst nach dem letzten Scrub aufgetreten sind. Scrub einmal anwerfen würde da auch nicht schaden.

 

[whiterabbit]

Ich habe in der Zwischenzeit direkt am dell-Server nachgesehen ... aus Gründen, die ich nicht nachvollziehen kann, blinkte der Slot dieser SSD gelb (anstatt durchgehend grün). Ich habe die Platte im iDrac identifiziert und wollte die Seriennummer mit

ls -1 /dev/disk/by-id/

finden ... da wurde sie aber gar nicht gezeigt.

Kurzerhand also die Platte aus dem Server gezogen und neu gesteckt ... jetzt wird sie wieder gefunden (LED leuchtet auch wieder grün). Ob das nun eine einmalige Sache war oder ob die Platte stirbt, kann ich noch nicht sagen. Das scrub läuft auf dem Pool noch.

 

[fireon]

finden ... da wurde sie aber gar nicht gezeigt.

Was wird denn angezeigt? Der Controller läuft im HBA-Mode?

 

[whiterabbit]

Sie war einfach "weg" ... erst nachdem ich sie neu gesteckt habe, wurde auch die SAS-ID wieder gefunden. Warum es da keine andere / gravierendere Warnung gab, weiß ich nicht.
Und: Ja, der Controller läuft im HBA-Modus.

 

[whiterabbit]

Ich habe die Cache-Platte aus dem Pool entfernt ... ging problemlos:
zpool remove zfs-pool-1 wwn-0x5001b44bf81eb531

Ich werde die Platte Montag checken und dann eine andere einbauen. Ich meine, dass das eh eine 08/15-Consumerware-Platte war, die ich da mal eingebaut hatte, um zu schauen, ob das was in Sachen Geschwindigkeit bringt. Sie muss irgendwie da vergessen worden sein

Wo wir aber gerade dabei sind: Wie macht ihr das? Lohnt sich eine Cache-SSD oder zusätzlich eine Log-SSD / ZIL bei 4 Platten überhaupt schon?

Nachtrag: Das wurde hier schon mal diskutiert: https://forum.proxmox.com/threads/zfs-cache-nachträglich-einrichten.81602/post-360225

 

[Dunuin]

Hängt immer von deinem Workload ab. Aber fast immer bringen SLOG und L2ARC so gut wie nichts, bzw wäre es gleich besser einfach mehr RAM zu kaufen und die HDDs komplett gegen Enterprise SSDs auszutauschen.
Was etwas bringt sind SSDs als Special Metadata Device. Das verdoppelte bis verdreifacht hier gut die IOPS Performance und das selbst bei async Writes. Das ist dann aber kein Cache und wenn die SSD draufgeht, dann sind auch alle Daten der HDDs weg. Da braucht man dann also mehrere zuverlässige SSDs im Mirror.