Zfs: Resilver-Neustart?

Ich hatte dies tatsächlich einmal auf Vanilla Linux Mdraid. Grundsätzlich versucht der Linux-Kernel, den Sektor zu lesen, und die Festplatte schlägt fehl, da der Sektor aus irgendeinem Grund beschädigt / unlesbar geworden ist. Dies wiederum führte dazu, dass die Raid-Synchronisierung fehlschlug.

Es gibt einen gefährlichen "Fix". Um eine Neuzuweisung des defekten HDD-Sektors zu erzwingen, können Sie beispielsweise hdparm --write-sector . ausführen. Beachten Sie, dass dies wirklich sehr gefährlich ist, da es einen ganzen HDD-Sektor effektiv auf Null setzt und ich nicht wirklich weiß, wie ZFS mit der Situation umgehen wird. Ihr Pool ist bereits beeinträchtigt, was die Situation möglicherweise verschlimmert, z. B. sind Daten in diesen Sektoren möglicherweise nicht mehr redundant (Sie haben mehrere Lesefehler im gesamten raidz2-2).

Ich habe gesehen, dass auf einem anderen Speicherserver mit WD-Festplatten etwas Ähnliches passiert ist, eine Art "WD-Bombe", wenn ich darf. Ich würde in Erwägung ziehen, sie so schnell wie möglich gegen etwas anderes auszutauschen.

Ich bin mir nicht sicher, wie sich ZFS bei unlesbaren Sektoren verhalten soll, da Linux den Sektor niemals selbst neu zuordnen wird, so dass dies möglicherweise einen Pool zerstören könnte, wenn sich unlesbare Sektoren ansammeln. Im Wesentlichen ist dies eine Form der stillen Datenbeschädigung, vor der wir nicht geschützt sind und die eine regelmäßige aktive Überwachung des Poolzustands durch den Systemadministrator erfordert. Vielleicht kann @behlendorf dazu Stellung nehmen.

Bearbeiten: Oder könnte dies ein Fehler sein, dass ZFS unter Linux nicht versucht, die Daten des defekten Sektors von einem anderen Gerät abzurufen, falls die primäre Methode fehlschlägt, oder könnte die Redundanz hier bereits erschöpft sein?

Eine schnelle Möglichkeit, dies auf einem einzelnen Gerät zu überprüfen, besteht natürlich darin, badblocks -s -c256 /dev/device auszuführen (dies ist schreibgeschützt, damit es sicher sein sollte, überprüfen Sie die Manpage für Optionen)

Vielen Dank für Ihre Antwort. Ich mache mir eigentlich keine Sorgen um die einzelnen Festplattenfehler, ich sehe das hier ziemlich viel und es ist eines der Dinge, vor denen die Redundanz in "RAID" Sie bewahren soll. Ich habe definitiv gesehen, wie sich ZFS von diesen anderen Zeiten erholt hat - es wurde entwickelt, um die fehlenden Informationen von den anderen Festplatten zu ergänzen und die Informationen wieder auf die fehlerhafte Festplatte zu schreiben. Ich denke, es schreibt die Daten in genau denselben Sektor zurück und verlässt sich darauf, dass die Festplatte einen toten Sektor neu zuordnet, anstatt die Daten in einen anderen Sektor zu schreiben und seine eigenen Blockzeiger zu aktualisieren.

Das Problem ist, dass Resilver neu gestartet wird, wenn auf dieser bestimmten Festplatte ein Fehler auftritt.

Zu Ihrer Information, seit dem ersten Posten hatte ich weitere 5 Fehler auf sdbc , jeder korrelierte mit einem Resilver-Neustart, wobei alle Neustarts mit den sdbc Fehlern korrelierten, und weitere 9 Fehler auf anderen Festplatten, die haben keine auffälligen Probleme verursacht:

2012-07-19-15:42:47     1.28T scanned out of 29.9T at 403M/s, 20h40m to go
2012-07-19-15:43:17     47.4M scanned out of 29.9T at 2.37M/s, (scan is slow, no estimated time)

2012-07-19-15:57:19     150G scanned out of 29.9T at 178M/s, 48h37m to go
2012-07-19-15:57:49     47.7M scanned out of 29.9T at 2.27M/s, (scan is slow, no estimated time)

2012-07-19-17:01:56     1.47T scanned out of 29.9T at 399M/s, 20h42m to go
2012-07-19-17:02:26     11.0M scanned out of 29.9T at 5.49M/s, (scan is slow, no estimated time)

2012-07-19-18:00:02     854G scanned out of 29.9T at 253M/s, 33h24m to go
2012-07-19-18:00:32     11.3M scanned out of 29.9T at 5.64M/s, (scan is slow, no estimated time)

2012-07-19-18:19:04     416G scanned out of 29.9T at 383M/s, 22h25m to go
2012-07-19-18:19:34     26.5M scanned out of 29.9T at 2.21M/s, (scan is slow, no estimated time)

Jul 19 15:42:50 b5 kernel: [87839.654210] end_request: critical target error, dev sdbc, sector 89985170
Jul 19 15:57:21 b5 kernel: [88709.279875] end_request: critical target error, dev sdbc, sector 1242265885
Jul 19 16:55:10 b5 kernel: [92172.837473] end_request: critical target error, dev sdbr, sector 92411471
Jul 19 16:55:23 b5 kernel: [92185.968422] end_request: critical target error, dev sdbr, sector 92616591
Jul 19 17:02:06 b5 kernel: [92588.136047] end_request: critical target error, dev sdbe, sector 103705189
Jul 19 17:02:17 b5 kernel: [92599.486257] end_request: critical target error, dev sdbc, sector 103884710
Jul 19 17:21:29 b5 kernel: [93749.776540] end_request: critical target error, dev sdbr, sector 1249209968
Jul 19 17:26:01 b5 kernel: [94021.482272] end_request: critical target error, dev sdaz, sector 1255414684
Jul 19 17:26:16 b5 kernel: [94035.966784] end_request: critical target error, dev sdbe, sector 1255592141
Jul 19 17:27:39 b5 kernel: [94118.680380] end_request: critical target error, dev sdbh, sector 1257310971
Jul 19 17:28:40 b5 kernel: [94179.921022] end_request: critical target error, dev sdbe, sector 1258878328
Jul 19 18:00:23 b5 kernel: [96080.118181] end_request: critical target error, dev sdbc, sector 1306147533
Jul 19 18:19:15 b5 kernel: [97210.681538] end_request: critical target error, dev sdbc, sector 31382981
Jul 19 18:25:51 b5 kernel: [97606.085044] end_request: critical target error, dev sdaz, sector 1230811160

Erstens hoffe ich, dass Sie Backups haben.

Beachten Sie, dass dies wirklich sehr gefährlich ist, da es einen ganzen HDD-Sektor effektiv auf Null setzt und ich nicht wirklich weiß, wie ZFS mit der Situation umgehen wird.

ZFS geht problemlos mit dem zerstörten Sektor um, vorausgesetzt, es ist Redundanz auf anderen Festplatten verfügbar.

Ihr Pool ist bereits beeinträchtigt, was die Situation möglicherweise verschlimmert, z. B. sind Daten in diesen Sektoren möglicherweise nicht mehr redundant (Sie haben mehrere Lesefehler im gesamten raidz2-2).

Das macht mir auch Sorgen. So viele Fehler im selben vdev und bereits 2 Festplatten außer Betrieb. Sicher eine gefährliche Situation. Es ist auch interessant zu sehen, dass nur die WD-Festplatten solche Fehler aufweisen, _und_ auch so viele Fehler im Scrub haben. Zur späteren Bezugnahme sollte man daher möglichst nicht alle gleichartigen Platten in einem redundanten vdev unterbringen, sondern sie verteilen.

Im Wesentlichen ist dies eine Form der stillen Datenbeschädigung, vor der wir nicht geschützt sind und die eine regelmäßige aktive Überwachung des Poolzustands durch den Systemadministrator erfordert.

ZFS wurde entwickelt, um Ihre Daten _spezifisch_ vor solchen Fehlern zu schützen. Es ist nicht "still", seit ZFS es meldet, oder? Linux mdraid und normale Hardware-Raid-Lösungen _sind_ jedoch von stiller Korruption betroffen.

Bearbeiten: Oder könnte dies ein Fehler sein, dass ZFS unter Linux nicht versucht, die Daten des defekten Sektors von einem anderen Gerät abzurufen, falls die primäre Methode fehlschlägt, oder könnte die Redundanz hier bereits erschöpft sein?

Kein Fehler, ZFS funktioniert einwandfrei. Könnte sein, dass die Redundanz bereits verloren ist.

Ich habe definitiv gesehen, wie sich ZFS von diesen anderen Zeiten erholt hat - es wurde entwickelt, um die fehlenden Informationen von den anderen Festplatten zu ergänzen und die Informationen wieder auf die fehlerhafte Festplatte zu schreiben. Ich denke, es schreibt die Daten in genau denselben Sektor zurück und verlässt sich darauf, dass die Festplatte einen toten Sektor neu zuordnet, anstatt die Daten in einen anderen Sektor zu schreiben und seine eigenen Blockzeiger zu aktualisieren.

Das ist richtig. Siehe raidz-spezifische Implementierungsdetails hier: http://src.illumos.org/source/xref/illumos-gate/usr/src/uts/common/fs/zfs/vdev_raidz.c - Zeile 2109. IIRC, dies ist die nur case-copy-on-write wird nicht verwendet.

Nun zu dem, was passiert ... höchstwahrscheinlich wird der Resilver neu gestartet, weil ZFS Fehler von sdbc erhält. Wenn Sie Glück haben, entsprechen die Lese-/Prüfsummenfehler auf anderen Festplatten nicht diesen Sektoren auf sdbc und die Redundanz ist intakt. Wenn Sie Backups haben, entfernen Sie sdbc vollständig und Sie _sollten_ sehen, wie resilver mit Paritätsdaten fertig wird. Oder stoppen Sie ZFS und führen Sie einen badblocks -sv Lauf auf sdbc aus, _und_ die Sektoren, die es als fehlerhaft gemeldet hat, mit hdparm oder dd (DANGEROUS) neu zu.

Dies funktioniert natürlich nur, wenn die Paritätsdaten der von Ihnen zerstörten Sektoren intakt sind - daher die Backups. Aber es ist besser, die gesamte Festplatte zu zerreißen, da der größte Teil von sdbc noch lesbar ist, würde ich vermuten.

