Defekter ZFS Pool

H

Heinrich

Guest
Hallo Leute,
Ich habe hier ein Problem mit einem kaputten ZFS-Pool:
root@fbsdnas [~] # zpool status -xv pool: bigdata 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: [URL]http://illumos.org/msg/ZFS-8000-8A[/URL] scan: scrub in progress since Wed Jan 23 17:26:02 2019 864G scanned out of 2.60T at 61.6M/s, 8h18m to go 0 repaired, 32.42% done config: NAME STATE READ WRITE CKSUM bigdata ONLINE 0 0 38 da1p1 ONLINE 0 0 76 errors: Permanent errors have been detected in the following files: /bigdata/heinrich/newdata/.zfs/snapshot/2019-01-10-03:00:00/store.sparsebundle/bands/6927 /bigdata/heinrich/newdata/.zfs/snapshot/2019-01-19-03:00:00/store.sparsebundle/bands/6927 /bigdata/heinrich/newdata/.zfs/snapshot/2019-01-23-03:00:00/store.sparsebundle/bands/6927 /bigdata/heinrich/newdata/.zfs/snapshot/2019-01-07-03:00:00/store.sparsebundle/bands/6927 <0xf20>:<0xb0143> <0x1128>:<0x77548> /bigdata/heinrich/newdata/.zfs/snapshot/2018-12-29-03:00:00/store.sparsebundle/bands/6927 /bigdata/heinrich/newdata/.zfs/snapshot/2018-12-29-03:00:00/store.sparsebundle/bands/1d08 /bigdata/heinrich/newdata/.zfs/snapshot/2019-01-20-03:00:00/store.sparsebundle/bands/6927 /bigdata/heinrich/newdata/store.sparsebundle/bands/6927 /bigdata/heinrich/newdata/store.sparsebundle/bands/1d08 /bigdata/heinrich/newdata/.zfs/snapshot/2018-12-30-03:00:00/store.sparsebundle/bands/1d08 /bigdata/heinrich/newdata/.zfs/snapshot/2018-12-21-03:00:00/store.sparsebundle/bands/6927 /bigdata/heinrich/newdata/.zfs/snapshot/2018-12-21-03:00:00/store.sparsebundle/bands/1d08 /bigdata/heinrich/newdata/.zfs/snapshot/2018-12-26-03:00:00/store.sparsebundle/bands/6927 /bigdata/heinrich/newdata/.zfs/snapshot/2018-12-26-03:00:00/store.sparsebundle/bands/1d08 /bigdata/heinrich/newdata/.zfs/snapshot/2019-01-16-03:00:00/store.sparsebundle/bands/6927 /bigdata/heinrich/newdata/.zfs/snapshot/2019-01-12-03:00:00/store.sparsebundle/bands/6927 <0xf50>:<0xb0143> /bigdata/heinrich/newdata/.zfs/snapshot/2019-01-21-03:00:00/store.sparsebundle/bands/6927 /bigdata/heinrich/newdata/.zfs/snapshot/2018-12-22-03:00:00/store.sparsebundle/bands/6927 /bigdata/heinrich/newdata/.zfs/snapshot/2018-12-22-03:00:00/store.sparsebundle/bands/1d08 /bigdata/heinrich/newdata/.zfs/snapshot/2019-01-14-03:00:00/store.sparsebundle/bands/6927 /bigdata/heinrich/newdata/.zfs/snapshot/2018-12-27-03:00:00/store.sparsebundle/bands/6927 /bigdata/heinrich/newdata/.zfs/snapshot/2018-12-27-03:00:00/store.sparsebundle/bands/1d08 <0x129e>:<0x77548> /bigdata/heinrich/newdata/.zfs/snapshot/2019-01-22-03:00:00/store.sparsebundle/bands/6927 /bigdata/heinrich/newdata/.zfs/snapshot/2018-12-23-03:00:00/store.sparsebundle/bands/1d08 /bigdata/heinrich/newdata/.zfs/snapshot/2019-01-04-03:00:00/store.sparsebundle/bands/6927 /bigdata/heinrich/newdata/.zfs/snapshot/2019-01-17-03:00:00/store.sparsebundle/bands/6927 /bigdata/heinrich/newdata/.zfs/snapshot/2018-12-25-03:00:00/store.sparsebundle/bands/6927 /bigdata/heinrich/newdata/.zfs/snapshot/2018-12-25-03:00:00/store.sparsebundle/bands/1d08 /bigdata/heinrich/newdata/.zfs/snapshot/2018-12-28-03:00:00/store.sparsebundle/bands/6927 /bigdata/heinrich/newdata/.zfs/snapshot/2018-12-28-03:00:00/store.sparsebundle/bands/1d08 /bigdata/heinrich/newdata/.zfs/snapshot/2018-12-24-03:00:00/store.sparsebundle/bands/1d08 /bigdata/heinrich/newdata/.zfs/snapshot/2019-01-11-03:00:00/store.sparsebundle/bands/6927 /bigdata/heinrich/newdata/.zfs/snapshot/2018-12-19-03:00:00/store.sparsebundle/bands/1d08 /bigdata/heinrich/newdata/.zfs/snapshot/2019-01-18-03:00:00/store.sparsebundle/bands/6927 /bigdata/heinrich/newdata/.zfs/snapshot/2018-12-20-03:00:00/store.sparsebundle/bands/1d08 root@fbsdnas [~] # uname -a FreeBSD fbsdnas 11.1-RELEASE FreeBSD 11.1-RELEASE #0 r321309: Fri Jul 21 02:08:28 UTC 2017 [EMAIL]root@releng2.nyi.freebsd.org[/EMAIL]:/usr/obj/usr/src/sys/GENERIC amd64 root@fbsdnas [~] #
Man sieht, dass eigentlich nur 2 Dateien defekt sind: 6927 und 1d08, allerdings leider auch in allen Snapshots seit dem 19.12.2018.
Z. Zt. Läuft noch ein Scrub, der nach evtl. weiteren defekten Dateien sucht.

