vfs.zfs.recover="1" in loader.conf: entstehen dadurch Nachteile?

[pit234a]

Das es manchmal länger mit antworten dauern kann, weil Du halt anderweitig viel eingespannt bist?

Das macht natürlich dann am meisten Sinn, wenn man verlässliche Hardware hat

beides.
Neue HW ist geplant, aber bevor ich nicht mit meinen Arbeiten fertig bin, fange ich das nicht an.
Das Zeitfenster ist mir zu klein, nun HW zu bestellen, neu installieren und dann auch alles bis 16.05. abgeben, was ich erledigen muss.

Schon die letzten Antworten waren ja von mir erst nach längerer Zeit erfolgt.
Da hatte ich eben den ersten Teil "meiner Arbeiten" erledigt und mich weder um HW noch um Pool gekümmert.

Nun bleiben noch zwei Teile am PC zu tun.
Natürlich will ich gar nicht bis 16.05. warten, aber das ist eben die gesetzte Frist für den dritten Teil der Arbeit. Schaffe ich es vorher, mache ich auch vorher alles neu.

Alles neu mache ich natürlich erst mal auf dem vorhandenen PC, quasi als Spielwiese. Erst mal mit Rollback....
Das ist zumindest der Plan.
Aber eben jetzt noch nicht, wo ich doch alles gut benutzen kann und nur noch wenige Wochen bleiben.
Des ungeachtet frage ich mal in meinem Bekanntenkreis nach HW-Empfehlungen und obwohl das nicht direkt mit dem Thema zu tun hat, stelle ich diese Frage auch hier. Antworten können ja nicht schaden.

 

[turrican]

metoo
aber ich zaudere dennoch.

Deine Daten - deine Entscheidung, ich kann dir die nicht abnehmen;
Ich kanns Pferd zum Fluß führen - trinken muss es dann von selber
Deine Eingangsfrage war, ob durch das zfs.recover=1 Nachteile entstehen;
Die Frage beantworte ich mit: ja! last resort! Daten retten! Pool neu bauen!

Das ist vielleicht unvernünftig, aber weißt du, ich habe einen kräftigen Bauch und mich oft auf mein Bauchgefühl verlassen.

Vielleicht läuft der pool noch seine 2 Jahre - vielleicht auch nicht, wer weiß das schon.

Es wäre nicht so der große Aufwand, alles neu zu installieren und ich glaube, seit FreeBSD 9 oder 10 habe ich das gar nicht mehr gemacht, sondern immer nur per ZFS-send/receive mein System "gekloned". Da kann es vielleicht sogar angesagt sein, mal wieder neu zu beginnen.

Könnte es theoretisch demnächst mal passieren (bzw isses schon passiert), dass der offensichtlich problematische zfs Pool dann bei einem send/receive auch "defekte" Daten ans Ziel schickt?

Abschließend wenn ich das ganze nochmal betrachte - und dann noch die Foreneinträge über problematische Samsung SSDs:
Ist/sind ggf deine Samsung(s) aus dieser besagten Serie, und das Ursprungsproblem warum deine Maschine ab und an von selbst hart die Grätsche macht - oder hatte sie das schon vor dem Einbau von Samsung EVO und QVO?

 

[pit234a]

Ist/sind ggf deine Samsung(s) aus dieser besagten Serie, und das Ursprungsproblem warum deine Maschine ab und an von selbst hart die Grätsche macht - oder hatte sie das schon vor dem Einbau von Samsung EVO und QVO?

tatsächlich kam das Abstürzen erst mit den Samsungs vor, aber beileibe nicht sofort. Die Samsungs sind nun ca zwei Jahre drin und das Absturz-Erlebnis habe ich seit einigen Monaten und eben sehr sporadisch. Es ist insgesamt noch keine zehn Mal vorgekommen, aber trotzdem ärgerlich genug.

Alle SSDs wurden wohl zusammen gekauft und ersetzten zu klein und zu alt gewordene. Genau erinnere ich das nicht mehr. Gleichzeitig erhöhte ich die Redundanz meines Root-Pools von einem einfachen Spiegel zu einem dreier-Spiegel.
Die letzte, also die jüngste SSD, die ich zunächst nur als Ersatz herum liegen hatte, ist aus 09/2021. Die anderen aus 10 und 11 2020, wären dann also gerade so noch zu den guten zu zählen.