Ich mache mir eigentlich keine Sorgen um die einzelnen Festplattenfehler, ich sehe das hier ziemlich viel und es ist eines der Dinge, vor denen die Redundanz in "RAID" Sie bewahren soll.
[…]
Das Problem ist, dass Resilver neu gestartet wird, wenn auf dieser bestimmten Festplatte ein Fehler auftritt.

Tbh, ich wäre sehr besorgt über all diese Lesefehler. Auch wenn ZFS in der Lage sein sollte, deinen Speck die meiste Zeit zu retten, ist das nur spektakulär flockige, Müll-Hardware direkt von WD :-/

Zumindest verlangsamen solche Fehler die Resilver und die Poolleistung. Im schlimmsten Fall führen sie zu einem vollständigen Poolverlust, wenn sie sich nur so überlappen. Der Mittelweg scheint Probleme wie diese zu sein, die Sie hier haben – dies sollte jedoch immer noch behebbar sein.

Meine 2 Cent: Werfen Sie diese WDs so schnell wie möglich so weit wie möglich. Es macht keinen Sinn, fehlerhafte Hardware zu verwenden...

Oh ja, diese WDs werden so schnell wie möglich ersetzt! Aber zuerst habe ich ein operatives Interesse daran, wie gut das mit flockiger Hardware und allem geht. Beachten Sie, dass es sich um raid-z2 handelt und nur eine Platte tatsächlich vollständig verschwunden ist, sodass noch eine Paritätsplatte übrig ist. Wenn zwei oder mehr Festplatten mit Fehlern auf demselben ZFS-Block vorhanden sind, sind natürlich Daten verloren. Aber auch in diesem Fall sollte es nur dann eine verlorene Datei bedeuten, wenn sie sich auf einem Datenblock befindet, der dann am Ende mit zpool status -v gemeldet werden sollte. Ich denke, wenn ich Pech habe und einen Teil des Blockzeigerbaums verliere, könnte ich viel mehr als eine einzelne Datei verlieren.

Statistisch gesehen... wurden seit dem Start von Resilver bisher insgesamt 169 Sektorfehler gemeldet, also 84,5 kB Daten. Der Pool enthält fast 25 TB an genutzten Daten, also unter der Annahme, dass sie gleichmäßig auf die 3 vdevs verteilt sind, sind es 8,3 TB auf dem fehlerhaften vdev, und verteilt auf die 10 verbleibenden Festplatten (+ 1 tot) sind das etwa 830 GB pro Festplatte. Grob gesagt bedeuten 84,5 kB von 830 GB, dass es eine ziemlich gute Chance gibt, dass die Fehler _nicht_ im selben ZFS-Block sind. Das hoffe ich zumindest!

...wenn das Resilver tatsächlich voranschreitet und nicht einfach immer wieder über denselben Boden geht.

Danke für den Vorschlag von badblocks , das kann tatsächlich funktionieren, wenn die Festplattenfehler behoben werden können, bevor der Resilver sie sieht. An dieser Stelle würde ich lieber sehen, ob das Resilver voranschreitet.

Danke schön!

Nur zur Klarstellung: Als ich sagte: "Ich mache mir keine Sorgen über die einzelnen Festplattenfehler", hätte ich mit "in Bezug auf das unmittelbare Problem" fortfahren sollen. Offensichtlich ist eine Festplatte mit einer hohen Fehlerrate etwas, worüber man sich Sorgen machen muss, und noch mehr ein Haufen Festplatten! Im Moment frage ich mich jedoch angesichts der Fehler im Spiel, ob das Resilver tatsächlich Fortschritte macht oder nicht.

Mir ist auch aufgefallen, dass Sie dort 512 Byte (EADS) und 4k Byte (EARX) Sektorplatten gemischt haben. Dies könnte Sektorüberschreibungsoperationen erschweren, da ein fehlerhafter interner 4k-Sektor 8 emulierte Sektoren unlesbar machen könnte. Wird der Pool mit der Option ashift=12 erstellt?

Hmm, bisher geben nur die EADS-Platten Lesefehler aus? Interessant auch, vielleicht hilft das bessere ECC bei "Advanced Format"-Disketten...

Es ist ashift=9 . Ich habe einige erste Tests durchgeführt und für meinen Datensatz gab es nur einen geringfügigen Geschwindigkeitsverlust und einen erheblichen Platzvorteil gegenüber ashift=12 .

Ich hatte den ECC auf den 4k-Festplatten vorher nicht wirklich in Betracht gezogen, aber ja, das würde Sinn machen.

Die andere Sache an der EADS ist, dass sie TLER / SCTERC (auf 7s eingestellt) haben, ebenso wie die Hitachis, während dies bei EARX und Seagates nicht der Fall ist. Es ist also wahrscheinlicher, dass sie fehlerhafte Sektoren melden, anstatt wirklich, wirklich, sehr hart (minutenlang) zu versuchen, die Daten zurückzubekommen. Aber die EADS sind auch die ältesten Festplatten in der Box, was möglicherweise mit den dort angezeigten Fehlern zu tun hat.

Danke für die ausführlichen Informationen Jungs. Ich habe nicht untersucht, warum der Resilver immer wieder neu gestartet wird, aber wenn ich eine etwas fundierte Vermutung wagen würde, würde es daran liegen, dass der vdev verschwindet/wieder auftaucht. Der mpt2sas-Treiber der unteren Ebene versucht möglicherweise verschiedene Wiederherstellungstechniken, um Zugriff auf den Sektor zu erhalten. Diese könnten das Zurücksetzen des Geräts oder des Kanals beinhalten, wodurch der Stack auf zfs zurückgesickert wäre.

Aber wie gesagt, das ist nur eine Vermutung. Trotzdem sollten wir den Fehler offen lassen, damit wir genau feststellen können, was ihn verursacht und was wir dagegen tun können.

TLDR; Nachdem die Festplatten in ein anderes Chassis verschoben wurden, läuft der Resilver gut (7 Stunden, 10 TB und Zählen) ohne Festplattenfehler.

Mein unmittelbares Problem ist also gelöst und danke an die, die geantwortet haben!

Es ist immer noch von Interesse, warum Fehler von sdbc und nur sdbc , dass der Resilver neu gestartet wurde. Ich glaube nicht, dass der vdev selbst verschwand - die Fehlermeldungen (gemäß dem ersten Beitrag in dieser Ausgabe) waren für mehrere Festplatten gleich, aber nur sdbc und immer sdbc den Resilver-Neustart verursachen. Vielleicht hat es etwas damit zu tun, dass es die Quellfestplatte in einem zpool replace ? Vielleicht kombiniert mit der Tatsache, dass gleichzeitig ein weiteres zpool replace im selben vdev lief, aber in diesem Fall war die "Quell"-Festplatte tatsächlich ganz verschwunden (tote Festplatte). Da sich mein Pool nun selbst verhält, kann ich das Problem nicht mehr reproduzieren, aber das Ziel des Gerätemanagers "dm-flakey" könnte nützlich sein, wenn jemand inspiriert wird, dieses Problem zu beheben.

Für Interessierte...

Ich habe das Resilvering schließlich aufgegeben, da es wirklich nicht ankommt, und beschloss, eine Disk-to-Disk-Kopie der Problemdiskette sdbc auf ein anderes unbenutztes Laufwerk zu erstellen:

dd if=/dev/sdbc of=/dev/${new} bs=64k conv=noerror

Dies war eine Variation des badblocks Vorschlags: Die Theorie bestand darin, eine Kopie von so vielen Daten wie möglich auf eine Festplatte zu laden, die nicht ständig fehlerhaft war, und dann die Neusilberung mit der "guten" Festplatte neu zu starten anstelle der Problemdiskette. Es würde immer noch Lücken in den Daten geben, wo die ursprüngliche Festplatte flockig war, aber dann könnte der Resilver diese Daten mithilfe der Parität wiederherstellen, und hoffentlich würde der Resilver ohne Festplattenfehler tatsächlich abgeschlossen werden.

Zu meiner großen Überraschung wurde dd 8,5 Stunden später ohne einen einzigen Festplattenfehler abgeschlossen. Hä?!?!

Der Unterschied bestand darin, dass beim Resilvering die 33 Festplatten im Pool alle gleichzeitig getroffen wurden, im Gegensatz zu dd , die von einer einzelnen Festplatte gelesen und dann auf eine separate Festplatte geschrieben wurden, dh starker Verkehr auf dem SAS Bus vs keine Konkurrenz.

Das eigentliche physische Layout ist eine SuperMicro 847E26-R1400LPB Headbox mit einem LSI SAS 9211-8i HBA, die mit einem anderen identischen SuperMicro verbunden ist, der als einfaches JBOD verdrahtet und dann mit einem Norco RPC-4224 JBOD verkettet ist. Alle fehlerhaften Festplatten, dh die WD EADS, befanden sich im Norco, zusammen mit einer Reihe anderer Festplatten, die keine Fehler aufwiesen.

Auf eine Ahnung hin habe ich alle Festplatten in dem Pool, den ich zu resilverieren versuchte, aus dem Norco und in das 2. Supermicro verschoben.

Es ist jetzt 7 Stunden lang mit 10 TB fertig, und kein einziger Festplattenfehler von einer der Festplatten. Nur noch 20 TB.

Aug! Plötzlich sehe ich diesen Norco nicht mehr freundlich an. Hmmm, ich frage mich, wenn ich einen Mixer hätte, der groß genug wäre, "wird er mixen"?

Lange Rede, kurzer Sinn: Verwenden Sie Nearline-SAS-Festplatten anstelle von SATA mit SAS-Expandern.

Längere Version: Ihr SuperMicro 847E26-R1400LPB hat eine SAS2 Backplane+2 Expander, richtig? Ich spiele mit denen in meinem aktuellen Job und genau dem gleichen HBA ... gute Hardware. Wie ist das zweite Chassis mit den 6 iPASS-Anschlüssen von Norco verkabelt?

Berichten zufolge sind SAS-Expander + SATA-Festplatten ein mögliches Rezept für eine Katastrophe, insbesondere bei mittlerer bis hoher Last. Selbst mit der neuesten HBA+Expander-Firmware besteht die Möglichkeit von Reset-Stürmen (oder anderen seltsamen Fehlerzuständen), die die Festplatten einer ganzen Backplane entweder kurzzeitig oder bis zum Aus- und Wiedereinschalten zerstören, je nachdem, wie stark eine sich schlecht benehmende SATA-Festplatte das SAS-Subsystem zum Absturz bringt . Hattest du das Systemlayout im 1. Post beschrieben... :-)