Ich könnte nun ein Rollback auf den letzten noch intakten Snapshot versuchen, dabei alle neueren Snapshots löschen.

Meine Frage nun: Habe ich dann auch wieder einen intakten Pool? Oder doch lieber den letzten guten Snapshot auf externe Platte spielen, Pool löschen und (evtl. auf neuer Festplatte) neu kreieren?

Noch ein paar Infos: Der Pool besteht aus nur 1 Platte, ich benutze ZFS hauptsächlich wegen der Snapshot- und Backup-Möglichkeiten. Ausserdem läuft das Ganze unter VMware ESXi-6.5.0-20170104001-standard.
 
Du kannst auch Dateien aus dem snapshot wiederherstellen- wenn du weißt, welche datein betroffen sind. Warte erstmal den scrub ab.
 
Das Problem ist bloss, dass diese Dateien alle Bestandteile eines MacOS sparsebundle (Diskimage) sind. Ich fürchte, dass beim Austausch einzelner Dateien dann das Filesystem auf dem Diskimage korrupt ist. Dann doch lieber ein komplettes Rollback.
 
Bei mir hatte timemachine laufend die sparsebundles zerlegt - war zwar nicht zfs, aber das ist unerheblich. Ich bin von timemachine über netzwerk weg, war mir zu nervig, laufend 300gb backup neu anzulegen..
 
Da ist die Hardware in irgendeiner Form defekt. Entweder hat das gute VMware Mist gebaut, die Verkabelung, die Platten selbst, der RAM, es gibt viele Möglichkeiten. Snapshots werden dich nicht retten, außer es sind wirklich nur Snapshots und nicht der aktuelle Stand betroffen. Was voraussetzt, dass die Dateien zwischen den Snapshots einmal überschrieben wurden. Daher, wie ZFS schon sagt: Die Ursache finden und beheben, dann die fraglichen Dateien aus dem Backup zurückspielen.
 
Der Scrub ist jetzt durchgelaufen und der Pool sieht jetzt so aus:
root@fbsdnas [~] # zpool status -xv pool: bigdata 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 12h54m with 2 errors on Thu Jan 24 06:20:05 2019 config: NAME STATE READ WRITE CKSUM bigdata ONLINE 0 0 42 da1p1 ONLINE 0 0 84 errors: Permanent errors have been detected in the following files: <0xf20>:<0xb0143> <0x1128>:<0x77548> /bigdata/heinrich/newdata/store.sparsebundle/bands/6927 /bigdata/heinrich/newdata/store.sparsebundle/bands/1d08 <0xf50>:<0xb0143> <0x129e>:<0x77548> /bigdata/heinrich/newdata/.zfs/snapshot/2018-12-19-03:00:00/store.sparsebundle/bands/6927 /bigdata/heinrich/newdata/.zfs/snapshot/2018-12-19-03:00:00/store.sparsebundle/bands/1d08 root@fbsdnas [~] #

