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

[pit234a]

vfs.zfs.recover="1" in der /boot/loader.conf hat mir eben sehr geholfen.

Vorausgegangen ist ein unerklärlicher Crash einiger zpools, darunter auch mein ROOT-pool.

Wie das passiert ist, weiß ich gar nicht.
Wann das passierte schon etwas besser. Nämlich, nachdem ich, wie inzwischen ja gewohnt eher nebenbei einen freebsd-update von 13.1 auf 13.2 gemacht hatte. Die meisten Fehler passieren mir dabei dann, wenn ich nochmal beim Mergen Hand anlegen will, weil ich da unbedingt noch was verbessern möchte. An sowas habe ich mich also bereits gewöhnt und mache niemals einen Upgrade ohne einen aktuellen Snap zu erstellen (und natürlich vorher auch drei Backups meiner "working-Datas" zu haben). Soweit alles gut.
Nur läuft das normalerweise immer gleich: freebsd-update...install...Neustart..und...nochmal..install.

Diesmal war es mir zu spät und ich wählte nach dem ersten install ein shutdown, um dann am nächsten Morgen weiter zu machen. Auch das noch alles gut, nur wartete ich den shutdown nicht ab und hätte dann ja eh nichts machen können. Mein PC hat ja eine Macke und schaltet sich sehr unzuverlässig gelegentlich einfach aus. Vielleicht hat dies hier genau während shutdown gefunkt, denn am nächsten Morgen konnte ich den Rechner nicht mehr booten und erhielt eine Crash-Meldung, die so schnell verging, dass ich mit Handy ein unbeholfenes Video davon aufgenommen und davon dann ein Bild gemacht habe, an dem ich mich weiter orientierte:

Das gute Internet gab mir einige Vorschläge dazu und ich konnte tatsächlich meine korrupten Pools nur noch importieren, nachdem ich in meinem Notsystem mit vfs.zfs.recover="1" in der loader.conf gebootet hatte. Ansonsten gab es sofort den oben gezeigten Crash.

Ein mehrfaches scrub bereinigte die Pools, aber ich setzte trotzdem nun auch das vfs.zfs.recover="1" in meinen ROOT-Pool des aktiven Systems.
Dieses bootete dann anschließend und ich konnte meinen freebsd-update beenden und so weiter.

Nun habe ich dieses vfs.zfs.recover="1" noch immer in der loader.conf.
Ich glaube, dass ich es nun nicht mehr brauche, aber, wenn ich das schon so gehabt hätte, wäre mir womöglich ein wenig Arbeit erspart geblieben.

Deshalb hier die Frage, ob es Nachteile bringt, es in der loader.conf zu haben. Also quasi für den Fall der Fälle, der eigentlich nie passiert...

 

[turrican]

Dieses Setting "entschärft" einige vitale Checks des zpools beim hochfahren/mounten des Pools und generiert bei Fehlern nur Warnungen, anstatt panic() aufzurufen (und den Vorgang somit "hart" abzubrechen);
Du könntest es also drin belassen, allerdings braucht es ein "gesunder" Pool definitiv nicht - und es könnte sein, dass du bestehende Probleme weiter mitschleppst/aufstaust.
Ich persönlich würde es wieder abschalten - und bei panic reagieren.

Du könntest den fraglichen pool noch mit einem zdb -bc <poolname> checken; am besten pool exportieren (bei boot-pool natürlich doof -> ggf ginge ein Live-OS), bei exportiertem Pool noch zusätzlich den schalter "-e" dazufügen: zdb -e -bc <poolname>

Hier ein Beispiel von einem (gesunden) Pool hier auf nem Server:

root@srv2[~]# zdb -e -bc vol1

Traversing all blocks to verify metadata checksums and verify nothing leaked ...