Höchstwahrscheinlich ist das Problem nicht Ihr Norco-Chassis, die "Backplanes" darin sind einfache Passthrough-Geräte ... nichts Besonderes daran. Möglicherweise haben Sie gerade die Fehlerdomäne verschoben, damit der/die HBA/Expander besser mit flockigen SATA-Festplatten umgehen können.

Beachten Sie, dass das direkte Anschließen von SATA-Festplatten an SAS-HBAs problemlos funktionieren sollte. Wenn Sie SAS-Expander (und das SATA-Tunneling-Protokoll) zu der Mischung hinzufügen, treten seltsame Fehler bei fehlerhaften SATA-Festplatten auf. SATA wurde einfach nicht mit Blick auf eine Switching-Fabric entwickelt, und es sieht so aus, als ob Firmwares immer noch nicht robust genug sind, um bei Auftreten von Fehlern mit Command Tunneling zuverlässig umzugehen.

Schade, dass Nearline-SAS-Festplatten so viel teurer sind als SATA-Festplatten. Man kann hoffen, dass die Preise früher als später sinken...

Norco ist mit einem Chenbro CK23601 verbunden. Das kann ich bei Bedarf auf jeden Fall mischen! Es verwendet den gleichen LSI SAS2X36-Expander wie das Supermicro SC847E26-RJBOD1. Ich bin daran interessiert, die Hardware-Seite der Dinge weiter zu diskutieren, vielleicht diesen Teil in zfs-discuss für ein breiteres Publikum zu verschieben?

Bei der unmittelbaren Ausgabe, 27 Stunden in und 21 TB von 30 TB abgeschlossen. 2 Festplattenfehler gemeldet, beide auf EADS-Festplatten, die beide nicht zu einem Resilver-Neustart führen:

Jul 21 04:17:54 b5 kernel: [39085.454182] mpt2sas0: log_info(0x31080000): originator(PL), code(0x08), sub_code(0x0000)
Jul 21 04:17:54 b5 kernel: [39085.454209] mpt2sas0: log_info(0x31080000): originator(PL), code(0x08), sub_code(0x0000)
Jul 21 04:17:54 b5 kernel: [39085.454232] mpt2sas0: log_info(0x31080000): originator(PL), code(0x08), sub_code(0x0000)
Jul 21 04:17:54 b5 kernel: [39085.454255] mpt2sas0: log_info(0x31080000): originator(PL), code(0x08), sub_code(0x0000)
Jul 21 04:17:54 b5 kernel: [39085.454278] mpt2sas0: log_info(0x31080000): originator(PL), code(0x08), sub_code(0x0000)
Jul 21 04:17:54 b5 kernel: [39085.454318] sd 0:0:36:0: [sdaj] Unhandled sense code
Jul 21 04:17:54 b5 kernel: [39085.454343] sd 0:0:36:0: [sdaj]  Result: hostbyte=invalid driverbyte=DRIVER_SENSE
Jul 21 04:17:54 b5 kernel: [39085.454400] sd 0:0:36:0: [sdaj]  Sense Key : Medium Error [current] 
Jul 21 04:17:54 b5 kernel: [39085.454461] Info fld=0x41d9e878
Jul 21 04:17:54 b5 kernel: [39085.454497] sd 0:0:36:0: [sdaj]  Add. Sense: Unrecovered read error
Jul 21 04:17:54 b5 kernel: [39085.454549] sd 0:0:36:0: [sdaj] CDB: Read(10): 28 00 41 d9 e7 92 00 00 e7 00
Jul 21 04:17:54 b5 kernel: [39085.454628] end_request: critical target error, dev sdaj, sector 1104799634
Jul 21 04:17:54 b5 kernel: [39085.454681] ZFS: zio error=121 type=1 offset=563655681024 size=118272 flags=20668 delay=7010

Jul 21 08:06:20 b5 kernel: [52770.786179] mpt2sas0: log_info(0x31080000): originator(PL), code(0x08), sub_code(0x0000)
Jul 21 08:06:20 b5 kernel: [52770.786234] mpt2sas0: log_info(0x31080000): originator(PL), code(0x08), sub_code(0x0000)
Jul 21 08:06:20 b5 kernel: [52770.786285] mpt2sas0: log_info(0x31080000): originator(PL), code(0x08), sub_code(0x0000)
Jul 21 08:06:20 b5 kernel: [52770.786362] mpt2sas0: log_info(0x31080000): originator(PL), code(0x08), sub_code(0x0000)
Jul 21 08:06:20 b5 kernel: [52770.786481] sd 0:0:32:0: [sdaf] Unhandled sense code
Jul 21 08:06:20 b5 kernel: [52770.786530] sd 0:0:32:0: [sdaf]  Result: hostbyte=invalid driverbyte=DRIVER_SENSE
Jul 21 08:06:20 b5 kernel: [52770.786611] sd 0:0:32:0: [sdaf]  Sense Key : Medium Error [current] 
Jul 21 08:06:20 b5 kernel: [52770.786669] Info fld=0x58678f34
Jul 21 08:06:20 b5 kernel: [52770.786705] sd 0:0:32:0: [sdaf]  Add. Sense: Unrecovered read error
Jul 21 08:06:20 b5 kernel: [52770.786757] sd 0:0:32:0: [sdaf] CDB: Read(10): 28 00 58 67 8f 33 00 00 02 00
Jul 21 08:06:20 b5 kernel: [52770.786836] end_request: critical target error, dev sdaf, sector 1483181875
Jul 21 08:06:20 b5 kernel: [52770.786888] ZFS: zio error=121 type=1 offset=757387388416 size=1024 flags=20668 delay=7010

Ich denke, das bedeutet, dass ich nur Glück hatte, dass die Problemfestplatte keinen Fehler erlitten hat und einen Resilver-Neustart verursacht hat. Daumen drücken für die nächsten 7 Stunden!

Aktueller Poolstatus:

  pool: pool2
 state: DEGRADED
status: One or more devices is currently being resilvered.  The pool will
    continue to function, possibly in a degraded state.
action: Wait for the resilver to complete.
 scan: resilver in progress since Fri Jul 20 06:01:47 2012
    21.3T scanned out of 29.9T at 369M/s, 6h43m to go
    1.38T resilvered, 71.49% done
config:

    NAME                                        STATE     READ WRITE CKSUM
    pool2                                  DEGRADED     0     0     0
      raidz2-0                                  ONLINE       0     0     0
        sdbi  Hitachi_HDS5C30_ML0220F30E2DMD    ONLINE       0     0     0
        sdbg  Hitachi_HDS5C30_ML0221F30B7ZND    ONLINE       0     0     0
        sdac  Hitachi_HDS7230_MN1240F33XBYYD    ONLINE       0     0     0
        sdad  Hitachi_HDS7230_MN1240FA03E4HD    ONLINE       0     0     0
        sdab  Hitachi_HDS7230_MN1240FA0HUZAD    ONLINE       0     0     0
        sdaa  Hitachi_HDS7230_MN1240FA0JXU2D    ONLINE       0     0     0
        sdba  Hitachi_HDS7230_MN1240FA0K07YD    ONLINE       0     0     0
        sdbp  Hitachi_HDS7230_MN1240FA0KP7YD    ONLINE       0     0     0
        sdah  Hitachi_HDS7230_MN1240FA0LA36D    ONLINE       0     0     0
        sdae  Hitachi_HDS7230_MN1240FA0LMP9D    ONLINE       0     0     0
        sdz   Hitachi_HDS7230_MN1270FA0SV8ED    ONLINE       0     0     0
      raidz2-1                                  ONLINE       0     0     0
        sdl   ST2000DL003-9VT_5YD1V6ZL          ONLINE       0     0     0
        sday  ST2000DL003-9VT_5YD1W04H          ONLINE       0     0     0
        sdn   ST2000DL003-9VT_5YD1XEDS          ONLINE       0     0     0
        sdi   ST2000DL003-9VT_5YD1XF0K          ONLINE       0     0     0
        sdbb  ST2000DL003-9VT_5YD1XQ15          ONLINE       0     0     0
        sdo   ST2000DL003-9VT_5YD1Z9BZ          ONLINE       0     0     0
        sdbe  WDC_WD20EARX-00_WD-WMAZA5589913   ONLINE       0     0  860K  (resilvering)
        sdbd  ST2000DL003-9VT_5YD563JW          ONLINE       0     0     0
        sds   ST2000DL003-9VT_5YD56MEZ          ONLINE       0     0     0
        sdy   ST2000DL003-9VT_5YD5FWQ6          ONLINE       0     0     0
        sdbq  WDC_WD20EARX-00_WD-WMAZA5567696   ONLINE       0     0     0
      raidz2-2                             DEGRADED     0     0     0
        sdaj  WDC_WD20EADS-00_WD-WCAVY1129416   ONLINE       7     0     0  (resilvering)
        sdaf  WDC_WD20EADS-00_WD-WCAVY1162803   ONLINE       3     0     0  (resilvering)
              replacing-2                       ONLINE       0     0     0
          sdak  WDC_WD20EADS-00_WD-WCAVY1184604 ONLINE       0     0     0  (resilvering)
          sdbh  WDC_WD20EARX-00_WD-WMAZA5603921 ONLINE       0     0     0  (resilvering)
        sdag  WDC_WD20EADS-00_WD-WCAVY1188798   ONLINE       0     0     0
              replacing-4                       DEGRADED     0     0     0
                17433600781902467301            UNAVAIL      0     0     0  was /dev/mapper/WDC_WD20EADS-00_WD-WCAVY1188828
          sdaz  Hitachi_HDS7230_MN1240FA0LHJLD  ONLINE       0     0     0  (resilvering)
        sdai  WDC_WD20EADS-00_WD-WCAVY1188933   ONLINE       0     0     0
        sdbr  WDC_WD20EADS-00_WD-WCAVY7404957   ONLINE       0     0     0
        sdbf  WDC_WD20EARX-00_WD-WCAZA9871198   ONLINE       0     0     0
        sdbo  WDC_WD20EARX-00_WD-WMAZA5346235   ONLINE       0     0     0
        sdbn  WDC_WD20EARX-00_WD-WMAZA5534735   ONLINE       0     0     0
        sdbj  WDC_WD20EARX-00_WD-WMAZA5561260   ONLINE       0     0     0

errors: No known data errors

Beachten Sie, dass mit dem Wechsel zum Supermicro-Gehäuse die sdbc Festplatte, die zuvor die Neustarts auslöste, jetzt sdak (was die Vorteile der Verwendung der Festplatten-IDs für den Pool anstelle des kurzlebigen /dev . demonstriert /sd*).