Als ich das Netzteil vor etlichen Wochen erneuerte, bekamen alle SSDs auch neue SATA-Kabel.
Alle Kabel sind also neu und weil ich nur solche Daten-Kabel verwende, die einen Rast-Mechanismus haben, schließe ich da einen Wackler aus. Man weiß natürlich nie...
Aber alle Pools verhalten sich nach wie vor sehr zuvorkommend und nur dieses eine, an sich unerklärliche Ereignis, hat mir einen Pool verunsichert.
Wir vermuten ja auch nur, dass das im Zusammenhang mit meinem bekannten HW-Defekt steht, weil das einfach die vernünftigste Annahme ist.

 

[Andy_m4]

Die anderen aus 10 und 11 2020, wären dann also gerade so noch zu den guten zu zählen.

Check doch einfach mal wie im Posting #46 beschrieben die Seriennummer. Dann musst Du nicht vermuten, sondern Du weißt.
Es ist immer so ein bisschen unbefriedigend, wenn nützliche Informationen geliefert aber dann vom Fragesteller aus irgendwelchen Gründen nicht verwertet werden.
Und komm mir nicht mit dem Zeitargument. Denn die Zeit Deine halbe Lebensgeschichte mit ins Posting zu packen hast Du ja offenbar auch. Aber nicht die 5 Minuten um mal auf die SSD zu gucken?

Wir vermuten ja auch nur, dass das im Zusammenhang mit meinem bekannten HW-Defekt steht, weil das einfach die vernünftigste Annahme ist.

Ja. Wir wissen es nicht. Und wenn man da mit entsprechend Aufwand nicht richtig in die Tiefe einsteigen will, bleibt nur sich ranzutasten. Und das beginnt halt damit alle bekannten Probleme erst mal zu beheben.
Und da Netzteil und Datenkabel schon getauscht worden sind, bleiben ja im Wesentlichen "nur" noch die Verdächtigen SSD und der Großraum Mainboard/RAM über. SSD könnte man noch aus der Liste der Verdächtigen streichen, wenn sie nicht eine bekanntermaßen problematische Seriennummer haben und den internen S.M.A.R.T. Extended-Test überstehen.
Den RAM durch ein extensives Memtest.
Etwas unglücklich ist natürlich, das der Fehler nur sehr sporadisch auftritt. Evtl. helfen da Stresstests den zu provozieren und somit das Problem weiter einzukreisen.

 

[pit234a]

Check doch einfach mal wie im Posting #46 beschrieben die Seriennummer. Dann musst Du nicht vermuten, sondern Du weißt.
Es ist immer so ein bisschen unbefriedigend, wenn nützliche Informationen geliefert aber dann vom Fragesteller aus irgendwelchen Gründen nicht verwertet werden.
Und komm mir nicht mit dem Zeitargument. Denn die Zeit Deine halbe Lebensgeschichte mit ins Posting zu packen hast Du ja offenbar auch. Aber nicht die 5 Minuten um mal auf die SSD zu gucken?


Ja. Wir wissen es nicht. Und wenn man da mit entsprechend Aufwand nicht richtig in die Tiefe einsteigen will, bleibt nur sich ranzutasten. Und das beginnt halt damit alle bekannten Probleme erst mal zu beheben.
Und da Netzteil und Datenkabel schon getauscht worden sind, bleiben ja im Wesentlichen "nur" noch die Verdächtigen SSD und der Großraum Mainboard/RAM über. SSD könnte man noch aus der Liste der Verdächtigen streichen, wenn sie nicht eine bekanntermaßen problematische Seriennummer haben und den internen S.M.A.R.T. Extended-Test überstehen.
Den RAM durch ein extensives Memtest.
Etwas unglücklich ist natürlich, das der Fehler nur sehr sporadisch auftritt. Evtl. helfen da Stresstests den zu provozieren und somit das Problem weiter einzukreisen.