loading concrete vdev 0, metaslab 115 of 116 ...
40.3G completed ( 223MB/s) estimated time remaining: 0hr 00min 00sec      
        No leaks (block sum matches space maps exactly)

        bp count:               1339205
        ganged count:                 0
        bp logical:         51084872704      avg:  38145
        bp physical:        42932260864      avg:  32058     compression:   1.19
        bp allocated:       43341082624      avg:  32363     compression:   1.18
        bp deduped:                   0    ref>1:      0   deduplication:   1.00
        Normal class:       43341328384     used:  4.39%
        Embedded log class              0     used:  0.00%

        additional, non-pointer bps of type 0:         64
        Dittoed blocks on same vdev: 46607

EDIT:
Die Doku meint dazu auch "zfs_recover should only be used as a last resort, as it typically results in leaked space, or worse"

 

[mr44er]

Genau, denn im Umkehrschluss stoppt die panic auch als Sicherheit, damit nicht noch mehr kaputt geht.

Obligatorisch: hast du mal einen memcheck laufen lassen oder ein anderes Netzteil zum Gegencheck? Das Bauchgefühl sagt, dass das irgendwie nach defekter Hardware aussieht.

 

[turrican]

Der Fehler könnte auch eingeschleppt worden sein, als sich die Maschine mal spontan selber abschaltete wie pit234a oben beschrieben hatte - ein "guter" scrub Lauf hernach ist kein Garant, dass nicht doch schon was mit dem zpool passiert ist - es gibt scheinbar Fehler, welche scrub nicht sieht - so zumindest meine Erfahrung.

Bisher hatte das bei mir dann der oben beschriebene zdb-Lauf aufgedeckt - der bricht dann - wenn schon was schlimmeres auf dem Pool vorgefallen ist - ggf aber auch an ner gewissen Stelle ab, ohne das reparieren zu können - man kann dann den Pool nur noch ro-mounten und die Daten auf nen anderen Pool retten bzw Pool neu bauen und Daten aus dem letzten Backup einspielen (oder den Pool mittels einer der letzen als gut bekannten txg starten, aber diese Info steht einem meist nicht zur Verfügung, bzw liegt schon zu weit zurück, als dass man noch von ner "guten" txg starten könnte).

 

[pit234a]

Genau, denn im Umkehrschluss stoppt die panic auch als Sicherheit, damit nicht noch mehr kaputt geht.

Obligatorisch: hast du mal einen memcheck laufen lassen oder ein anderes Netzteil zum Gegencheck? Das Bauchgefühl sagt, dass das irgendwie nach defekter Hardware aussieht.

unbedingt!
Ich suche danach schon seit Monaten erfolglos und nach dem letzten Tausch des Netzteils hatte ich eine sorglose Uptime von über 60 Tagen und glaubte natürlich, damit schon gewonnen zu haben.
memcheck ist nicht unbedingt mein Freund. Solche sehr sporadischen Fehler habe ich noch nie mit diesem Tool finden können und es braucht für umfassende Checks ja gefühlte Wochen. Deshalb hatte ich (in einem anderen Thread aus anderem Grund erwähnt) versucht, den Speicher irgendwie gezielt zu belegen und auch SWAP zu erzwingen, um eine Reaktion zu sehen.
Es bleibt für mich einfach mysteriös und scheint nicht nachvollziehbar, auch nicht mit Gewalt.

Aber ja, es schreit nach neuer HW und dabei ist die erst vier Jahre alt!

zdb erschlägt mich, das gebe ich ganz ehrlich zu.
Ich hatte einige Dinge probiert und die beste Rückmeldung war ungefähr, dass es meine gewünschte Datei gar nicht gibt.
Die Datei sollte eigentlich der Name meines (offline)- Pools sein.
Nun ist der Pool ja wieder Online und arbeitet auch ganz gut und obwohl nur privat genutzt, habe ich damit auch einige Arbeit zu machen und nicht so viel Zeit, Experimente zu fahren und die Materie genauer kennen zu lernen. Was ich dann alles eh ja sofort wieder vergessen würde und für den nächsten Ernstfall nicht parat hätte.
Ich reflektiere mal kurz meine Situation:
eigentlich hätte ich das System neu aufsetzen sollen, meine Backups einspielen und gut ist.
Irgendwie war ich dafür zu stolz.
Wann habe ich zuletzt ein FreeBSD neu installiert? Kann mich gar nicht erinnern.
Meine zweite Option war es, den zuvor angefertigten Snap zurück zu spielen. Aber dafür musste ich den Pool erst mal importieren können. Ohne vfs.zfs.recover="1" ging das aber gar nicht. Auch nicht mit dem benutzten Life-System!