Zu Ihrer Information, das Resilvering wurde mit mehreren weiteren Festplattenfehlern abgeschlossen, aber keine auf sdak und keine weiteren Neustarts.

Ich bestätige dies nur als mehr als nur einen einmaligen Freak: Ich sehe dieses Problem "Resilver startet bei Fehler von der Ersatzfestplatte neu" bei verschiedenen Festplatten.

Wieder einmal ersetzte ich eine fehlerhafte Festplatte mit zpool replace ${pool} ${guid} ${new_device} (wobei ${guid} die GUID der jetzt nicht zugänglichen ausgefallenen Festplatte war). Das Resilver wurde ursprünglich vor einigen Tagen gestartet, aber zpool status zeigt mir jetzt, dass es erst vor einer Stunde neu gestartet wurde:

scan: resilver in progress since Mon Aug 13 22:54:11 2012

...die genau mit dem Zeitstempel eines Festplattenfehlers auf der neuen Ersatzfestplatte übereinstimmt:

Aug 13 22:54:04 b5 kernel: [715848.288843] sd 0:0:62:0: [sdbh] Unhandled sense code
Aug 13 22:54:04 b5 kernel: [715848.288873] sd 0:0:62:0: [sdbh]  Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Aug 13 22:54:04 b5 kernel: [715848.288922] sd 0:0:62:0: [sdbh]  Sense Key : Medium Error [current] 
Aug 13 22:54:04 b5 kernel: [715848.288962] Info fld=0x5f7eb4a9
Aug 13 22:54:04 b5 kernel: [715848.288993] sd 0:0:62:0: [sdbh]  Add. Sense: Unrecovered read error
Aug 13 22:54:04 b5 kernel: [715848.289036] sd 0:0:62:0: [sdbh] CDB: Read(10): 28 00 5f 7e b4 a9 00 00 c8 00
Aug 13 22:54:04 b5 kernel: [715848.289099] end_request: critical target error, dev sdbh, sector 1602139305
Aug 13 22:54:04 b5 kernel: [715848.289137] ZFS: zio error=121 type=1 offset=818293592576 size=102400 flags=20640 delay=6900

Der relevante Abschnitt des zpool status :

                   replacing-0                      DEGRADED     0     0     0
                     Hitachi_HDS7230_MN1270FA11PATD FAULTED     66 1.36K     0  too many errors
              sdbh   Hitachi_HDS7230_MN1270FA0SNEDD ONLINE       1     1     0  (resilvering)

Zu Ihrer Information: "Resilver startet bei Fehler von der Ersatzfestplatte neu" tritt auch auf, wenn die Originalfestplatte noch vorhanden ist (zuvor hatte ich es nur gesehen, wenn die Originalfestplatte fehlerhaft war).

@chrisrd 65947351e71bec2ec5673bf0c3ad02f2c2b96b6c könnte dies behoben haben.

Ja, das scheint das Problem zu lösen. Ich habe keinen Testfall zu bestätigen, aber ich würde sagen, das Ticket kann geschlossen werden.

Für alle, die die obige Saga verfolgen, wurden meine Probleme mit mehreren defekten EADS-Festplatten am Ende auf eine einzige zwielichtige EADS zurückgeführt. Es würde "etwas" tun und andere EADS-Festplatten würden Fehler erfahren. Sobald diese eine Platte ersetzt wurde (während eines Programms zum Austauschen aller EADS-Platten), waren alle Probleme verschwunden. Stelle dir das vor. Ich schätze, die EADS-Festplatten sind in Bezug auf ihre Busspezifikationen marginal oder so, vielleicht nur in Verbindung mit den SATA-über-SAS-Expandern usw. Seitdem wurden die ersetzten EADS-Festplatten (abzüglich der zwielichtigen) in Testpools verwendet und wir haben es nicht getan ähnliche Probleme auch während längerer Stresstests usw.

Ich hasse es wirklich, alte Tickets zu stoßen, aber ich bin mir nicht sicher, was ich tun soll.

Ich habe genau das gleiche Problem mit 0.6.5-304_gf74b821

Ich hatte ein Problem, bei dem immer noch ein fehlerhaftes Laufwerk in der Maschine vorhanden war und der Pool aufgrund möglicherweise dieses Problems wiederholt zu einem Neustart der Resilvering-Funktion führte. Ich hatte meinen Resilver-Neustart ungefähr 5 Mal, bevor ich dies endlich fand, das fehlerhafte Gerät offline geschaltet und aus dem Gehäuse entfernt.

Mein Setup ist ein Supermicro-Gehäuse mit SATA-Festplatten hinter SAS HBA/Expandern.
`

Hey,
Ich hasse es auch zu stoßen..

0.6.5.6-1~trusty auf 3.19.0-58-generic #64~14.04.1-Ubuntu
In meinem Fall 4 TB SAS NL in Supermicro Expansion.. :(

Einige E/A-Fehler im Protokoll..

[646135.203418] mpt2sas0: log_info(0x31120303): originator(PL), code(0x12), sub_code(0x0303)
[646135.203504] sd 1:0:26:0: [sdaa] FAILED Result: hostbyte=DID_SOFT_ERROR 
driverbyte=DRIVER_OK
[646135.203508] sd 1:0:26:0: [sdaa] CDB:
[646135.203509] Write(16): 8a 00 00 00 00 01 9f 82 e9 ff 00 00 00 18 00 00
[646135.203520] blk_update_request: I/O error, dev sdaa, sector 6971124223

`
root@fshh7 :~# zpool-Status
Becken: fshh7
Zustand: DEGRADED
Status: Ein oder mehrere Geräte werden gerade neu versilbert. Der Pool wird
weiterhin funktionieren, möglicherweise in einem verschlechterten Zustand.
Aktion: Warten Sie, bis der Resilver abgeschlossen ist.
Scan: resilver in Arbeit seit So 19. Juni 22:54:38 2016
14.1T gescannt von 99.2T bei 408M/s, 60h43m bis zum Ziel
314G resilvered, 14,17% fertig
Konfiguration:

    NAME                          STATE     READ WRITE CKSUM
    fshh7                         DEGRADED     0     0     0
      raidz2-0                    ONLINE       0     0     0
        sdau                      ONLINE       0     0     0
        sdav                      ONLINE       0     0     0
        sdaw                      ONLINE       0     0     0
        sday                      ONLINE       0     0     0
        sdax                      ONLINE       0     0     0
        sdaz                      ONLINE       0     0     0
        sdba                      ONLINE       0     0     0
        sdbb                      ONLINE       0     0     0
        sdbc                      ONLINE       0     0     0
        sdbd                      ONLINE       0     0     0
        sdbe                      ONLINE       0     0     0
        sdbf                      ONLINE       0     0     0
        sdbg                      ONLINE       0     0     0
        sdbh                      ONLINE       0     0     0
        sdbi                      ONLINE       0     0     0
        sdbj                      ONLINE       0     0     0
        sdbk                      ONLINE       0     0     0
        sdbl                      ONLINE       0     0     0
        sdbm                      ONLINE       0     0     0
        sdbn                      ONLINE       0     0     0
        sdbo                      ONLINE       0     0     0
        sdbp                      ONLINE       0     0     0
      raidz2-2                    DEGRADED     0     0     0
        sdb                       ONLINE       0     0     0
        sdc                       ONLINE       0     0     0
        sdd                       ONLINE       0     0     0
        sde                       ONLINE       0     0     0
        sdf                       ONLINE       0     0     0
        sdg                       ONLINE       0     0     0
        sdh                       ONLINE       0     0     0
        sdi                       ONLINE       0     0     0
        sdj                       ONLINE       0     0     0
        sdk                       ONLINE       0     0     0
        sdl                       ONLINE       0     0     0
        sdm                       ONLINE       0     0     0
        sdn                       ONLINE       0     0     0
        sdo                       ONLINE       0     0     0
        sdp                       ONLINE       0     0     0
        sdq                       ONLINE       0     0     0
        sdr                       ONLINE       0     0     0
        sds                       ONLINE       0     0     0
        sdt                       ONLINE       0     0     0
        sdu                       ONLINE       0     0     0
        sdv                       ONLINE       0     0     0
        sdw                       ONLINE       0     0     0
        sdx                       ONLINE       0     0     0
        sdy                       ONLINE       0     0     0
        sdz                       ONLINE       0     0     0
        replacing-25              DEGRADED     0     0     0
          6262255769558981431     FAULTED      0     0     0  was /dev/sdaa1
          scsi-35000c50083acd193  ONLINE       0     0     0  (resilvering)
        sdab                      ONLINE       0     0     0
        sdac                      ONLINE       0     0     0
        sdad                      ONLINE       0     0     0
        sdae                      ONLINE       0     0     0
        sdaf                      ONLINE       0     0     0
        sdag                      ONLINE       0     0     0
        sdah                      ONLINE       0     0     0
        sdai                      ONLINE       0     0     0
        sdaj                      ONLINE       0     0     0
        sdak                      ONLINE       0     0     0
        sdal                      ONLINE       0     0     0
        sdam                      ONLINE       0     0     0
        sdan                      ONLINE       0     0     0
        sdao                      ONLINE       0     0     0
        sdap                      ONLINE       0     0     0
        sdaq                      ONLINE       0     0     0
        sdar                      ONLINE       0     0     0
        sdas                      ONLINE       0     0     0
        sdat                      ONLINE       0     0     0
    logs
      mirror-1                    ONLINE       0     0     0
        sdbq1                     ONLINE       0     0     0
        sdbr1                     ONLINE       0     0     0
    cache
      sdbq2                       ONLINE       0     0     0
      sdbr2                       ONLINE       0     0     0