die Aussage zu dem Baujahren der Platten bezieht sich natürlich auf die gegebene Information und das Auswerten der Seriennummer. Ansonsten wäre das doch wirklich nur geraten.
Weil ich es vielleicht aber falsch verstanden oder falsch gemacht habe, hier auch die Nummern:

S5SVNG0NA70050K
S5SVNF0NB22928Y
S5SVNG0NA69992M
S5SVNG0NA70056F
S5SVNG0N922408Y
S626NF0R900938R

Außer dem Netzteil- und Kabeltausch sowie natürlich Ab-Stecken und wieder An-Stecken von RAM und CPU sowie erneuern der Wärmeleitpaste etc sind ein Memtest und einige stress-ng Tests ergebnislos gelaufen. Schließlich hatte ich den Eindruck, dass die crashes erst mit gut gefülltem RAM erfolgen und suchte auch in der Richtung erfolglos. Es blieb nur ein Eindruck. Abschalten des Power-Schalters, An- und Abschalten des powerd (und powerdx), des Screensavers, des composite-Managers, der USV-Überwachung: Alles nichts.
Steckdosen und Kontakte zur und von der USV sind auch OK.
Weiß nicht, was ich vielleicht noch aus purer Verzweiflung alles probiert habe. Ahja: die diversen USB-Hubs hatte ich auch zwischendurch mal entfernt und verschiedene Einstellungen im BIOS versucht.
Die längste beobachtete Uptime war über definitiv über 60 Tage.
Weil ich das zunächst ja gar nicht wirklich wahrgenommen habe und mich nur wunderte, dass der PC bei der nächsten Benutzung neu gestartet war oder hing, weiß ich auch nicht genau, wie lange das Problem schon besteht.
Alle SSDs außer der letzten und neuesten, lieferten auch beim extended Selftest keinen Fehler. Den Test habe ich natürlich auch mehrfach laufen lassen.

Einige Zeilen in wenigen Minuten hier tippen ist ja kein Aufwand.
Gerne erzähle ich bei Bedarf auch noch mehr von meinem Leben.
Aber aufwändige Tests mit der Gefahr, ein gerade noch laufendes System erst recht unbrauchbar zu machen, will ich eben derzeit vermeiden.
Es ist ja nicht so, als ob ich den ganzen Tag vor dem PC hocke und arbeite. Eben darum will ich ihn einfach nur nutzen und schon die nun vermehrten Backups der Arbeitsdaten auf externe Medien braucht ja Zeit, während der ich dann vorsorglich nichts weiter mache und auch hier einige Zeilen tippen kann.

Neue HW wird kommen. Auch danach kann ich ja schon suchen, während die Backups mal laufen. Ich begnüge mich nicht mit einem einzigen.
Und ihr könnt mir glauben, dass es in meinem eigenen Interesse ist, schnell mit meinen Aufgaben fertig zu werden und dann auch hier weiter zu machen.

 

[turrican]

S5SVNG0NA70050K
S5SVNF0NB22928Y
S5SVNG0NA69992M
S5SVNG0NA70056F
S5SVNG0N922408Y
S626NF0R900938R

bis auf die letzte in der Liste sind alle vor DEC 2020 (N, 9/A/B == 2020, SEP/OCT/NOV), die letzte auf der Liste ist von SEP 2021;
wäre jetzt interessant, ob deine Maschine ohne diese nicht mehr abschmiert - aber genau da ist dein root-Pool drauf, vermute ich mal?

 

[pit234a]

wäre jetzt interessant, ob deine Maschine ohne diese nicht mehr abschmiert - aber genau da ist dein root-Pool drauf, vermute ich mal?

nein, das ist ein Datenpool auf den ich (auch) intern jede Nacht ein Backup laufen lasse. Es liegen aber auch andere Daten dort.

Das ist wirklich eine gute Idee, die mal abzuhängen und das könnte ich vielleicht auch recht schnell und einfach mal machen. Der PC steht unter meinem sehr schweren Schreibtisch und ist deshalb nicht so einfach sofort zugänglich.
Gerade läuft noch was im Hintergrund, aber in einigen Stunden gehe ich das wirklich mal an.