Das Hauptproblem dabei ist für mich gewesen, dass dann, wenn der ROOT-Pool dermaßen zickt, ich gar nicht weiter komme.
Ich kann die Meldung nicht mal lesen und weiß zunächst mal gar nicht, dass ZFS betroffen ist. Ich sehe ja auch keine Crash-Logs und sonnst gar nichts, das System startet nur immer neu und meldet den Fehler schneller, als ich ihn lesen kann.
Ich war da zunächst ziemlich hilflos.
Hilflos gefällt natürlich nicht und obwohl ich das in meinem entsprechenden Live-(Rettungs)-System nun bereits rein genommen habe, dachte ich daran, dieses vfs.zfs.recover="1" auch in meinem aktuellen System zu setzen, obgleich ich es da nicht brauche und nach euren Ratschlägen wohl auch gar nicht will.


Was ich aber noch fragen möchte.
Es gab dann nach dem ersten Scrub eine Meldung, in einer Datei sei ein nicht behebbarer Fehler gefunden worden.
Dazu gab es aber nicht den Namen der Datei, sondern etwas der Art: <0x111111>:<0x2222222>, nun sinnfrei aus dem Gedächtnis getippt.
Kann ich dazu mittels zdb den Namen/Speicherort der derart beschädigten Datei finden?
Meist braucht man die ja nicht und kann sie durch die entsprechende Datei aus dem Backup ersetzen. Nur kam ich hier einfach nicht weiter und nach einem weiteren Scrub war die Meldung dann verschwunden.

 

[turrican]

Wenn ich mich recht zurückerinnere dann gab das zdb auch keinen Pfad zu ner Datei bzw ne direkte Datei o.ä. aus, sondern auch eher nen Adresszeiger oder zwei, aber genau kann ich mich nicht mehr an die Details erinnern, is schon ne Weile her;

Das zfs Filesystem ist eigentlich recht robust, würde mich interessieren, was da genau schiefgegangen ist.

Lass doch mal bei Gelegenheit nen zdb -bc auf dem Pool laufen, ohne ihn zu exportieren - ggf sieht man da schon was (aktuelles Backup der Daten haste vorliegen?)

 

[pit234a]

Lass doch mal bei Gelegenheit nen zdb -bc auf dem Pool laufen, ohne ihn zu exportieren - ggf sieht man da schon was (aktuelles Backup der Daten haste vorliegen?)

also, ohne zu exportieren, geht ja leicht:

pit@Celsius /home/pit:-# zdb -bc Celsius

Traversing all blocks to verify metadata checksums and verify nothing leaked ...

loading concrete vdev 0, metaslab 56 of 116 ...error: zfs: removing nonexistent segment from range tree (offset=7008204000 size=600)
Abbruch
pit@Celsius /home/pit:-# zdb -bc aussenlager-2

Traversing all blocks to verify metadata checksums and verify nothing leaked ...

loading concrete vdev 0, metaslab 115 of 116 ...
 573G completed (9831MB/s) estimated time remaining: 0hr 00min 01sec         
    No leaks (block sum matches space maps exactly)

    bp count:               5793055
    ganged count:                 0
    bp logical:        729743212032      avg: 125968
    bp physical:       616370745344      avg: 106398     compression:   1.18
    bp allocated:      616704231936      avg: 106455     compression:   1.18
    bp deduped:                   0    ref>1:      0   deduplication:   1.00
    Normal class:      634574802944     used: 64.24%
    Embedded log class        2237952     used:  0.03%

    additional, non-pointer bps of type 0:      11482
    Dittoed blocks on same vdev: 53459
    Dittoed blocks in same metaslab: 12