`

Es ist wahrscheinlich ein Fehler darin zu finden, aber als Abschwächung für einen von Ihnen haben Sie TLER auf den fehlerhaften Laufwerken konfiguriert? (zB smartctl -l scterc,RNUM,WNUM [Laufwerk] - RNUM/WNUM sind Zehntelsekunden für einen Lese-/Schreibversuch vor dem Aufgeben, während 0 im Allgemeinen dazu führt, dass es nicht aufgibt ... was, wenn es auch dauert lang, kann sein, wenn die verschiedenen anderen Teile der Kette beschließen, sie gewaltsam zurückzusetzen)

Ich würde vorschlagen, es zu versuchen, wenn Sie können, denn vorausgesetzt, die Implementierung ist nicht fehlerhaft, reagieren die meisten Teile von E/A-Stacks besser auf Laufwerke, die nach X Sekunden geantwortet haben, dass ein Fehler aufgetreten ist, als auf Laufwerke, die nicht mehr reagieren, bis Sie das zurücksetzen Gerät.

Hey, thx für die Antwort.

Ich kann es testen. Welche Werte für scterc würden Sie empfehlen?
Ich werde sie so schnell wie möglich einstellen und sehen, ob der Umbau endlich durchkommt.

Dankeschön!

Tobias, ich leide momentan auch unter diesem Problem.

Ich habe mit den Typen im IRC gesprochen und mir wurden Werte von 70,70 zum Ausprobieren gegeben (smartctl -l scterc,70,70)

Zu diesem Zeitpunkt befinde ich mich bei meinem 5.

Dankeschön.
Also setze ich 80,80 und gebe Feedback. Vielleicht können Sie mindestens eine Nachsilverierung überspringen.
60 Stunden zu gehen.. in meinem Fall..
Daumen drücken..

Okay. Wieder neu gestartet. :(
Nächster Versuch 150,150

Das Ändern der Werte in andere Zahlen sollte leider keinen Einfluss darauf haben, ob es hilft oder nicht.

Also @rincebrain würdest du trotzdem den Wert 0 vorschlagen?

Dankeschön.

Nein, ich behaupte immer noch, dass es eine gute Idee ist, es in einem RAID-Array auf Werte ungleich Null einzustellen, aber wenn ein Satz von Werten ungleich Null dieses Problem nicht umging, wird ein anderer Satz wahrscheinlich auch nicht funktionieren.

Zurücksetzen für mich, die Einstellung auf allen Festplatten hatte keine Wirkung.

Könnte das neue Laufwerk entfernen und so viele Daten wie möglich kopieren, bevor es zu einem katastrophalen Ausfall kommt, und einfach neu aufbauen.

Originaler Problemmelder hier...

Wenn Ihr Pool raid-z2 ist (zB @tobias-k), würde ich vorschlagen, das fehlerhafte Laufwerk aus dem Pool zu entfernen, um zu verhindern, dass Fehler erzeugt werden, die dazu führen, dass der Resilver neu gestartet wird. Sie haben immer noch ein verbleibendes Paritätslaufwerk, sodass Ihre Daten weiterhin sicher sind und Sie so schnell wie möglich auf die 2 x Parität zurückkehren können.

Wenn Sie ein fehlerhaftes Laufwerk auf raid-z1 haben, können Sie entweder das fehlerhafte Laufwerk entfernen, um den Resilver so schnell wie möglich abzuschließen (Ihre Daten sind noch alle da, aber Sie können einige Blöcke verlieren, wenn ein anderes Laufwerk während des Resilvern Probleme hat) , oder, wenn Sie ein anderes Ersatzlaufwerk haben (dh zusätzlich zu dem, auf das Sie versuchen zu resilverieren), verfahren Sie wie in meinem "TLDR" -Beitrag oben und stoppen Sie das Resilvering (zB exportieren Sie den Pool), dann "dd " das fehlerhafte Laufwerk auf das zweite Ersatzlaufwerk (machen Sie sich keine Sorgen um gelegentliche Fehler), entfernen Sie das fehlerhafte Laufwerk, bringen Sie dann den Pool mit dem neuen kopierten Laufwerk wieder hoch und lassen Sie den Resilver abschließen. Dieser zweite Ansatz ist etwas sicherer, als das fehlerhafte Laufwerk einfach zu entfernen, denn wenn ein anderes Laufwerk während der anschließenden Resilver Probleme hat, wird es hoffentlich durch das neue kopierte Laufwerk abgedeckt - vorausgesetzt, das neue Problem liegt auf anderen Blöcken als das ursprüngliche fehlerhafte Laufwerk Probleme.

Alte Festplatte entfernt. Resilver abgeschlossen, die offline geschaltete Festplatte NICHT entfernt (immer noch dort hängen geblieben) Neustarts verursachen immer noch einen Neustart von Resilver, obwohl sie abgeschlossen sind - entfernen Sie die offline geschaltete Festplatte nie.

Ich habe keine Datenfehler mehr (ich hatte das letzte Mal 5 Dateien, die jetzt als Null angezeigt werden).

Ich werde nur das Verschieben von Daten aus dem Array abschließen und es wegblasen.

@raxxy Können Sie bitte klarstellen, was Sie mit "alte Festplatte entfernt" und dann "hatte die offline geschaltete Festplatte NICHT entfernt" meinen? Wenn Sie meinen, dass sich die alte fehlerhafte Festplatte noch im Computer befindet und ein Neustart dazu führt, dass ein anderer Resilver erneut gestartet wird, was passiert, wenn Sie den Resilver beenden und die fehlerhafte Festplatte aus dem Computer entfernen und neu starten?

Ich glaube, er meint, dass es behauptet, resilvering/scrubbing zu sein, aber das Gerät ist immer noch mit REPLACING {offline disk, new disk} gekennzeichnet und startet bei jedem Neustart einen Resilver.

Rincebrain hat recht, tut mir leid, dass ich es eilig hatte, zur Arbeit zu gehen, klar sollte ich öfter Korrektur lesen.. ;)

Tote Festplatte + neue Ersatzfestplatte -> IO-Fehler lösen Resilver-Neustartschleife aus
Tote Festplatte physisch entfernt + neue Ersatzfestplatte rein -> Resilver wird abgeschlossen, entfernt aber nie die Festplatte, die es ersetzt hat (sitzt dort 'UNAVAIL' oder wenn ich neu starte, hat es eine lange numerische Zeichenfolge

Jedes Ereignis im ZFS-Pool (Export/Import, Neustart) führt dazu, dass der Resilver neu gestartet und wahrscheinlich abgeschlossen wird, aber niemals die Festplatte entfernt (Dies ist der 30 zurück, um zu sehen, ob es das Problem beheben würde - Festplatte wieder entfernt, damit ich die Daten schneller verschieben kann.)

@raxxy OK, ich weiß nicht, was da los ist. Enthält Ihr "zpool events -v poolname" etwas Interessantes in Bezug auf die Scrubs? Wenn Sie damit zufrieden sind, Ihr eigenes ZoL zu kompilieren, können Sie versuchen, diesen Patch hinzuzufügen, der ein wenig mehr "Zpool-Ereignisse"-Informationen zum Scrub-Abschluss bietet: chrisrd/ zfs@92da32e

Es lohnt sich auch, den Pool ohne /etc/zfs/zpool.cache aufzurufen. Etwas wie: den Pool exportieren, /etc/zfs/zpool.cache entfernen und erneut importieren (oder neu starten und importieren).

Commit d14fa5dba1ad0e68e803435ac48ec1ea78121699, das mit dem Master zusammengeführt wurde, hat dies möglicherweise behoben. Hat jemand mit dieser Änderung getestet?

Nicht behoben, immer noch Neustarts mit Laufwerken mit Suchfehlern.

Dateiname: /lib/modules/4.4.0-36-generic/kernel/zfs/zfs/zfs.ko
Version: 0.6.5.6-0ubuntu10
Lizenz: CDDL
Autor: OpenZFS unter Linux
Beschreibung: ZFS
srcversion: BAF128A524F0974CFA37071
hängt davon ab: spl,znvpair,zunicode,zcommon,zavl
vermagic: 4.4.0-36-generisches SMP mod_unload modversions

[Fr 2. September 11:31:28 2016] blk_update_request: Kritischer mittlerer Fehler, dev sdz, Sektor 4106662640
[Fr 2. September 11:31:33 2016] sd 2:0:20:0: device_block, handle(0x001e)
[Fr 2. September 11:31:33 2016] mpt2sas_cm2: log_info(0x31110610): Absender(PL), Code(0x11), sub_code(0x0610)
[Fr 2. September 11:31:33 2016] mpt2sas_cm2: log_info(0x31110610): Absender(PL), Code(0x11), sub_code(0x0610)
[Fr 2. September 11:31:33 2016] sd 2:0:20:0: device_unblock und Einstellung auf running, handle(0x001e)
[Fr 2. Sep. 11:31:34 2016] sd 2:0:20:0: [sdz] tag#1 CDB: Lesen(16) 88 00 00 00 00 00 f4 c6 b3 70 00 00 00 20 00 00
[Fr 2. September 11:31:34 2016] mpt2sas_cm2: sas_address(0x5003048000d25b63), phy(35)
[Fr 2. Sep. 11:31:34 2016] mpt2sas_cm2: Enclosure_logical_id(0x5003048000d25b7f),slot(23)
[Fr 2. September 11:31:34 2016] mpt2sas_cm2: handle(0x001e), ioc_status(success)(0x0000), smid(162)
[Fr 2. September 11:31:34 2016] mpt2sas_cm2: request_len(16384), underflow(16384), resid(16384)
[Fr 2. September 11:31:34 2016] mpt2sas_cm2: tag(65535), transfer_count(0), sc->result(0x00000000)
[Fr 2. September 11:31:34 2016] mpt2sas_cm2: scsi_status(check condition)(0x02), scsi_state(autosense valid )(0x01)
bla bla bla

@thisisnotmyrealname Das ist nicht überraschend, keine der 0.6.5.X-Versionen hat den Commit, dass @behlendorf oben erwähnt Ihr Problem beheben könnte.

Sie müssen entweder von git master bauen oder einfach diesen bestimmten Commit auf 0.6.5.X anwenden und erstellen und sehen, ob das Problem für Sie weiterhin besteht.

Entschuldigung für den vorherigen Bericht. Scheint, dass Ubuntu das ZFS-Kernel-Modul auf mich geschmuggelt hat.

Dateiname: /lib/modules/4.4.0-36-generic/extra/zfs/zfs.ko
Version: 0.6.5-437_gd02ca37
Lizenz: CDDL
Autor: OpenZFS unter Linux
Beschreibung: ZFS
srcversion: E4190FDAA7A1780753688F9
hängt davon ab: spl,znvpair,zunicode,zcommon,zavl
vermagic: 4.4.0-36-generisches SMP mod_unload modversions

Ich habe das neueste Git mit dem verglichen, was ich kompiliert habe, und nur Änderungen an der zfs-Testsuite gesehen.

Status: Ein oder mehrere Geräte werden gerade neu versilbert. Der Pool wird
weiterhin funktionieren, möglicherweise in einem verschlechterten Zustand.
Aktion: Warten Sie, bis der Resilver abgeschlossen ist.
Scan: resilver in Arbeit seit Fr 09.09.2016 01:15:26 2016
39,2 G gescannt von 84,6 T mit 5,45 M/s (Scan ist langsam, keine geschätzte Zeit)
1,52G resilvered, 0,05% fertig

Ich habe vor 7 Tagen ein Resilver gestartet und es wird seitdem neu gestartet. Gibt es noch andere nützliche/hilfreiche Informationen, die ich zur Verfügung stellen kann?

Kann bestätigen, dass ein Problem mit Resilver-Neustarts immer wieder aufgetreten ist, das beim Wechsel zu zfs-daily ppa vom Donnerstag verschwunden ist. Mein Pool ist wieder ganz.

Es könnte etwas mit #5970 zu tun haben.

Ich glaube, ich bin auf das gleiche Problem gestoßen, bin mir aber nicht ganz sicher..

Ich habe einen raidz2-Pool, den ich mit falsch ausgerichteten Partitionen eingerichtet habe. Ich wollte dies beheben, also habe ich versucht, Laufwerke nacheinander offline zu schalten, die Partitionstabelle zu löschen und sie dann zu ersetzen, aber stattdessen das volle Laufwerk zu verwenden. Nach dem Austauschen der Laufwerke scheint der Status für den Resilver-Prozess jedoch neu zu starten und wird nie fortgesetzt. Als Beispiel hat mir der zpool-Status Folgendes gegeben:

action: Wait for the resilver to complete.
  scan: resilver in progress since Thu Jan 11 18:19:54 2018
        252M scanned out of 6.99T at 12.6M/s, 161h24m to go
        42.3M resilvered, 0.00% done

Und ein paar Sekunden später bekam ich:

action: Wait for the resilver to complete.
  scan: resilver in progress since Thu Jan 11 18:20:15 2018
        227M scanned out of 6.99T at 13.4M/s, 152h27m to go
        37.6M resilvered, 0.00% done

Ich war mir nicht sicher, was zu tun war und bemerkte, dass es immer zu laufen schien, wenn es einen bestimmten Punkt erreichte, und startete den Server neu, woraufhin der Resilver anfing, sich zu entwickeln und den Knackpunkt überstanden. Dies ist auf beiden Laufwerken passiert, die ich in meinem Pool neu partitioniert habe. Anbei die Protokolle des Versuchs für das zweite Laufwerk zpool_replace.log.redacted.gz (ebenfalls eingefügt unter https://paste.fedoraproject.org/paste/HbUQxhWB6L7j59FNLCFzHA ). Ich habe nach der ersten Fahrt (die erfolgreich war) einen Scrub durchgeführt, bevor ich zur zweiten Fahrt übergegangen bin.

Der einzige Hinweis, den ich gefunden habe, war dies in den Journalprotokollen zum Zeitpunkt eines Resilver-Neustarts:

Jan 11 18:18:54 ZFSHOST zed[8820]: eid=488 class=config_sync pool_guid=0x89A3B4EB7BFA7DBF
Jan 11 18:18:55 ZFSHOST zed[9045]: eid=489 class=config_sync pool_guid=0x89A3B4EB7BFA7DBF
Jan 11 18:18:55 ZFSHOST zed[9047]: eid=490 class=config_sync pool_guid=0x89A3B4EB7BFA7DBF
Jan 11 18:18:56 ZFSHOST zed[9270]: eid=491 class=config_sync pool_guid=0x89A3B4EB7BFA7DBF
Jan 11 18:18:56 ZFSHOST zed[9280]: eid=492 class=config_sync pool_guid=0x89A3B4EB7BFA7DBF
Jan 11 18:18:56 ZFSHOST kernel: Alternate GPT is invalid, using primary GPT.
Jan 11 18:18:56 ZFSHOST kernel:  sda:
Jan 11 18:18:56 ZFSHOST kernel:  sda: sda1 sda9
Jan 11 18:18:56 ZFSHOST zed[9382]: eid=493 class=vdev_attach pool_guid=0x89A3B4EB7BFA7DBF vdev_path=/dev/disk/by-id/ata-WDC_WD4000F9YZ-09N20L1_WD-WMC5D0D1T4V6-part1 vdev_state=ONLINE
Jan 11 18:18:57 ZFSHOST zed[9539]: eid=494 class=resilver_start pool_guid=0x89A3B4EB7BFA7DBF
Jan 11 18:18:57 ZFSHOST zed[9545]: eid=495 class=history_event pool_guid=0x89A3B4EB7BFA7DBF
Jan 11 18:19:01 ZFSHOST zed[11291]: eid=496 class=config_sync pool_guid=0x89A3B4EB7BFA7DBF
Jan 11 18:19:06 ZFSHOST zed[13682]: eid=497 class=history_event pool_guid=0x89A3B4EB7BFA7DBF
Jan 11 18:19:20 ZFSHOST zed[18764]: eid=498 class=config_sync pool_guid=0x89A3B4EB7BFA7DBF
Jan 11 18:19:20 ZFSHOST zed[18773]: eid=499 class=config_sync pool_guid=0x89A3B4EB7BFA7DBF
Jan 11 18:19:35 ZFSHOST zed[26064]: eid=500 class=config_sync pool_guid=0x89A3B4EB7BFA7DBF
Jan 11 18:19:35 ZFSHOST zed[26071]: eid=501 class=config_sync pool_guid=0x89A3B4EB7BFA7DBF
Jan 11 18:19:39 ZFSHOST zed[27625]: eid=502 class=history_event pool_guid=0x89A3B4EB7BFA7DBF
Jan 11 18:19:39 ZFSHOST zed[27627]: eid=503 class=resilver_start pool_guid=0x89A3B4EB7BFA7DBF
Jan 11 18:19:39 ZFSHOST zed[27637]: eid=504 class=history_event pool_guid=0x89A3B4EB7BFA7DBF
Jan 11 18:19:50 ZFSHOST zed[32020]: eid=505 class=config_sync pool_guid=0x89A3B4EB7BFA7DBF
Jan 11 18:19:50 ZFSHOST zed[32025]: eid=506 class=config_sync pool_guid=0x89A3B4EB7BFA7DBF
Jan 11 18:19:54 ZFSHOST zed[1317]: eid=507 class=history_event pool_guid=0x89A3B4EB7BFA7DBF
Jan 11 18:19:54 ZFSHOST zed[1323]: eid=508 class=resilver_start pool_guid=0x89A3B4EB7BFA7DBF
Jan 11 18:19:54 ZFSHOST zed[1327]: eid=509 class=history_event pool_guid=0x89A3B4EB7BFA7DBF

BEARBEITEN: Behoben, dass eine Protokollzeile abgeschnitten wurde

Wenn ich raten müsste, wird es durch die Tatsache verwirrt, dass Sie nicht gesagt haben, dass Sie das alte Gerät verprügeln und möglicherweise beim Versuch stecken bleiben, das "alte" Laufwerk neu zu benennen / zu importieren.

Ich bin mir einigermaßen sicher, was mit Ihnen passiert, ist, dass etwas eine Umbenennung des Laufwerks auslöst und, wenn das Laufwerk verschwindet und wieder auftaucht, dadurch ein Neustart des Resilver ausgelöst wird.

Ich bin mir weniger sicher, _was_ es auslöst, aber ich würde vermuten, dass es schließlich bemerkt, dass das "alte" Laufwerk von Teil 1 wieder auftaucht, wenn es umbenannt wird, versucht, es online zu stellen, und dabei das Resilver zerstört.

Ich würde zpool offline verwenden, um das "alte" Gerät explizit offline zu stellen, was es wahrscheinlich davon überzeugen sollte, dies nicht mehr zu versuchen. wenn nicht, stellen Sie sicher, dass autoreplace=off auf dem Pool sollte; Wenn das nicht der Fall ist, dann ist das ein weiterer Fehler, würde ich denken.

(Welche ZoL-Version, Distribution+Kernel-Version usw.?)

Ich habe einen Zpool offline gemäß dem Protokollverlauf durchgeführt, den ich angehängt habe. Außerdem ist Autoreplace deaktiviert:

# zpool get all | grep autoreplace
tank  autoreplace                    off                            default

Dies ist Version 0.7.5-1 auf Centos 7-Kernel 3.10.0-693.11.6.el7.x86_64.

Ich bin auf Version 0.7.3-1 und habe gestern das gleiche Problem nach einem "Zpool-Ersatz" festgestellt". Mir ist aufgefallen, dass die Resilvering wiederholt alle zehn Sekunden mit einer Tonne davon in der zfs-Historie neu gestartet wurde:

2018-02-04.00:58:42 [txg:7268183] scan setup func=2 mintxg=3 maxtxg=7264178
2018-02-04.00:59:08 [txg:7268189] scan aborted, restarting errors=0

Ich habe gesucht und folgendes Problem gefunden: 6613 . Es wurde erwähnt, dass es mit zed zusammenhängen könnte, also habe ich zfs-zed gestoppt und es wurde etwa eine Stunde später wieder versilbert. Ich könnte das Problem auf einer anderen Diskette reproduzieren, also könnte es sich tatsächlich um einen Fehler im Zusammenhang mit ZED handeln.

Ich verwende archzfs-git (wahrscheinlich eine sehr aktuelle Version) und hatte Probleme beim Ersetzen eines Laufwerks mit diesen Protokollen im Journal:

Mar 11 22:43:47 hubble zed[19428]: eid=9385 class=config_sync pool_guid=0x38BF9374E2B7FD2D
Mar 11 22:43:50 hubble zed[19788]: eid=9386 class=config_sync pool_guid=0x38BF9374E2B7FD2D
Mar 11 22:43:51 hubble zed[19867]: eid=9387 class=vdev.bad_ashift pool_guid=0x38BF9374E2B7FD2D vdev_path=/dev/disk/by-id/wwn-0x50014ee262071313-part3
Mar 11 22:43:51 hubble zed[19892]: eid=9388 class=vdev.bad_ashift pool_guid=0x38BF9374E2B7FD2D vdev_path=/dev/disk/by-id/wwn-0x50014ee20cb16a07-part3
Mar 11 22:43:52 hubble zed[19912]: eid=9389 class=history_event pool_guid=0x38BF9374E2B7FD2D
Mar 11 22:43:52 hubble zed[19916]: eid=9390 class=resilver_start pool_guid=0x38BF9374E2B7FD2D
Mar 11 22:43:52 hubble zed[19918]: eid=9391 class=history_event pool_guid=0x38BF9374E2B7FD2D
Mar 11 22:44:02 hubble zed[20670]: eid=9392 class=config_sync pool_guid=0x38BF9374E2B7FD2D
Mar 11 22:44:06 hubble zed[20941]: eid=9393 class=config_sync pool_guid=0x38BF9374E2B7FD2D
Mar 11 22:44:06 hubble zed[21032]: eid=9394 class=vdev.bad_ashift pool_guid=0x38BF9374E2B7FD2D vdev_path=/dev/disk/by-id/wwn-0x50014ee262071313-part3
Mar 11 22:44:06 hubble zed[21035]: eid=9395 class=vdev.bad_ashift pool_guid=0x38BF9374E2B7FD2D vdev_path=/dev/disk/by-id/wwn-0x50014ee20cb16a07-part3
Mar 11 22:44:07 hubble zed[21053]: eid=9396 class=history_event pool_guid=0x38BF9374E2B7FD2D
Mar 11 22:44:07 hubble zed[21057]: eid=9397 class=resilver_start pool_guid=0x38BF9374E2B7FD2D
Mar 11 22:44:07 hubble zed[21062]: eid=9398 class=history_event pool_guid=0x38BF9374E2B7FD2D
Mar 11 22:44:18 hubble zed[21754]: eid=9399 class=config_sync pool_guid=0x38BF9374E2B7FD2D
Mar 11 22:44:21 hubble zed[22114]: eid=9400 class=config_sync pool_guid=0x38BF9374E2B7FD2D
Mar 11 22:44:21 hubble zed[22190]: eid=9401 class=vdev.bad_ashift pool_guid=0x38BF9374E2B7FD2D vdev_path=/dev/disk/by-id/wwn-0x50014ee20cb16a07-part3
Mar 11 22:44:22 hubble zed[22201]: eid=9402 class=vdev.bad_ashift pool_guid=0x38BF9374E2B7FD2D vdev_path=/dev/disk/by-id/wwn-0x50014ee262071313-part3
Mar 11 22:44:22 hubble zed[22204]: eid=9403 class=history_event pool_guid=0x38BF9374E2B7FD2D
Mar 11 22:44:22 hubble zed[22208]: eid=9404 class=resilver_start pool_guid=0x38BF9374E2B7FD2D
Mar 11 22:44:22 hubble zed[22210]: eid=9405 class=history_event pool_guid=0x38BF9374E2B7FD2D
Mar 11 22:44:36 hubble zed[23236]: eid=9406 class=config_sync pool_guid=0x38BF9374E2B7FD2D
Mar 11 22:44:36 hubble zed[23309]: eid=9407 class=config_sync pool_guid=0x38BF9374E2B7FD2D
Mar 11 22:44:42 hubble zed[23562]: eid=9408 class=vdev.bad_ashift pool_guid=0x38BF9374E2B7FD2D vdev_path=/dev/disk/by-id/wwn-0x50014ee262071313-part3
Mar 11 22:44:42 hubble zed[23569]: eid=9409 class=vdev.bad_ashift pool_guid=0x38BF9374E2B7FD2D vdev_path=/dev/disk/by-id/wwn-0x50014ee20cb16a07-part3
Mar 11 22:44:43 hubble zed[23581]: eid=9410 class=history_event pool_guid=0x38BF9374E2B7FD2D
Mar 11 22:44:43 hubble zed[23584]: eid=9411 class=resilver_start pool_guid=0x38BF9374E2B7FD2D
Mar 11 22:44:43 hubble zed[23588]: eid=9412 class=history_event pool_guid=0x38BF9374E2B7FD2D

systemctl stop zfs-zed das Problem gelöst und das Resilvering wird normal fortgesetzt (hoffe ich).

@as-com Hat das Stoppen von zfs-zed das Problem gelöst? Ich habe das ohne Glück versucht, bin immer noch in der gleichen Resilver-Schleife stecken geblieben.

Was es jedoch für mich zu beheben schien, war, ein detach auf der problematischen Festplatte durchzuführen, es mit scrub -p fillzero /dev/sda (NICHT zfs' scrub ) auf Null zu setzen und dann erneut anzuhängen es. Ich habe noch keinen Fehler erhalten und das Resilver scheint etwa 30% schneller zu sein als zuvor.

Ich denke, was (zumindest in meinem Fall) passiert, ist, dass es eine Art I/O-Fehler gibt, von dem sich zfs während des Resilver, der den Neustart auslöst, nicht wiederherstellen kann, aber zwingt es zu einem sauberen Resilver (da ich vermute) es wird versuchen, faul zu sein und Schreibblöcke zu vermeiden, die bereits vorhanden sind) korrigiert es schließlich.

@4oo4 Ja, das Stoppen von Zed hat das Problem gelöst. Meine Hypothese ist, dass es eine Timing-Sache ist, bei der zed manchmal Konfigurationsmaterial von zfs anfordert, was dazu führt, dass der Resilver neu gestartet wird.

@as-com Zu früh gesprochen, es wurde wieder neu gestartet. Gestern Abend habe ich versucht, diesen Dienst zu deaktivieren, ließ ihn aber trotzdem neu starten.

Es geht jedoch noch schneller als zuvor (und bisher fehlerfrei), da ich es wieder gestoppt habe. Ihre Hypothese zu zfs-zed scheint richtig zu sein, eine saubere Festplatte zu haben scheint auch zu helfen.

Ich verwende die ZFS-Version 0.7.8.

Ich habe mein Problem mittlerweile mehrfach reproduziert (keine Fehler. nur ein ständiges Neustarten des Nachsilvering-Vorgangs) und ein Stoppen von Zed während des Nachsilverings hilft mir immer.

@StefanCohen Cool, also

@4oo4 Ja. Das ist was ich mache.

Das hat meinen Speck gerettet! Sieger war systemctl stop zfs-zed. Wenn dies gängige Praxis ist, sollten die Dokumente aktualisiert werden. Ich hatte alle möglichen Probleme mit dem Neustart von Resilver, da ich aufgrund häufiger intelligenter Fehler proaktiv ein Laufwerk austauschte und nicht herausfinden konnte, warum sie nicht fortfahren würden. Es gab keine Lese- oder Schreibfehler, daher war es sehr verwirrend, bis ich dies gelesen habe.

Dankeschön!!

Dieser Fehler ist seit 2012 offen, daher stimme ich zu, dass es schön wäre, wenn die Dokumente ihn erwähnen.

Ich bin gerade darauf gestoßen, als ich einige ältere Treiber durch neuere ersetzt habe. Danke, dass Sie dieses Problem geöffnet haben. Am Ende war es eine Kombination aus TLER und ZED, die es meinem Speicher ermöglichte, Fortschritte zu machen.

Ich bin gerade in den letzten Tagen auf einem Array darauf gestoßen. Zed töten und es noch einmal versuchen lassen.

Ich bin gerade auf ein ähnliches/das gleiche gestoßen? Ausgabe.

System:
ArchLinux
Linux t440s 4.20.0-arch1-1-ARCH #1 SMP PREEMPT Mo 24 Dec 03:00:40 UTC 2018 x86_64 GNU/Linux
zfs: 0.8.0-rc2_42_g06f3fc2a4
spl: 0.8.0-rc2_42_g06f3fc2a4

Dies ist nur ein sehr einfacher gespiegelter Pool von 2 über USB angeschlossenen Festplatten.
Der Resilvering-Prozess wird alle 20-40 Sekunden neu gestartet, wenn versucht wird, das fehlerhafte Laufwerk zu ersetzen.
Im Gegensatz zum ursprünglichen Issue-Posting sind KEINE Festplattenfehlermeldungen im Kernel-Log zu finden, wenn dmesg !
Das Ausführen eines Scrubs für den Pool führt zu einem vollständigen Scrub ohne Fehler:

  pool: mypassport
 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: scrub repaired 0B in 0 days 11:29:33 with 0 errors on Tue Jan  1 03:39:21 2019
config:

    NAME                                                   STATE     READ WRITE CKSUM
    mypassport                                             DEGRADED     0     0     0
      mirror-0                                             DEGRADED     0     0     0
        usb-WD_Elements_25A1_575835314433384C56485448-0:0  ONLINE       0     0     0
        /fakedrive.img                                     FAULTED      0     0     0  external device fault

errors: No known data errors

Das Deaktivieren von zfs-zed wie von anderen vorgeschlagen, hat nichts gebracht.

Interessant könnte sein, wie ich überhaupt in die Situation gekommen bin:

1. Erstellen Sie einen gespiegelten Pool
2. Nehmen Sie ein Laufwerk offline / lassen Sie es ausfallen
3. Schreiben Sie einige Daten in den Pool (in meinem Fall ein paar TB aus einem Backup)
4. Ersetzen Sie das fehlerhafte Laufwerk; resilvering funktioniert zu diesem Zeitpunkt einwandfrei (-f, da auf dem Ersatzlaufwerk bereits eine Partition vorhanden war)
5. Exportieren Sie den Pool manuell, während er noch resilvered ist
6. Neustart
7. Pool neu importieren -> Resilvering startet bei Null und bleibt in der "Resilvering Restart Loop" hängen

Wie ich das Problem schließlich auf meinem Computer gelöst habe:

1. Trennen Sie das Ersatzlaufwerk wieder aus dem Pool
2. Füllen Sie das gesamte Ersatzlaufwerk mit Nullen dd if=/dev/zero of=/dev/sdc bs=4096
3. Fügen Sie dem Ersatzlaufwerk eine gpt-Partitionstabelle und eine ext4-Partition hinzu (um die Notwendigkeit von -f zu erzwingen)
4. Stoppen Sie den zfs-zed-Dienst.
5. Verbinden Sie das Ersatzlaufwerk mit dem Pool. Lassen Sie es silbrig werden. Fertig

Ich bin mir nicht sicher, ob 4. und entweder 2. oder 3. wirklich notwendig sind. Möglicherweise muss der zfs-zed-Dienst nicht gestoppt werden. Möglicherweise würde nur das Nullen oder Erstellen einer anderen Partitionstabelle/fs auf der Festplatte ausreichen. Ich bin mir nicht sicher, ob die Option -f andere Codepfade auslöst!?

Meine Vermutung, was passiert ist: zfs versucht herauszufinden, wie viel bereits auf das neue Laufwerk resilvered wurde, scheitert jedoch mysteriöserweise am manuellen Export und Reimport beim ersten Resilvering-Versuch. Vielleicht auch mit USB zu tun?

Möglicherweise verwandt
https://forums.freebsd.org/threads/zfs-resilver-restarts.30892/

Vielleicht rechtfertigt dies ein separates Problem, da ich KEINE Laufwerksfehler hatte und schließlich mit der oben genannten Methode erfolgreich war? Eventuell beim Illumos Bugtracker? Es scheint definitiv ein Fehler in einer der Komponenten versteckt zu sein.

Dieses Problem hat meinen Speck gerettet.

Hängen tagelang in der Resilver-Schleife fest, mit ständiger Angst vor einem Ausfall der verbleibenden Platte im Spiegel-Vdev. Stopped zfs-zed, Festplatte in Minuten neu versilbert.

Für mich musste ich 2 Dinge tun - zfs-zed töten und auch zfs_scan_ignore_errors=1 , damit mein ziemlich durcheinander geratenes Array sich selbst resilver lässt.

Letztendlich sieht es so aus, als müsste ich alle verbleibenden Daten extrahieren und aus Backups neu erstellen.

Hallo zusammen, Originalplakat (von vor 7 Jahren!) hier...

Ich bin auf dieses "resilver ständig neu starten" gestoßen, nachdem ich ein Laufwerk ausgetauscht hatte, was natürlich einen Resilver auslöste.

Eines der Symptome waren diese Nachrichten, die alle 15 Sekunden oder so in mein zpool history -i gespuckt wurden:

2019-04-01.10:52:54 [txg:564945133] scan aborted, restarting errors=0
2019-04-01.10:52:54 [txg:564945133] starting deferred resilver errors=0
2019-04-01.10:52:54 [txg:564945133] scan setup func=2 mintxg=3 maxtxg=564899810

Dies ist mit 0.8.0 und OHNE die zfs-Funktion feature@resilver_defer aktiviert.

Sobald ich feature@resilver_defer aktiviert hatte, hörte der Neustart auf und der Resilver machte Fortschritte.

Für andere in dieser Situation scheinen die Optionen wie folgt zu sein:

1. (vorübergehend?) kehre zu 0.7.latest zurück und lass das Resilver ausklingen
2. nur feature@resilver_defer aktivieren:

zpool set feature@resilver_defer=enabled pool`