Nebenbei ist mir eben einer meiner Backup-Pools an einem USB-Anschluss dauernd abgeschmiert, an einem anderen prüfe ich ihn gerade problemlos. Auch das ist irgendwie nicht wirklich koscher. -> neue HW wird kommen!

Edit: detached ist sie schon mal

 

[Andy_m4]

nein, das ist ein Datenpool auf den ich (auch) intern jede Nacht ein Backup laufen lasse.

Wie machst Du eigentlich Dein Backup? Per zfs send oder kopierst Du mehr oder weniger die Dateien?

Nebenbei ist mir eben einer meiner Backup-Pools an einem USB-Anschluss dauernd abgeschmiert

Ist das der USB-Anschluss an dem Rechenr der auch Probleme macht?

neue HW wird kommen!

Zum Glück. So ist das ja kein Zustand :-)

 

[pit234a]

Wie machst Du eigentlich Dein Backup? Per zfs send oder kopierst Du mehr oder weniger die Dateien?

immer noch mit rsync, hauptsächlich zumindest.
Das hatte ich halt schon vor ZFS und deshalb an dem Konzept kaum was geändert.
Der Vorteil ist auch der, dass ich auf externe Medien in anderen Dateisystemen (etwa NTFS oder extfs) mit der gleichen Routine sichern und dann diese Daten auch in anderen Systemen benutzen kann. Das mache ich derzeit zusätzlich mehrmals am Tage.
Auf die internen Medien sichere ich ziemlich gnadenlos mein komplettes ~/., das heißt, ich mache zuvor einen aktuellen Snap davon, aus dem ich dann sichere.
Außerdem bilde ich in einem Verzeichnis, sagen wir mal Backup, die wichtigsten Verzeichnisse ab, in denen ich für gewöhnlich Daten speichere und synchronisiere auch dies jede Nacht zunächst intern und dann nach einem ssh-Server meines Providers (wir hatten das Thema hier behandelt) mittels rclone.

Zusätzlich habe ich zwei externe Platten mit ZFS und dahin hatte ich auf eine bisher unregelmäßig mit ZFS-Send und auf die andere mit rsync mal alle vier Wochen oder so zusätzlich ein Backup gefahren.
ZFS-Send mache ich nun nicht mehr, seit der Pool gepaniced hatte.

Ist das der USB-Anschluss an dem Rechenr der auch Probleme macht?

Das habe ich eben zum ersten Mal festgestellt.
Ich habe die USB-Ports auf HUBs verteilt und zusätzlich zwei direkt über Kabel verlängert. Bei längeren Backups will ich nicht über die HUBs gehen.
An einem dieser Kabel hatte ich nun Probleme, die ich bisher noch gar nicht bemerkt habe.
Ist natürlich markiert und wird nun entsprechend vorsichtig oder gar nicht eingesetzt.
Aber jedenfalls ein Grund mehr für neue HW.

 

[Andy_m4]

immer noch mit rsync, hauptsächlich zumindest.

Ok. Ist auch in Ordnung. Hintergrund meiner Frage war auch nur die Befürchtung, das man etwaig korrupte Teile des Pools damit mit kopiert. Aber auch so kann natürlich immer noch der Inhalt der Dateien beschädigt sein.
Evtl. macht es Sinn vor dem Hintergrund mal im Auge zu behalten, welche Dateien rsync da eigentlich kopiert (rsync hat ja die angenehme Eigenschaft nur die Dateien zu kopieren, die sich auch verändert haben).
Sind da Dateien bei, die man eigentlich nicht bearbeitet hat, könnte das ein Hinweis darauf sein, das die Datei beschädigt ist.

ZFS-Send mache ich nun nicht mehr, seit der Pool gepaniced hatte.

Ja. Vernünftig.

Bei längeren Backups will ich nicht über die HUBs gehen.

Ja. Auch sehr vernünftig. Ich hab bei diesen externen USB-Hubs auch nie ein wirklich gutes Gefühl. Ich hab glücklicherweise i.d.R. genügend USB-Anschlüsse, um nicht darauf angewiesen zu sein. :-)