pit@Celsius /home/pit:-# zdb -bc Celsius

Traversing all blocks to verify metadata checksums and verify nothing leaked ...

loading concrete vdev 0, metaslab 56 of 116 ...error: zfs: removing nonexistent segment from range tree (offset=7008204000 size=600)
Abbruch

Das sind die beiden betroffenen Pools, also jene, welche dann Fehler zeigten.
Celsius ist der ROOT-Pool und da habe ich das dann auch doppelt laufen lassen.
Schon ein wenig beunruhigend, oder?

 

[turrican]

Oh ja - da is definitiv was mit dem Pool;

Das wäre jetzt die Situation, in welcher zfs.recover auf 0 ein panic() aufrufen würde -> da Intervention notwendig.

Keine Ahnung ob ein zfs Experte da trotzdem noch was retten könnte, mein Wissen darüber endet definitiv hier.

Im Endeffekt bleibt nur destroy des Pools und einen neuen erstellen - vor dem neu erstellen vielleicht noch die aktuellen Werte der Disk mit smartmontools prüfen, ggf nen short und long check laufen lassen.

 

[mr44er]

Wenn du ein Backup hast, kann man Folgendes ausprobieren: https://github.com/openzfs/zfs/issues/13483#issuecomment-1205941970

Import/Export ist dann wichtig und wenn das Importieren ohne Krachbumm geht, sollte alles gut sein. Ein nochmaliger scrub empfiehlt sich.
Wenn der nicht behebbare Fehler ohne ein zpool clear wieder verschwand, sollten zumindest keine Daten verloren gegangen sein.

Btw. würde ich die Reparatur auch nicht auf der defekten Hardware durchführen wollen und selbst wenn das klappt...wie lange gehts gut, bis du wieder an dem Punkt bist? Bin mir ziemlich sicher, dass das daher kommt.
Für solche Hardwaremacken sollte man eigentlich jede Komponente zum präzisen Gegentest auf Lager haben...aber ich weiß ja wie das mit der Realität ist: Ein Büro ist keine Werkstatt.

 

[turrican]

Laut der Seite sollte sich so ein Pool mittels dieser Settings wieder mounten lassen:

sysctl vfs.zfs.spa.load_verify_data=0
sysctl vfs.zfs.spa.load_verify_metadata=0
sysctl vfs.zfs.recover=1
sysctl vfs.zfs.zil.replay_disable=1

Ob keine Daten verloren gegangen sind: wie könnte man das mit letzter Sicherheit feststellen? Gibts da ne (zfs-Bordmittel-)Methode - außer z.B. ne 'last-known-good' Version aller Dateien ausm Backup mittels sha256 per Skript bearbeiten lassen und die Hashes mit dem Ist-Stand vergleichen?
Das Backup könnte ja auch schon beschädigte Daten enthalten.

Ein scrub geht ja scheinbar drüber, ohne ne Auffälligkeit zu melden - also scheint dieses Problem dann doch nicht so schwerwiegend? Warum dann defaultmäßig panic()?

 

[mr44er]

Gibts da ne (zfs-Bordmittel-)Methode

Da ist mir nichts bekannt.

Ein scrub geht ja scheinbar drüber, ohne ne Auffälligkeit zu melden - also scheint dieses Problem dann doch nicht so schwerwiegend? Warum dann defaultmäßig panic()?

Wie ich das verstanden habe, gehts da nur um die spacemaps, also doppelt markierter, freier Speicher, was die panic dann zündet, da nicht klar ist, ob das jetzt wirklich frei ist oder nicht.