1. alle 0.8.0-Funktionen aktivieren:

zpool upgrade pool

WARNUNG Das Aktivieren von 0.8.0-Funktionen, einschließlich feature@resilver_defer , führt dazu, dass mit diesem Pool nicht auf 0.7.x zurückgesetzt werden kann.

(Dies ist eine völlig andere Ursache als das ursprüngliche Problem von vor 7 Jahren, aber die Symptome sind die gleichen und dieses Problem scheint der Ort zu sein, an den die Leute kommen, wenn sie auf dieses "Resilver ständig neu starten" treffen.)

Für alles, was es wert ist, bin ich heute auch gerade auf dieses Problem gestoßen, nachdem ich mit einem defekten Laufwerk auf 0.8.1 aktualisiert hatte, da das Resilver mit 0.7 sehr lange dauern würde, also wollte ich sequentielles Resilver. Das Stoppen von zed hat nicht funktioniert, aber das Upgrade des Pools und das Aktivieren von resilver_defer lösten das Problem.

Ich erlebe dies derzeit in einem Pool, der unter 0.8.2 ausgeführt wird, mit aktiviertem feature@resilver_defer (der Pool war auf 0.8.2 mit dieser Funktion aktiviert, als der Resilver gestartet wurde). Die Originaldiskette ist nicht mehr vorhanden, die Ersatzdiskette hat beim ersten Resilver-Lauf (den ich gelöscht habe) Fehler festgestellt und den zweiten Resilver-Lauf ohne Fehler beendet. Es ist derzeit im dritten Resilver.

  pool: tank
 state: DEGRADED