An einem dieser Kabel hatte ich nun Probleme, die ich bisher noch gar nicht bemerkt habe.

Ja. Auch mit USB-Kabeln kann man mitunter viel "Spaß" haben.
Ich will ja nicht sagen, das früher alles besser war. Da gabs durchaus auch Probleme. Aber wenn da ein Kabel nicht ging, dann war es halt kaputt. Heute hast Du Phänomene wie: Ein und das selbe Kabel funktioniert zwischen den beiden Geräten, zwischen den anderen beiden Geräten aber nicht und solche Scherze.

 

[pit234a]

Evtl. macht es Sinn vor dem Hintergrund mal im Auge zu behalten, welche Dateien rsync da eigentlich kopiert (rsync hat ja die angenehme Eigenschaft nur die Dateien zu kopieren, die sich auch verändert haben).

auch deshalb liebe ich rsync, wenn das nun nicht übertrieben ist.
Weil das alles ja immer vollkommen gut funktionierte, hatte ich die Ausgabe nach /dev/null geschickt.
Auch wegen des Fehlers mit meiner HW habe ich das zurück gesetzt und mir fällt gar nichts auf, das nicht passen würde!

Aber, weil ein Teil meiner Aufgaben innerhalb einer Win10-VM erfolgen muss, habe ich nun auch diese in meinen Sicherungs-Ablauf hineingenommen und das sind echt große Dateien und somit verbringe ich gerade mehr Zeit im Wartemodus, als mit Arbeit.

Mehrere Backups zu haben, ist mir aber gerade wichtiger, denn je.

 

[Andy_m4]

habe ich nun auch diese in meinen Sicherungs-Ablauf hineingenommen und das sind echt große Dateien und somit verbringe ich gerade mehr Zeit im Wartemodus, als mit Arbeit.

Ja. rsync kann zwar auch nur Änderungen wegkopieren. Standardmäßig legt aber rsync während des kopierens ne neue Datei an. Und das kann dann ziemlich viel Zeit kosten. Mit dem Parameter --inplace kann man dieses Verhalten verhindern (siehe rsync Manpage). Sollte man aber mit Bedacht einsetzen, weil man sich damit auch leicht mal was kaputt machen kann.
Idealerweise sind die Dateien auf dem Backup-System versioniert.

Alternativ sichert man gar nicht das komplette Image, sondern nur die Nutzdateien. Images lassen sich in der Regel ja per Loopback- bzw. md-Device mounten. Mit Hilfe von NTFS-3G kriegt man da gut seine Dateien aus der Image-Datei rausgekratzt.

 

[mr44er]

Des ungeachtet frage ich mal in meinem Bekanntenkreis nach HW-Empfehlungen und obwohl das nicht direkt mit dem Thema zu tun hat, stelle ich diese Frage auch hier. Antworten können ja nicht schaden.

Für Intel kann ich nichts vorschlagen, da habe ich derzeit keine Ahnung.
Bei AMD wäre die Marschrichtung grob: X6xx Chipsatz, AM5 Sockel

Lesestoff zu den Chipsätzen und Boards:

AMD X670E, X670, B650E, B650 und A620 im Vergleich

Wer auf AMDs AM5-Plattform mit Ryzen 7000 umrüsten will, hat die Qual der Wahl zwischen fünf Mainboard-Chipsätzen. Doch welcher leistet was?

www.computerbase.de

Chipsatz-Vergleich: AMD X670E, X670, B650E und B650 Unterschiede (Update: A620)

Die Unterschiede der Chipsätze für Ryzen 7000/AM5 Systeme in der Übersicht. Vergleich von AMD X670E, X670, B650E, B650 und A620.

hardware-helden.de

https://www.only4gamers.de/x670-vs-b650-vs-x670e-und-b650e/

Board: Mit X670E hast du die besten Aufrüstchancen für später. Wenn der Preis zu happig ist, nach X670 schauen oder ggf. ob auch noch ne Nummer kleiner 'reicht' in Bezug auf Slots, PCI-E Version und Lanes. Meine Prios wären Asus>Gigabyte>MSI, aber auch da kann sich ein genauerer Blick lohnen: z.B. 50€ sparen, wenn man ein Board ohne WLAN bekommt, das man eh nicht nutzt.