Wenn der scrub nichts mehr meldet, würde ich jetzt mal davon ausgehen, dass auch das Backup ok ist. Dafür hat man ja Versionierung oder ein Zweitbackup. (hoffentlich!)

 

[turrican]

gehts da nur um die spacemaps, also doppelt markierter, freier Speicher, was die panic dann zündet, da nicht klar ist, ob das jetzt wirklich frei ist oder nicht.

Irgendwo (find das jetzt leider auf die schnelle nicht) hatte ich mal gelesen, dass bei diesem metaslab/adding-existing-segment-to- range Fehler auch genau der andere Fall eingetreten sein könnte: dass Speicher irrtümlich als frei markiert - und wg CoW schon wieder benutzt wurde - da wären dann Daten verloren gegangen.
EDIT: und die Meinung war dazu dann: Pool neu bauen und Daten rücksichern;
Was mich halt immer noch wundert is, dass ein scrub über sowas hinwegsieht - oder erwarte ich da vom scrub zu viel?

Wenn der scrub nichts mehr meldet, würde ich jetzt mal davon ausgehen, dass auch das Backup ok ist. Dafür hat man ja Versionierung oder ein Zweitbackup. (hoffentlich!)

aber da scrub ja nie was gemeldet hat, weiss man ja auch nie wie weit ein etwaiger Datenverlust schon zurückliegt...

 

[Yamagi]

Was mich halt immer noch wundert is, dass ein scrub über sowas hinwegsieht - oder erwarte ich da vom scrub zu viel?

Das immer noch durch das Netz geisternde Missverständnis ist, dass scrub ein Ersatz für fsck sei. Ist es aber tatsächlich nicht. scrub prüft die Daten im Pool auf Konsistenz und repariert gefundene Konsistenzprobleme (wenn möglich) mit ZFSs Self Healing Funktionen. Metadaten werden dabei nur soweit beachtet, wie es notwendig ist, um die Daten zu traversieren. Das stellt hauptsächlich sicher, dass die Metadaten lesbar und ihre Checksums korrekt sind. Komplexe Metadatenprobleme kann scrub nicht erkennen und muss es eigentlich auch nicht, denn durch ZFSs transaktionsbasierte Architektur sollten sie nicht vorkommen. Sind Metadatenblöcke zerstört, gibt es bis zu 6 Kopien zur Wiederherstellung.

Wenn es - aus welchen Gründen auch immer - soweit gekommen ist, dass ein Pool nicht mehr importiert werden kann oder das System durch Inkonsistenten im Pool crasht, ist die Sache verloren. Man wird hinterher nie sicherstellen können, dass die Metadaten wirklich konsistent sind. Der einzige sinnvolle Weg ist dann, die Daten aus dem Backup auf einen neuen Pool wiederherzustellen. Funktionen wie zpool import -F oder eben sysctl vfs.zfs.recover=1 und den anderen oben genannten sysctl existieren hauptsächlich, um aus einem zerstörten Pool noch Daten ziehen zu können. Nicht, um ihn zu reparieren. Sie überdecken Probleme nur, lösen sie aber nicht.

Interessant ist eher die Frage, wie der Pool überhaupt zerstört wurde. Alle zerstörten Pools, die ich über die Jahre hatte, waren entweder defekte Hardware, das Problem alte mit lügender Hardware - was allerdings in den letzten 10 Jahren im Desktopbereich wesentlich besser geworden ist - und einmal Speicherkorruption durch einen mit ZFS überhaupt nicht zu tun habenden Bug in einem NIC-Treiber.

 

[pit234a]

leider vermute ich auch nur, dass tatsächlich während des manuellen shutdown auch ein HW-Kollaps passiert ist. Ich weiß das aber nicht sicher, die Kiste war ja aus, als ich mich wieder ran setzte. Nur kamen solche plötzlichen Aussetzer in der Vergangenheit ja bereits vor. Deshalb halte ich das irgendwie für plausibel.
Der manuelle shutdown erfolgte nach dem ersten Durchgang von freebsd-update von 13.1 auf 13.2. Ob da bereits neue Module im Spiel gewesen sein könnten? Es gibt immerhin nun ja diese Einträge zum if_rtw88.ko in der dmesg, die mir auch nicht wirklich gefallen.