status: One or more devices is currently being resilvered.  The pool will
        continue to function, possibly in a degraded state.
action: Wait for the resilver to complete.
  scan: resilver in progress since Mon Jan 20 14:53:56 2020
        590G scanned at 497M/s, 229G issued at 193M/s, 14.4T total
        32.2G resilvered, 1.55% done, 0 days 21:27:01 to go
config:

        NAME                                            STATE     READ WRITE CKSUM
        tank                                            DEGRADED     0     0     0
          raidz2-0                                      DEGRADED     0     0     0
            ata-WDC_WD30EFRX-68AX9N0_WD-WCC1T1489518    ONLINE       0     0     0
            ata-WDC_WD30EFRX-68AX9N0_WD-WCC1T1489979    ONLINE       0     0     0
            ata-WDC_WD30EFRX-68EUZN0_WD-WCC4N7PV8232    ONLINE       0     0     0
            replacing-3                                 DEGRADED     0     0     0
              9593279170455378102                       UNAVAIL      0     0     0  was /dev/disk/by-id/ata-WDC_WD30EFRX-68AX9N0_WD-WCC1T1545830-part1
              ata-WDC_WD60EFAX-68SHWN0_WD-WX11D39929YU  ONLINE       0     0     0  (resilvering)
            ata-WDC_WD30EFRX-68AX9N0_WD-WCC1T1545960    ONLINE       0     0     0
            ata-WDC_WD30EFRX-68AX9N0_WD-WCC1T1550817    ONLINE       0     0     0
        logs    
          mirror-1                                      ONLINE       0     0     0
            wwn-0x55cd2e404b510699-part6                ONLINE       0     0     0
            wwn-0x55cd2e404b511223-part6                ONLINE       0     0     0



