• Diese Seite verwendet Cookies. Indem du diese Website weiterhin nutzt, erklärst du dich mit der Verwendung von Cookies einverstanden. Erfahre mehr

Defekter ZFS Pool

Heinrich

Active Member
Themenstarter #1
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.
 

Esjott

Kellerkind
#2
Du kannst auch Dateien aus dem snapshot wiederherstellen- wenn du weißt, welche datein betroffen sind. Warte erstmal den scrub ab.
 

Heinrich

Active Member
Themenstarter #3
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.
 

Esjott

Kellerkind
#5
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..
 

Yamagi

Possessed With Psi Powers
Mitarbeiter
#6
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.
 

Heinrich

Active Member
Themenstarter #7
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.
 

Heinrich

Active Member
Themenstarter #8
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?
 

Heinrich

Active Member
Themenstarter #9
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...
 

mr44er

Well-Known Member
#10
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. ;)
 
Themenstarter #11
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...
 
Themenstarter #13
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..
 

mr44er

Well-Known Member
#14
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! ;)
 

Binfort

Well-Known Member
#16
Frage am Rande, redundant ist ein Pool bei mir mit ZMIRROR. Das hätte doch die Fehler wie oben nicht verhindert? Beim RAM Ausfall...
 
Themenstarter #17
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.
 

Kamikaze

Warrior of Sunlight
Mitarbeiter
#18
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.
 
Themenstarter #19
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?
 

medV2

Well-Known Member
#21
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
 
Themenstarter #22
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?
 

mr44er

Well-Known Member
#24
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.