CPU: https://geizhals.de/?cat=cpuamdam4&xf=820_AM5
Wie immer je mehr, desto gut. Im Endeffekt anhand der eigenen workload die Kernzahl wählen und die Kategorie Ryzen 5,7 oder 9. Lässt sich bei geizhals auch bequem anhand Preis pro core sortieren. Erinnerung: im idle geben die sich alle nix mehr bei der Stromrechnung, wohl aber unter Vollast. Der TDP-Wert gibt an, wieviel unter Vollast 'weggekühlt' werden muss. Eventuell von Bedeutung, wenn das Gehäuse winzig ist und zugebaut press im Schrank irgendwo steht.
Es gibt manche CPUs mit Grafikeinheit (das Board muss das dann auch unterstützen und Grafikausgänge haben), da weiß ich aber nicht, wie der Treiber unter FreeBSD gerade performt bzw. ob überhaupt. Eine weitere Grafikkarte kann man natürlich trotzdem immer dazustecken, eine Nvidia beißt sich da nicht. Wenn du eine hast, kannst du sie weiternutzen, eine Kombo ohne Grafikeinheit wählen und ein paar Euro sparen.

RAM: schau in der Anleitung vom Board, welche Riegel offiziell unterstützt werden. Dimensioniere auf mindestens 32GB bei knappem Budget, besser sind 64GB.
Auch hier je schneller, desto gut. Wenn du nicht spielst, kannst du getrost im guten Mittel bleiben. Sprich ungefähr bei DDR5-6000 +/-.
Das letzte Quäntchen Highend wird viel zu teuer und nicht jedes Board mag alle schnellen Riegel bzw. bei mehr als zwei Highend-Riegeln kann es Probleme geben. Den bunten Blinkquatsch mit LEDs dran kann man sich auch sparen.

 

[pit234a]

Ja. rsync kann zwar auch nur Änderungen wegkopieren. Standardmäßig legt aber rsync während des kopierens ne neue Datei an. Und das kann dann ziemlich viel Zeit kosten. Mit dem Parameter --inplace kann man dieses Verhalten verhindern (siehe rsync Manpage). Sollte man aber mit Bedacht einsetzen, weil man sich damit auch leicht mal was kaputt machen kann.
Idealerweise sind die Dateien auf dem Backup-System versioniert.

Alternativ sichert man gar nicht das komplette Image, sondern nur die Nutzdateien. Images lassen sich in der Regel ja per Loopback- bzw. md-Device mounten. Mit Hilfe von NTFS-3G kriegt man da gut seine Dateien aus der Image-Datei rausgekratzt.

so wirklich traue ich ntfs-3g unter FreeBSD immer noch nicht, aber das ist wahrscheinlich doof.

Deshalb also der einfache Weg.
Wenn ich etwas in der VM gemacht habe, sichere ich sie halt komplett (mehrfach). Eben auch nach Extern.

Nur bin ich soweit noch gar nicht.
Weil ich die Win10-VMs quasi nie benutze, bin ich gerade dabei, diese zu aktualisieren. Das ist auch doof von mir, ich sollte das häufiger während des Betriebes machen und nicht erst dann, wenn ich es brauche.
Ist halt so und dann mache ich natürlich auch interne Kopien/Sicherheitspunkte der VMs und das ist schon einige nahezu 100G, die ich dann auf extern derzeit mehrfach am Tag sichere.

--inplace bewährt sich da kaum.
Bei einzelnen Dateien und "kleineren Gebinden" wohl schon, aber bei mir heißt es eben warten....

 

[turrican]

Sandforce war wirklich ein besonders herausragender Haufen Scheiße. Aber die Zeiten sind ja zum Glück lange vorbei

War mir bis heute nicht bewußt, aber der Sandforce Controller lebt noch weiter, zumindest in den m.2 SSD-Speicherkärtchen von Kingston

Hatte heut bei ner APU2 mit m.2 SSD nen smartctl laufen lassen, vielleicht für einige von Interesse:

Model Family:     SandForce Driven SSDs
Device Model:     KINGSTON SMS200S330G

Hatte vor ein paar Jahren zwei Stück dieser m.2 SSDs für den Betrieb mit APU2 geholt, eine is schon kaputtgegangen (einfach von einer Sekunde auf die andere hin), die zweite läuft seit ca 1600 Betriebs-h.

 

[medV2]

War mir bis heute nicht bewußt, aber der Sandforce Controller lebt noch weiter, zumindest in den m.2 SSD-Speicherkärtchen von Kingston

Hatte heut bei ner APU2 mit m.2 SSD nen smartctl laufen lassen, vielleicht für einige von Interesse:

Model Family:     SandForce Driven SSDs
Device Model:     KINGSTON SMS200S330G

Hatte vor ein paar Jahren zwei Stück dieser m.2 SSDs für den Betrieb mit APU2 geholt, eine is schon kaputtgegangen (einfach von einer Sekunde auf die andere hin), die zweite läuft seit ca 1600 Betriebs-h.

Das ist ein mSATA, also SATA für den m2 Port, also kein direkter PCIe Anschluss. Dieser Schwachsinn sollte ja schon genug über das Produkt aussagen, da haben sie sicher den größten Müll verwurstet, den sie noch rumliegen hatten

 

[pit234a]

ich möchte versuchen, eine kurze Rückmeldung zu geben, obwohl ich da nun seit vielen Tagen am herumprobieren bin.

Gleichzeitig, oder vorab habe ich aber noch ein Problem, das am ehesten durch einen Fehler von mir verursacht worden ist und das ich gar nicht durchblicke und nicht lösen kann. Es sind nämlich ca 15 Dateien mit permanenten Checksumme-Fehlern vorhanden und ich bekomme die nicht weg.
Am einfachsten zeige ich mal das erste File aus der zpool status Ausgabe:

errors: Permanent errors have been detected in the following files:

        //usr/home/projekt-x/21-12-14 - arte - Krimi_im_kreml.ts

mir fällt auf, dass der Pfad nicht mit / sondern mit // beginnt und das ist bei allen folgenden Dateien auch der Fall. Das hier gezeigte ist ein Film, den ich natürlich eigentlich nicht brauche (obwohl er bald nach Veröffentlichung aus der Mediathek genommen wurde) und den ich natürlich auch an einem besseren Ort gespeichert habe. Deshalb machte es mir kein Herzblut, den zu löschen.

pit@Celsius /home/pit:-# ll "//usr/home/projekt-x/21-12-14 - arte - Krimi_im_kreml.ts"
ls: //usr/home/projekt-x/21-12-14 - arte - Krimi_im_kreml.ts: No such file or directory

Danach ein zpool clear, zpool online und erneuter scrub: zeigt wieder die Datei mit permanenten Fehlern, wie im ersten Beispiel. Ein find über / zeigt zwar zwei Dateien, aber außerhalb des Pools und die haben auch gleiche Checksumme und funktionieren auch. Alle angemeckerten dateien, die ich überprüfen kann, funktionieren und teilweise sind da Virtual-Box-Disks dabei, die ich gestern noch benutzt und auch verändert habe.

Außer diesen 15 Dateien gab es zunächst einige mehr, alle aus einem externen Speicher zurück gespielt und gut zu finden und zu lösen. Nur mit diesen Doppel // Dingern tappe ich im Finstern.


Ich hätte sollen alles neu machen!
Warum doch nicht?
Zunächst wohl mein Charakter. Ich wollte es einfach anders versuchen, obwohl meine komplette Backup-Strategie darauf ausgelegt ist, im fehlerfall das System neu zu machen und die gesicherten Daten zurück zu spielen. Das ist einfach vernünftig, aber Mangels Übung "im Neumachen" fürchtete ich diesen Schritt und hatte sodann auch die Hoffnung bekommen, es einfacher haben zu können.
Sodann wollte ich aber "Neumachen" auch mit neuer HW verbinden und hier kam mir das Angebot eines Bekannten eines Bekannten meines Sohnes in die Quere, der mir gute HW billig verkaufen wollte, dann aber wohl plötzlich ins Vor-Sommerloch gefallen ist. Seit Wochen höre ich nichts mehr und warte dennoch eine kurze Weile weiter, weil sich das nun mal so gehört.
Also, doch nicht alles Neu, alles noch beim Alten.
Aber, ich wollte ja und machte deshalb eine zusätzliche Sicherung nach der Anderen, nur für den Fall der Fälle und um eben gerüstet zu sein.