NAME  PROPERTY                       VALUE                          SOURCE
tank  size                           16.2T                          -
tank  capacity                       88%                            -
tank  altroot                        -                              default
tank  health                         DEGRADED                       -
tank  guid                           13759943618182453813           -
tank  version                        -                              default
tank  bootfs                         -                              default
tank  delegation                     on                             default
tank  autoreplace                    off                            default
tank  cachefile                      -                              default
tank  failmode                       wait                           default
tank  listsnapshots                  off                            default
tank  autoexpand                     off                            default
tank  dedupditto                     0                              default
tank  dedupratio                     1.00x                          -
tank  free                           1.83T                          -
tank  allocated                      14.4T                          -
tank  readonly                       off                            -
tank  ashift                         12                             local
tank  comment                        -                              default
tank  expandsize                     -                              -
tank  freeing                        0                              -
tank  fragmentation                  38%                            -
tank  leaked                         0                              -
tank  multihost                      off                            default
tank  checkpoint                     -                              -
tank  load_guid                      11289215483194079640           -
tank  autotrim                       off                            default
tank  feature<strong i="5">@async_destroy</strong>          enabled                        local
tank  feature<strong i="6">@empty_bpobj</strong>            active                         local
tank  feature<strong i="7">@lz4_compress</strong>           active                         local
tank  feature<strong i="8">@multi_vdev_crash_dump</strong>  enabled                        local
tank  feature<strong i="9">@spacemap_histogram</strong>     active                         local
tank  feature<strong i="10">@enabled_txg</strong>            active                         local
tank  feature<strong i="11">@hole_birth</strong>             active                         local
tank  feature<strong i="12">@extensible_dataset</strong>     active                         local
tank  feature<strong i="13">@embedded_data</strong>          active                         local
tank  feature<strong i="14">@bookmarks</strong>              enabled                        local
tank  feature<strong i="15">@filesystem_limits</strong>      enabled                        local
tank  feature<strong i="16">@large_blocks</strong>           active                         local
tank  feature<strong i="17">@large_dnode</strong>            enabled                        local
tank  feature<strong i="18">@sha512</strong>                 enabled                        local
tank  feature<strong i="19">@skein</strong>                  enabled                        local
tank  feature<strong i="20">@edonr</strong>                  enabled                        local
tank  feature<strong i="21">@userobj_accounting</strong>     active                         local
tank  feature<strong i="22">@encryption</strong>             enabled                        local
tank  feature<strong i="23">@project_quota</strong>          active                         local
tank  feature<strong i="24">@device_removal</strong>         enabled                        local
tank  feature<strong i="25">@obsolete_counts</strong>        enabled                        local
tank  feature<strong i="26">@zpool_checkpoint</strong>       enabled                        local
tank  feature<strong i="27">@spacemap_v2</strong>            active                         local
tank  feature<strong i="28">@allocation_classes</strong>     enabled                        local
tank  feature<strong i="29">@resilver_defer</strong>         enabled                        local
tank  feature<strong i="30">@bookmark_v2</strong>            enabled                        local

Das geht immer noch in 0.8.3

Schwimmbad: Fernseher
Zustand: DEGRADED
Status: Ein oder mehrere Geräte werden gerade neu versilbert. Der Pool wird
weiterhin funktionieren, möglicherweise in einem verschlechterten Zustand.
Aktion: Warten Sie, bis der Resilver abgeschlossen ist.
Scan: resilver in Arbeit seit Do 26 Mrz 15:16:14 2020
138G gescannt mit 17,3G/s, 52,7G ausgegeben mit 6,59G/s, 81,6T insgesamt
0B resilvered, 0.06% erledigt, 0 Tage 03:31:11 bis zum Ende
Konfiguration:

    NAME                        STATE     READ WRITE CKSUM
    tv                          DEGRADED     0     0     0
      raidz3-0                  DEGRADED     0     0     0
        wwn-0x5000cca261c9c282  ONLINE       0     0     0
        wwn-0x5000cca261c9bc3d  OFFLINE      0     0     0
        wwn-0x5000c500b2e78f6e  ONLINE       0     0     0
        wwn-0x5000cca261c9a642  ONLINE       0     0     0
        wwn-0x5000cca261c9079e  OFFLINE      0     0 74.0K
        wwn-0x5000c500b5b16651  ONLINE       0     0     0
        wwn-0x5000c500b2e71d11  ONLINE       0     0     0
        wwn-0x5000c500b5b15fdc  ONLINE       0     0     0
        wwn-0x5000c500b5b15d85  ONLINE       0     0     0
        wwn-0x5000c500b2e67d21  ONLINE       0     0     0
        wwn-0x5000c500b4e0ac49  ONLINE       0     0     0
        wwn-0x5000c500b5b05687  ONLINE       0     0     0
        wwn-0x5000cca261c9bdc0  ONLINE       0     0     0
        wwn-0x5000cca261c9ad25  ONLINE       0     0     0
        wwn-0x5000cca261c9ac0c  ONLINE       0     0     0
        wwn-0x5000cca261c8662b  ONLINE       0     0     0
    cache
      wwn-0x5002538500204a4f    ONLINE       0     0     0

Fehler: Keine bekannten Datenfehler

Ich habe die Festplatten offline geschaltet und ZED gestoppt, um zu sehen, ob das Resilver repariert, das anscheinend seit >15 Tagen ununterbrochen läuft.