Jetzt werden noch der aktuelle Stand und der Snapshot vom 19.12.2018 angemeckert, die dazwischen liegenden Snapshot aus irgend einem Grund nicht mehr, wieso eigentlich nicht?
Was ist jetzt mit dem Snapshot vom 18.12. Müsste der nicht ok sein?
Der letzte Snapshot, den ich auf externe Platte gesichert habe, war vom 3.12. Ich könnte jetzt wenigstens die externe Platte auf den Stand vom 18.12. "hochziehen". Weiterhin mal schauen, was sich seitdem überhaupt an Dateien geändert hat und versuchen die einzeln zu sichern. Viel kann es nicht sein.
Dann könnte ich nach Überprüfung der Hardware den Pool neu kreieren und von der externen Platte zurückspielen.
 
Hier mal der der Output von smartctl -a der Platte:
root@fbsdnas [~] # smartctl -a /dev/da1 smartctl 6.5 2016-05-07 r4318 [FreeBSD 11.1-RELEASE amd64] (local build) Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org === START OF INFORMATION SECTION === Model Family: Western Digital Red Device Model: WDC WD30EFRX-68EUZN0 Serial Number: WD-WCC4N6JUURCV LU WWN Device Id: 5 0014ee 26416132b Firmware Version: 82.00A82 User Capacity: 3,000,592,982,016 bytes [3.00 TB] Sector Sizes: 512 bytes logical, 4096 bytes physical Rotation Rate: 5400 rpm Device is: In smartctl database [for details use: -P show] ATA Version is: ACS-2 (minor revision not indicated) SATA Version is: SATA 3.0, 6.0 Gb/s (current: 3.0 Gb/s) Local Time is: Thu Jan 24 11:14:48 2019 CET SMART support is: Available - device has SMART capability. SMART support is: Enabled === START OF READ SMART DATA SECTION === SMART Status command failed: scsi error unsupported field in scsi command SMART overall-health self-assessment test result: PASSED Warning: This result is based on an Attribute check. General SMART Values: Offline data collection status: (0x00)Offline data collection activity was never started. Auto Offline Data Collection: Disabled. Self-test execution status: ( 0)The previous self-test routine completed without error or no self-test has ever been run. Total time to complete Offline data collection: (39540) seconds. Offline data collection capabilities: (0x7b) SMART execute Offline immediate. Auto Offline data collection on/off support. Suspend Offline collection upon new command. Offline surface scan supported. Self-test supported. Conveyance Self-test supported. Selective Self-test supported. SMART capabilities: (0x0003)Saves SMART data before entering power-saving mode. Supports SMART auto save timer. Error logging capability: (0x01)Error logging supported. General Purpose Logging supported. Short self-test routine recommended polling time: ( 2) minutes. Extended self-test routine recommended polling time: ( 397) minutes. Conveyance self-test routine recommended polling time: ( 5) minutes. SCT capabilities: (0x703d)SCT Status supported. SCT Error Recovery Control supported. SCT Feature Control supported. SCT Data Table supported. SMART Attributes Data Structure revision number: 16 Vendor Specific SMART Attributes with Thresholds: [FONT=courier new]ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x002f 200 200 051 Pre-fail Always - 0 3 Spin_Up_Time 0x0027 180 178 021 Pre-fail Always - 6000 4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 18 5 Reallocated_Sector_Ct 0x0033 200 200 140 Pre-fail Always - 0 7 Seek_Error_Rate 0x002e 200 200 000 Old_age Always - 0 9 Power_On_Hours 0x0032 087 087 000 Old_age Always - 9713 10 Spin_Retry_Count 0x0032 100 253 000 Old_age Always - 0 11 Calibration_Retry_Count 0x0032 100 253 000 Old_age Always - 0 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 15 192 Power-Off_Retract_Count 0x0032 200 200 000 Old_age Always - 2 193 Load_Cycle_Count 0x0032 196 196 000 Old_age Always - 12522 194 Temperature_Celsius 0x0022 112 102 000 Old_age Always - 38 196 Reallocated_Event_Count 0x0032 200 200 000 Old_age Always - 0 197 Current_Pending_Sector 0x0032 200 200 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0030 100 253 000 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x0032 200 200 000 Old_age Always - 0 200 Multi_Zone_Error_Rate 0x0008 100 253 000 Old_age Offline - 0[/FONT] SMART Error Log Version: 1 No Errors Logged SMART Self-test log structure revision number 1 No self-tests have been logged. [To run self-tests, use: smartctl -t] SMART Selective self-test log data structure revision number 1 SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS 1 0 0 Not_testing 2 0 0 Not_testing 3 0 0 Not_testing 4 0 0 Not_testing 5 0 0 Not_testing Selective self-test flags (0x0): After scanning selected spans, do NOT read-scan remainder of disk. If Selective self-test is pending on power-up, resume after 0 minute delay. root@fbsdnas [~] #