Ich überlegte noch, einen rollback zu versuchen?
Damit kann ich ja die Daten vor dem Ereignis herstellen. Dann müsste das ja auch wieder heile sein.

Meine Backups laufen in der Nacht automatisch mit rclone und rsync, also nicht auf zfs-Ebene (send/receive). Da und mit smartctl seinen Selbsttests sieht die Welt bisher noch gut aus.

Der PC ist erst vier Jahre alt und ich wollte, dass er wenigstens fünf Jahre hält. Ich sehe nun noch nicht wirklich Not, aber natürlich wäre es auch nicht so daneben, die HW komplett zu ersetzen und ein Jahr früher als geplant umzusteigen. Doch das will ich nach Möglichkeit nicht heute und morgen durchdenken. So zwischen 20.04. und Ende Mai habe ich immer besonderen Bedarf an meinem PC. Das hört sich widersprüchlich an, aber da käme mir eine Neuanschaffung eher in die Quere.
Ich denke, mit einigen häufiger durchgeführten Offline-Backups auch während des Tages und meinem guten und treuen Laptop habe ich jedenfalls auch ein Ausfallkonzept.

 

[turrican]

Ich überlegte noch, einen rollback zu versuchen?
Damit kann ich ja die Daten vor dem Ereignis herstellen. Dann müsste das ja auch wieder heile sein.

ich denke, dass bei einem Rollback das Problem mit dem Defekt am Pool bestehen bleibt und nur ein pool destroy, pool create und dann rollback aus dem Backup abhilft;
einen Versuch vorher wäre es aber doch mal wert (wenn du die Zeit hast) - würde mich auch interessieren;

 

[turrican]

Irgendwo (find das jetzt leider auf die schnelle nicht) hatte ich mal gelesen, dass bei diesem metaslab/adding-existing-segment-to- range Fehler auch genau der andere Fall eingetreten sein könnte: dass Speicher irrtümlich als frei markiert - und wg CoW schon wieder benutzt wurde - da wären dann Daten verloren gegangen.

Hab zwar nicht die Quelle zu dem oben von mir gesagten gefunden, aber im zfs-Quelltext im File module/zfs/range_tree.c steht dieser Kommentar am Funktionsaufruf zfs_panic_recover(), welche dann die Meldung "adding existent segment to range tree" oben von @pit234a generiert:

* If this is a gap-supporting range tree, it is possible that we
* are inserting into an existing segment. ...

das würde sich erstmal ja schlecht anhören, aber ob das nun Daten überschreibt, kann ich mit meinem nicht-Wissen über die internen zfs Strukturen jetzt nicht draus ableiten, da es quasi weitergeht mit "wir müssen in dem Fall dann nur..."

* ...In this case simply
* bump the fill count and call the remove / add callbacks. If the
* new range will extend an existing segment, we remove the
* existing one, apply the new extent to it and re-insert it using
* the normal code paths.

Das hört sich dann ja wieder so ala "alles halb so wild" an... aber trotzdem panic()en sie ja hernach pauschal mal.

 

[Andy_m4]

Aber ja, es schreit nach neuer HW und dabei ist die erst vier Jahre alt!

Ja schon. Aber im Zweifel muss man halt vielleicht doch mal was machen. Weil man hat ja auch nie ein gutes Gefühl dabei.
Hardware auf der wegen sporadischer Fehler der Pool kaputt geht ist so ein bisschen wie ein Auto zu fahren, wo manchmal die Bremse nicht richtig funktioniert.