Eine Möglichkeit, die mir weiter oben schon mal durch den Kopf gegangen war, ist ja ein RollBack.
Mhhm. Bevor ich das probieren wollte, dachte ich aber, kann ich auch den "last known good" snap auch einfach mal auf ein externes Medium legen und erst mal dort betrachten. Mittels zfs send | recv transportierte ich den kompletten Snap und der bestand alle Tests. zpool status und zdb waren zufrieden.
Das überraschte mich, aber es gab mir nun auch einen externen Pool, den ich auch benutzen konnte.
Mhhm. Das kann ich doch auch mal Spaßeshalber mit einem aktuellen Snap probieren? Den "last known good" hatte ich nun ja sicher. Also mal alle älteren gelöscht, einen aktuellen angelegt und diesen gesendet: ebenfalls alles gut!
Das überraschte mich dann noch mehr!
Es sieht so aus, als hätte ich hier eine sehr einfache Möglichkeit gefunden, alle Daten zu sichern und einen heilen neuen Pool aus dem kaputten zu generieren.

Bevor ich das jedoch einsetzen wollte, testete ich den Pool noch mehrfach und es zeigten sich zunehmend mehr Fehler. Das Medium war eine Micro-SD-HC-Karte in einem USB-Reader und neu. Die erste Prüfung hatte gar keinen Fehler gezeigt und am nächsten Tag waren es schon zwei Dateien und dann drei, nun fünf, aber bislang auf dem Stand stabil. Seltsam: alle fünf sind Virtual-Disks, also relativ große Dateien.
Trotzdem entmutigte mich das zunächst, dieses Medium zu nutzen und stattdessen setzte ich den "last known good" ein, der nach wie vor keine Fehler zeigte und die zuvor gemachten zusätzlichen und deshalb einige Stunden jüngere Sicherungen, um damit meinen Root-Pool neu aufzusetzen.


Das liest sich schön einfach. Ihr müsst aber bedenken, dass ich nicht in der Materie drin stecke und keine Erfahrung habe. Deshalb passierten mir viele, teilweise banale Fehler (falsche Pfadangaben, um nur mal eines zu nennen). Aber ich stolperte auch darüber, dass die externen (USB) Medien einfach gelegentlich mal aussetzten, bzw Aussetzer produzierten. Weiter oben hatte ich ja ein Problem an einem USB-Anschluss festgestellt und traute mich schließlich nur noch mit einem einzigen USB-Anschluss zu arbeiten. Aber auch bei Überprüfungen auf einem anderen System musste ich diese gelegentlichen Aussetzer feststellen. Die Platten werden langsam, dann stehen sie, gehen in Standby und anstatt sich ordentlich wach zu rütteln, geben sie scheinbar ganz auf und liefern dann keine Daten mehr. Das kommt natürlich nicht immer vor, aber wenn man über Nacht Daten zurück spielen wollte und am Morgen merkt, dass es irgendwie gar nicht weiter geht. ist das eben schon doof und verunsichert zusätzlich.


Um die abenteuerliche Geschichte nicht auszuweiten, nochmal zusammen gefasst.
Ich komme mit dem Problem von oben gerade nicht weiter, kann aber gut mit meinem System arbeiten und es zeigen sich ansonsten keine Fehler. Eine aktuelle Datensicherung habe ich bisher nicht gemacht, weil ich mir wegen der festgestellten Fehler im Pool noch ein wenig Sorgen mache.

Erstaunlicherweise zeigte der Klon des beschädigten Pools aus einem aktuellen Snap mittels zfs send | recv auf ein externes Medium gespielt (zunächst) gar keine Fehler. Er zeigt auch nun keine Fehler beim Scan mit zdb -bc.