Hiernach scheint die Platte ok zu sein. Wie könnte ich das noch gründlicher testen?
 
Bei mir hatte timemachine laufend die sparsebundles zerlegt - war zwar nicht zfs, aber das ist unerheblich. Ich bin von timemachine über netzwerk weg, war mir zu nervig, laufend 300gb backup neu anzulegen..
Von Time Machine bin ich auch schon lange weg. Hing selbst bei lokalen Platten, auf Netzwerk-Platten wurden zu kleine sparsebundles angelegt, so dass die Sicherung wegen Platzmangels abbrach und und und..
Das sparse bundle, um das es hier geht, ist meine Arbeits-Disk und wird per ZFS send auf eine externe Platte gesichert, nur ist die letzte Sicherung schon einige Wochen her...
 
Wie könnte ich das noch gründlicher testen?
Code:
smartctl -t long /dev/da1
Das wird bei 3TB aber ein paar Stunden fressen und nichts an den Daten retten können, eher machts noch mehr kaputt, wenn defekte Sektoren gefunden und ausgetauscht werden, während irgendwas an der Mechanik endgültig stirbt, was man nie ausschließen kann.

Dann könnte ich nach Überprüfung der Hardware den Pool neu kreieren und von der externen Platte zurückspielen.
Darauf wirds hinauslaufen. An dieser Stelle wieder: öfter BACKUP! und mal Redundanz für den Pool. ;)
 
Es wird immer spannender:
panic: solaris assert: arc_decompress(buf) == 0 (0x5 == 0x0), file: /usr/src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c, line: 4923 cpuid = 1 KDB: stack backtrace: #0 0xffffffff80aada97 at kdb_backtrace+0x67 #1 0xffffffff80a6bb76 at vpanic+0x186 #2 0xffffffff80a6b9e3 at panic+0x43 #3 0xffffffff8248023c at assfail3+0x2c #4 0xffffffff8218e2e0 at arc_read+0x9f0 #5 0xffffffff821a557c at dmu_send_impl+0x8cc #6 0xffffffff821a4c86 at dmu_send_obj+0x186 #7 0xffffffff82230c06 at zfs_ioc_send+0x1d6 #8 0xffffffff82233c26 at zfsdev_ioctl+0x6d6 #9 0xffffffff8093ae08 at devfs_ioctl_f+0x128 #10 0xffffffff80ac93e5 at kern_ioctl+0x255 #11 0xffffffff80ac911f at sys_ioctl+0x16f #12 0xffffffff80ee0394 at amd64_syscall+0x6c4 #13 0xffffffff80ec392b at Xfast_syscall+0xfb Uptime: 1d0h37m4s Dumping 1884 out of 8156 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91% Dump complete

Passierte beim Übertragen von Daten auf die externe Platte...
 
Kiste runterfahren, Platten abklemmen. Alle!

memtest86+ laufen lassen, ich vermute da defekten RAM.
 
Kiste runterfahren, Platten abklemmen. Alle!

memtest86+ laufen lassen, ich vermute da defekten RAM.
Ich bin beeindruckt. Das erste Mal in meinem Leben findet memtest86 mir einen Speicherfehler! Ich war erst skeptisch, da ich, wie gesagt, in meinem ganzen Berufsleben nie einen Speicherfehler gefunden habe und auch nie einen Riegel tauschen musste. Aber dann dachte ich mir "schaden kann es ja nicht". Und siehe da: nach weniger als 1 min. kam der erste Fehler:

IMG_20190124_213625.jpg


Ich hab dann erst die Platten abgeklemmt, falls die zu viel Strom ziehen, aber der Fehler kam wieder, selbe Adresse, aber ein anderes Bit. Der Test läuft jetzt über Nacht weiter, mal sehen..
 
Jep...womit sich erklärt, warum der pool Inkonsistenz zeigt.

Nun kann man davon ausgehen, dass die Platte ok ist. Jetzt könnte mit neuem RAM ein erneuter scrub Wunder bewirken. Könnte.

Für mich ist es das erste Mal, dass ich mitbekomme, dass ein pool durch defekten RAM stirbt. Ich wette, es sähe anders aus, wenn Redundanz vorhanden wäre. Zaunpfahl! ;)
 
Frage am Rande, redundant ist ein Pool bei mir mit ZMIRROR. Das hätte doch die Fehler wie oben nicht verhindert? Beim RAM Ausfall...
 
Jep...womit sich erklärt, warum der pool Inkonsistenz zeigt.

Nun kann man davon ausgehen, dass die Platte ok ist. Jetzt könnte mit neuem RAM ein erneuter scrub Wunder bewirken. Könnte.

Für mich ist es das erste Mal, dass ich mitbekomme, dass ein pool durch defekten RAM stirbt. Ich wette, es sähe anders aus, wenn Redundanz vorhanden wäre. Zaunpfahl! ;)
Da bin ich mir nicht so sicher. Ich kenne zwar die Interna von ZFS nicht, aber wenn es aufgrund eines Speicherfehlers eine falsch berechnete Checksum auf beide Platten schreibt, hilft das auch nicht viel. Da sollte der Zaunpfahl dann auf jeden Fall auch noch in Richtung ECC RAM zeigen.
Ich wüsste auch nicht, wie ein Scrub mir die kaputt gegangenen Daten zurückbringen sollte. Ich traue eigentlich dem ganzen Pool nicht mehr und werde ihn deshalb neu anlegen und die Daten zurückspielen.
Der RAM-Test sieht jetzt so aus:
IMG_0003.JPG

Die unteren 8 GB sind wohl kaputt, d.h. ich werde die erstmal austauschen und dann erneut einen RAM-Test fahren.
 
Ich hatte Mal einen Fall in den ich mehrere memtest-Instanzen parallel laufen lassen musste um den RAM Fehler zu finden. Ein Prozess hat einfach nicht genug lässt erzeugt. Das Problem war thermisch. Ich musste den Takt senken.
 
Ich bin jetzt nicht ganz sicher, welche Module betroffen sind. Ich habe 4x4GB in den Slots A1,B1,A2,B2. Welche sind jetzt für die unteren 8GB zuständig, A1,B1 oder A1,A2?
 
Ok, hab noch mal gegoogelt, es müssen wohl A1,B1sein. Ich werd die mal rausnehmen und nochmal memtest fahren..
 
Wie ich das sehe macht er ein Backup auf eine ZFS Platte und von der nochmal ein Backup auf eine externe Platte. Denke das ist genug Redundanz :D
 
Ganz so ist das nicht. Die ZFS-Platte ist meine Arbeits-Disk. Von der mache ich Backup auf die externe Platte.
Zum Thema Redundanz später mehr. Im Moment kämpfe ich noch mit den Speicherfehlern. Ich habe ja eine Bank (A1,B1) rausgezogen aber memtest findet trotzdem noch Fehler:
IMG_20190125_182151.jpg

Der Fehler kommt nur bei 2 eingebauten Riegeln. Wenn man sie einzeln testet, sind sie ok.

Vielleicht kann mir hier mal einer helfen, ich hab zuwenig Erfahrung mit Speicherriegeln:
Ich habe 4x4GB eingebaut. Wie ist die Zuordnung des Adressraum zu den Slots A1,B1,A2,B2? Ist jeder Riegel für einen 4GB-Bereich? Wenn ja, welcher für welchen?
 
Teste mal mit aktiviertem SMP (muss man schnell drücken nachdem memtest startet)
Jeden Riegel einzeln in jedem Slot. Schreib dir dann auf, welcher Riegel in welchem Slot Fehler wirft.

Kann auch sein, dass a weng Staub auf den Kontakten liegt.
 
Zurück
Oben