Um den finanziellen Verlust etwas abzufedern könntest Du die Hardware ja an die Bundeswehr verkaufen. Die haben ein fettes Sondervermögen und wissen gar nicht wohin damit und dann droht es wieder in irgendwelche Beraterfirmen zu versickern.
Stattdessen können die sich damit brüsten in "Cyber, Cyber" investiert zu haben.
Also klassisches Win-Win. :-)

Und falls Du Angst hast, das könnte unsere Verteidigungsfähigkeit beeinträchtigen, so kann ich Dich beruhigen:
Die ist auf so niedrigen Level, die kann nicht weiter fallen. :-)

 

[mr44er]

Der PC ist erst vier Jahre alt und ich wollte, dass er wenigstens fünf Jahre hält. Ich sehe nun noch nicht wirklich Not, aber natürlich wäre es auch nicht so daneben, die HW komplett zu ersetzen und ein Jahr früher als geplant umzusteigen. Doch das will ich nach Möglichkeit nicht heute und morgen durchdenken.

Ganz komplett musst du auch nicht kaufen. Es reicht ja eine Kombi mit Board, CPU und RAM (eventuell neues Netzteil). Bis der Fehler nicht eindeutig gefunden ist, dürfte dir die Hardware im Ist-Zustand den pool wieder kaputtmachen. Wenn es denn so war, ich halte das als die wahrscheinlichste Ursache, gerade wenn sie vorher schon desöfteren abstürzte.
Wenn die alte HW mal außer Betrieb ist, kann man sich damit risikolos beschäftigen und nach der Reparatur ggf. einem neuen Zweck zufügen, NAS-HW tauschen oder MediaPC etc.

Ich hatte auch noch nicht das Vergnügen, mir einen produktiven pool unabsichtlich geschrottet zu haben, daher wenig bis gar keine Erfahrung zu Erfolg oder wo man da anhebelt. Die tendenzielle Meinung bei solchen Defekten zu neuem pool nehme ich daher gerne an.

 

[pit234a]

Ganz komplett musst du auch nicht kaufen. Es reicht ja eine Kombi mit Board, CPU und RAM (eventuell neues Netzteil).

naja, und auch ne neue GraKa wäre kein Luxus und NT werte ich eher als Verschleißteil und habe die auf Vorrat hier liegen und deshalb ja schon erneuert.

Das Problem ist für mich als End-Nutzer ja, dass ich nicht ein MB und CPU und RAM auf Vorrat halten kann. Es gibt diese Kombi ja nur einmal bei mir. Es macht keinen finanziellen Sinn, immer ein zweites MB und eine zweite CPU mit zu kaufen.
Den Rest habe ich quasi schon durch und erfolglos getauscht.

Das Gehäuse ist ja im Grunde nur Metall-Schrott und inzwischen gefühlte 20 Jahre + im Einsatz.
Das schreit alles geradezu nach neuer HW, aber wie gesagt, im Moment bin ich froh, wenn ich zunächst mal so weiter arbeiten kann.

Und zwar auch ohne Experimente, die mich selbst zwar sehr interessieren, aber gerade mal in den Hintergrund gedrückt werden.
So lange es geht, nutze ich nun die nächsten Wochen den PC ohne weitere Änderungen und wenn er versagt, nehme ich meinen Laptop als Alternative.
Danach sehe ich dann weiter.

Und ich hoffe, dass das gut geht.
Bisher sieht es ganz gut aus.

 

[turrican]

... kann scrub nicht erkennen und muss es eigentlich auch nicht, denn durch ZFSs transaktionsbasierte Architektur sollten sie nicht vorkommen.

Ja genau - das war auch bisher mein Verständnis des ganzen zfs Gerödels - ne Transaktion läuft da entweder ab... oder halt nicht, in dem Fall wäre dann das ZIL beim Neustart gefragt. Inkonsistenzen dürften da doch gar nicht vorkommen?!?! Außer, wenn er nicht mal mehr das ZIL schreiben konnte?

Sind Metadatenblöcke zerstört, gibt es bis zu 6 Kopien zur Wiederherstellung.

Ist das die Default-Einstellung, ohne weiteres zutun beim Setup des Pools?

 

[turrican]

Und falls Du Angst hast, das könnte unsere Verteidigungsfähigkeit beeinträchtigen, so kann ich Dich beruhigen:
Die ist auf so niedrigen Level, die kann nicht weiter fallen. :-)

Ich war '97 beim Outdoorclub (damals war Volker Rühe BMdV), und genau den letzen Satz dachten wir damals eigentlich schon - aber es ging wohl noch tiefer.

Und ja, ich bin mir sicher: die "100 Mrd" (wenn die denn je kommen) versickern größtenteils bei irgendwelchen "Berater"firmen, ohne daß groß was für die Truppe rumkommt, und schon gar keine brauchbare, funktionsfähige Ausrüstung - geschweige denn des Faktes, dass das mit den 100 Mrd eh wieder nur heiße Luft aus des Bundeskanzlers Munde war...

 

[turrican]

Was mir noch spontan einfiel, als ich heut grad nach Platten für mein kleines NAS Projekt suchte:
@pit234a, deine Platte mit dem problematischem Pool drauf, was war das gleich noch für ein Modell?
War das vielleicht ein Modell mit SMR Aufzeichnungsmethode?

 

[Andy_m4]

in dem Fall wäre dann das ZIL beim Neustart gefragt. Inkonsistenzen dürften da doch gar nicht vorkommen?!?

Das ZFS Intend Log ist ja in dem Sinne keine Sicherheitsmaßnahme, sondern hat eher den Charakter eines Schreibcaches. Und sofern bringt das ja nicht eine grundsätzliche Lösung des Problems. Außer das es halt das problematische Zeitfenster verkleinern kann.

Ich war '97 beim Outdoorclub (damals war Volker Rühe BMdV), und genau den letzen Satz dachten wir damals eigentlich schon - aber es ging wohl noch tiefer.

Um mal im Netzwerker-Sprech zu bleiben: Deutschland ist die DMZ Europas. :-)

 

[turrican]

Das ZFS Intend Log ist ja in dem Sinne keine Sicherheitsmaßnahme, sondern hat eher den Charakter eines Schreibcaches. Und sofern bringt das ja nicht eine grundsätzliche Lösung des Problems. Außer das es halt das problematische Zeitfenster verkleinern kann.

ZIL (mein Verständnis davon bisher, bitte korrigier mich):
wird im Normbetrieb nur beschrieben, mit dem was sein wird (Metadaten, keine "Daten", sonst könnte zfs ja gleich die Daten schreiben), wird aber beim erneuten Hochfahren (nach einem Crash) abgespult, um konsistenten Zustand des Filesystems wiederherzustellen (ggf konsistent vor dem Crash, es konnten halt dann wirklich Transaktionen nicht 100% abgeschlossen werden, neue Daten nicht geschrieben, aber das FS ist wieder in einem konsistenten Zustand und kann weiter benutzt werden (kein fsck notwendig, wie bei ext, xfs, etc)

 

[Andy_m4]

ZIL

Die Idee hinter ZIL ist so ähnlich wie die Idee bei Cache. Pools sind relativ gesehen langsam, also schalten wir noch ein "schnelles Medium" (und/oder schnelle Organisationsstruktur) davor, um das (zumindest nach außen hin) zu beschleunigen.
Im Fall von ZIL heißt das halt, wenn irgendwas an Daten rein kommt dann schieben wir das erst mal ins ZIL (idealerweise liegt das auf einer schnellen SSD) und dann können wir uns in Ruhe damit befassen das in den Pool zu übertragen.

Was Du beschreibst ist ja eher das, was klassischerweise über ein Journaling realisiert wird. Da gehts ja explizit nicht um Beschleunigung oder so, sondern um Datensystemkonsistenz und das man die im Crash-Fall auch schnell wieder recovered kriegt ohne erst umständlich/langwierig ne Dateisystemprüfung zu machen.