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

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.
Kommen da dann die Daten oder nur die Metadaten rein?
 
dann könnte man doch gleich die Daten ins Ziellaufwerk schreiben - wäre doch kürzer als "Metadaten" UND "Daten" ins ZIL...
 
dann könnte man doch gleich die Daten ins Ziellaufwerk schreiben
Naja. Das ist halt - wie bereits gesagt - so ähnlich(!) wie bei Cache/ARC. Da könntest Du genauso argumentieren, das man ja direkt von Disk lesen könnte statt es durch den ARC zu schleusen.

Wie gesagt. Der ZIL hat eine Optimierungsfunktion. Sowohl von der Organisation der Datenstrukturen als auch die Tatsache das man ihn bevorzugt auf schnellen Datenträgern einsetzt hilft ja dabei.
Durch den Preisverfall im SSD-Bereich ist es heute vielleicht nicht mehr ganz so relevant, aber insbesondere wenn man ein Setup mit klassischen Magnetfestplatten hat und dann davor quasi ne SSD als "Schreibpuffer" schaltet, ist ja ganz offensichtlich, das es was bringt.
Natürlich nicht, wenn Du durchgehend schreibst weil irgendwann der Puffer volllaufen würde. Aber quasi Lastspitzen abfedern, dafür funktioniert es gut.

Ob und wieviel ZIL im jeweiligen Szenario bringt, muss man natürlich gucken. Nicht umsonst ist es ja per default nicht dabei, sondern muss explizit eingeschaltet werden.

Korrekterweise sollte ich aber an der Stelle sage, das ich hier ZIL etwas ungenau verwendet habe. Sowas wie ZIL hast Du nämlich immer. Was man aber häufig meint, wenn von ZIL gesprochen wird ist ZIL/SLOG (also das was man via zpool add mypool log ....). Wenn man das strenger betrachten und auseinander differenziert, so ist ZIL selbst quasi der "Journaling-Teil". Fügst Du SLOG hinzu, wird sowohl das Journal als auch der Schreibcache für Daten auf das Log-Device zwischengespeichert.
Meine Ausführungen beziehen sich auf ZIL/SLOG.
 
Zuletzt bearbeitet:
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?
Das mit dem ZIL hattet ihr jetzt ja schon. :) Grundsätzlich aber ja: Transaktionen umfassen Daten und Metadaten, Daten werden Metadaten ausgeschrieben. ZFS ist durch seine Transaktionen und sein Copy On Write Design immer konsistent. Transaktionen sind atomar, also entweder ganz oder gar nicht geschrieben. Stürzt das System während des Schreibens einer Transaktion ab, ist sie nicht als vollständig markiert und wir nach dem Neustart verworfen. Direkt aufeinanderfolgende Transaktionen überschreiben sich niemals. Ich habe nicht im Kopf, wie viele Transaktionen vergehen müssen, bis die Daten älterer Transaktionen überschrieben werden, aber es waren recht viele. Metadaten werden immer mehrmals geschrieben. Ich meine, dass die Anzahl dynamisch bestimmt wird, aber mindestens zwei Kopien.

Wenn das Dateisystem doch inkonsistent geworden ist, heißt das, dass etwas richtig böse schief gegangen ist. Zum Beispiel Softwarebugs, allerdings ist ZFS inzwischen so alt und reif, dass sie eigentlich nicht mehr vorkommen. Außer man nutzt wirklich extrem neue Funktionen, wie dieser Block Reuse Kram in FreeBSD 14-CURRENT letztens. Möglich sind auch Bug in anderen Kernelsystemen, die Nebenwirkungen haben. Aber FreeBSD ist da sehr stabil, sodass das unwahrscheinlich ist. Meist ist die Ursache Hardware. Entweder kaputte oder sterbende Hardware, vom RAM bis zum Medium kommt alles infrage. Sobald die Hardware nicht mehr funktioniert, ist man im undefinierten Niemandsland. Daher auch die Empfehlung regelmäßig zu scrubben, ein scrub findet sich anbahnende Probleme idealerweise früh. Im Desktopbereich ist auch lügende Hardware noch immer ein Problem, wobei das besser geworden ist. Also Hardware, die Anforderungen direkt auszuschreiben ignoriert, sondern Daten dennoch in Caches hält, umsortiert und so weiter. Es im Falle eines Absturz aber nicht mehr auf die Reihe bekommt, sie zu schreiben. Wirklich vermeiden kann man das nicht, außer man will viel Geld ausgeben.

Nochmal kurz zur ZIL. Das Ding ist hauptsächlich, aber nicht nur, als Lösung für Unterbrechungen des Transaktionsplans gedacht. ZFS sammelt alle schreibenden Änderungen in einer Queue und konstruiert daraus Transaktionen, die dann ausgeschrieben werden. Transaktionen werden ausgeschrieben, wenn genügend Daten vorhanden sind, sie also sozusagen voll sind. Oder, wenn nicht genügend Daten vorhanden sind, nach einem Timeout. Das Timeout lässt sich irgendwo konfigurieren. Das ist übrigens auch der Grund, weshalb ZFS Festplatten praktisch sofort aus dem Standby zurückholt. Beim erstellen der Transaktionen ist ZFS intelligent, es optimiert. Wenn z.B. mehrere Änderungen, die einen Block betreffen, in der Queue liegen, wird nur die letzte Änderung ausgeschrieben, da sie die vorherigen Änderungen aufhebt. Genauso können Metadatenänderungen zusammengefasst werden. Es werden erst alle Datenänderungen und am Ende einmal die Metadatenänderung geschrieben.

Das funktioniert solange gut, bis ein fsync() in der Queue landet. Das erzwingt alle ausstehenden Änderungen sofort auszuschreiben. In dem Moment muss ZFS die aktuelle Transaktion sofort abschließen, die Queue ohne Optimierungen in Transaktionen verpacken, ausschreiben und ein Leeren aller Caches auslösen. Das ist gerade bei mechanischen Platten extrem teuer. Durch unnötige Schreibkopfbewegungen, durch Schreiben von unnötig viel Metadaten, da dort der Verlust des Caches noch Sekunden nachwirken kann und so weiter. Leider machen Anwendungen, die auf Konsistenz bedacht sind, unendlich viele fsync(). Daher hat man die ZIL erfunden. Bei Nutzung der ZIL wird die Queue nicht mehr im ausschließlich RAM gehalten, sondern teilweise auf einem persistenten Medium. Sobald etwas in der ZIL gespeichert ist, ist es persistent und ZFS kann ein fsync() ignorieren. Stürzt das System ab, wird beim Neustart die ZIL zurück in die Queue gefüttert und die Änderungen damit ausgeschrieben. Die ZIL liegt normalerweise im Pool, kann aber auf ein Log-Device ausgelagert werden.
 
@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?
das SMR finde ich auf die Schnelle nicht in den Ausgaben.
Insgesamt habe ich da sechs SSD verbaut, die ich mir so nach und nach gegönnt hatte oder vorsorglich mal als E-Teil gekauft hatte und nach einiger Liegezeit dann doch verbaute.
Alle sechs sind gleicher Typ, aber unterschiedlich alt. Es sind Samsung SSD 870 QVO 1TB
Jeweils drei SSDs sind zu einem Z-Mirror vereint und einer davon ist mein Root-Pool. Der andere ist "Datengrab" und empfängt auch den ersten Backup in der Nacht. Diese beiden Pools hatten Fehler gezeigt, aber nur der Root-Pool verursachte die Panik und ist nun noch immer laut zdb nicht so ganz in Ordnung.

Code:
pit@Celsius ~:-# zpool status -v
  pool: Celsius
 state: ONLINE
  scan: scrub repaired 0B in 00:41:39 with 0 errors on Sun Apr 16 09:22:06 2023
config:

    NAME        STATE     READ WRITE CKSUM
    Celsius     ONLINE       0     0     0
      mirror-0  ONLINE       0     0     0
        ada0p2  ONLINE       0     0     0
        ada1p2  ONLINE       0     0     0
        ada2p2  ONLINE       0     0     0

errors: No known data error
Die Selbsttests mit smartctl liefern hier für keine SSD einen Fehler, beim zweiten Mirror gibt es für die neueste SSD einige Read-Fehler. Die erste SSD hat gerade 16000 Stunden auf dem Buckel und die letzte erst knapp 2600, also, die letzte ist die einzige, die Fehler notiert hat.

Im Augenblick bin ich froh und drücke die Daumen, dass alles funktioniert und ich kann mich derzeit nicht überwinden, überhaupt den PC mal neu zu starten, geschweige denn, etwas zu testen und zu probieren. Das große Heulen kann natürlich dann schon bald losgehen, aber mit ein wenig Glück schaffe ich noch meine anstehenden und anstrengenden Aufgaben damit zu bewältigen, ohne etwas zu verändern.
 
das SMR finde ich auf die Schnelle nicht in den Ausgaben.
Insgesamt habe ich da sechs SSD verbaut, die ich mir so nach und nach gegönnt hatte oder vorsorglich mal als E-Teil gekauft hatte und nach einiger Liegezeit dann doch verbaute.
Alle sechs sind gleicher Typ, aber unterschiedlich alt. Es sind Samsung SSD 870 QVO 1TB
Jeweils drei SSDs sind zu einem Z-Mirror vereint und einer davon ist mein Root-Pool. Der andere ist "Datengrab" und empfängt auch den ersten Backup in der Nacht. Diese beiden Pools hatten Fehler gezeigt, aber nur der Root-Pool verursachte die Panik und ist nun noch immer laut zdb nicht so ganz in Ordnung.

Code:
pit@Celsius ~:-# zpool status -v
  pool: Celsius
 state: ONLINE
  scan: scrub repaired 0B in 00:41:39 with 0 errors on Sun Apr 16 09:22:06 2023
config:

    NAME        STATE     READ WRITE CKSUM
    Celsius     ONLINE       0     0     0
      mirror-0  ONLINE       0     0     0
        ada0p2  ONLINE       0     0     0
        ada1p2  ONLINE       0     0     0
        ada2p2  ONLINE       0     0     0

errors: No known data error
Die Selbsttests mit smartctl liefern hier für keine SSD einen Fehler, beim zweiten Mirror gibt es für die neueste SSD einige Read-Fehler. Die erste SSD hat gerade 16000 Stunden auf dem Buckel und die letzte erst knapp 2600, also, die letzte ist die einzige, die Fehler notiert hat.

Im Augenblick bin ich froh und drücke die Daumen, dass alles funktioniert und ich kann mich derzeit nicht überwinden, überhaupt den PC mal neu zu starten, geschweige denn, etwas zu testen und zu probieren. Das große Heulen kann natürlich dann schon bald losgehen, aber mit ein wenig Glück schaffe ich noch meine anstehenden und anstrengenden Aufgaben damit zu bewältigen, ohne etwas zu verändern.
Bei SSDs brauchst dir keine Sorgen wg CMR oder SMR machen, das gibts nur bei "rotierendem Rost".

In manchen Foren kann man lesen, dass zfs und QLC SSDs ne schlechte Kombination sind, aber andere bestätigen wieder, dass die dem zfs durchaus gewachsen sind, wenn auch vielleicht mit geringerer TBW als TLC oder andere SSDs.

Meine Frage nach SMR rührte daher, weil in nem Dokument (ZFS on SMR, Novak, 2014, (d)) die Möglichkeit von ziemlich ähnlichen Fehlern beschrieben war (S 23, "ZFS may hiccup and perform some writes out of order...") - und zfs müsste da im Prinzip für SMR Platten ausgelegt werden; ob solcher Code in der Zwischenzeit in 2.0 eingepflegt wurde, weiß ich nicht, vllt wissen einige hier im Forum mehr darüber, ob zfs nun mit z.B. HA-SMR, HM-SMR und/oder DM-SMR besser umgehen kann bzw überhaupt von deren Feinheiten weiß, ob da Code dafür hinzugefügt wurde.

Aber da du SSDs einsetzt, ist die ganze Betrachtung diesbezgl. eh hinfällig.

Vllt sind da einfach nur Zellen wirklich schon kaputtgegangen (QLC sind da scheinbar eh anfälliger, besonders bei viel write-IO) und deswegen war der Pool auf einmal nicht mehr konsistent.

Da könnteste smartctl mal laufen lassen (smartctl -a /dev/ice) und folgende Werte auslesen:

5 Reallocated_Sector_Ct (den Wert hat allerdings nicht jede Samsung, der muss nicht vorhanden sein)
177 Wear_Leveling_Count
179 Used_Rsvd_Blk_Cnt_Tot
181 Program_Fail_Cnt_Total
182 Erase_Fail_Count_Total
183 Runtime_Bad_Block
187 Uncorrectable_Error_Cnt
 
Ich verwende in 2 großen Setups mit ZFS auch nur Q/MLC SSDs und hatte noch keien Probleme damit. In der Theorie müsste ZFS (bzw. jedes CoW) ja auch MLC in die Hände spielen, kann mir maximal ein extrem verkacktes Wearleveling in der Firmware vorstellen.

Aber ja, sowas müsste im smart aufscheinen.
 
Zumindest sollten der Reallocated Sector Count und ggf der Used Reserved Block Count hochzählen, aber bei Plattenfirmware würd mich nichts wundern, die Foren sind auch voll von "fw seems poorly programmed" bis "I think the device fw is crap" (nicht speziell auf Samsung bezogen) - die Firmware der Crucial MX500 Reihe scheint wohl auch von nem mittlerweile bekannten Bug betroffen, welcher wohl nach etlichen TRIMs auftritt;
Da muss ich gleich nochmal nachforschen, die hab ich selber im Einsatz - und bislang keine Probleme damit, die am meisten genutzte hat so 10.000-11.000 Stunden und etliche TBytes written drauf, wenn ich mich recht erinnere.

Hatte auch mal ne OCZ mit dem berüchtigten Sandforce Controllerchip, die war laut Smart super in Schuss, nur konnte die halt kein Byte mehr speichern, sämtl. counter waren aber gut.
 
Sandforce war wirklich ein besonders herausragender Haufen Scheiße. Aber die Zeiten sind ja zum Glück lange vorbei :D
 
177 Wear_Leveling_Count
179 Used_Rsvd_Blk_Cnt_Tot
181 Program_Fail_Cnt_Total
182 Erase_Fail_Count_Total
183 Runtime_Bad_Block
187 Uncorrectable_Error_Cnt
Code:
"ID","Name","Failed","Norm-ed value","Worst","Threshold","Raw value","Type","Flags"
5,"Reallocated Sector Count","never","100","100","10","0","<b>pre-failure</b>","PO--CK"
9,"Power-On Time","never","96","96","0","16.148","old age","-O--CK"
12,"Power Cycle Count","never","99","99","0","147","old age","-O--CK"
177,"Wear Leveling Count","never","97","97","0","27","<b>pre-failure</b>","PO--C-"
179,"Used Reserved Block Count (Total)","never","100","100","10","0","<b>pre-failure</b>","PO--C-"
181,"Program Fail Count","never","100","100","10","0","old age","-O--CK"
182,"Erase Fail Count","never","100","100","10","0","old age","-O--CK"
183,"Runtime Bad Blocks","never","100","100","10","0","<b>pre-failure</b>","PO--C-"
187,"Reported Uncorrectable","never","100","100","0","0","old age","-O--CK"
190,"Airflow Temperature","never","72","56","0","28","old age","-O--CK"
195,"Hardware ECC Recovered","never","200","200","0","0","old age","-O-RC-"
199,"CRC Error Count","never","100","100","0","0","old age","-OSRCK"
235,"POR Recovery Count","never","99","99","0","48","old age","-O--C-"
241,"Total LBAs Written","never","99","99","0","20.974.106.511","old age","-O--CK"

Ich nutze am liebsten gsmartcontrol, weil das eine schöne Darstellung hat und ich alle Tests auch über die GUI anwerfen kann. Die Ausgabe oben ist nahezu identisch für alle SSDs in allen Pools.
Nur im zweiten Pool, der also nicht betroffen ist, zeigt eine SSD (die jüngste) dies:
Code:
"ID","Name","Failed","Norm-ed value","Worst","Threshold","Raw value","Type","Flags"
5,"Reallocated Sector Count","never","97","97","10","31","<b>pre-failure</b>","PO--CK"
9,"Power-On Time","never","99","99","0","2.700","old age","-O--CK"
12,"Power Cycle Count","never","99","99","0","61","old age","-O--CK"
177,"Wear Leveling Count","never","99","99","0","4","<b>pre-failure</b>","PO--C-"
179,"Used Reserved Block Count (Total)","never","97","97","10","31","<b>pre-failure</b>","PO--C-"
181,"Program Fail Count","never","100","100","10","0","old age","-O--CK"
182,"Erase Fail Count","never","100","100","10","0","old age","-O--CK"
183,"Runtime Bad Blocks","never","97","97","10","31","<b>pre-failure</b>","PO--C-"
187,"Reported Uncorrectable","never","99","99","0","67","old age","-O--CK"
190,"Airflow Temperature","never","80","60","0","20","old age","-O--CK"
195,"Hardware ECC Recovered","never","199","199","0","67","old age","-O-RC-"
199,"CRC Error Count","never","100","100","0","0","old age","-OSRCK"
235,"POR Recovery Count","never","99","99","0","38","old age","-O--C-"
241,"Total LBAs Written","never","99","99","0","6.704.196.107","old age","-O--CK"
Weil das hier nicht so schön bunt gemalt ist, wie bei der GUI: die erste Zeile 5, "..." ist dort nämlich rot unterlegt und wenn man dann den Cursor hin führt, bekommt man sogar eine kurze Erklärung dazu. Ich finde diese GUI echt brauchbar, für Laien wie mich.

Ansonsten habe ich ja seit dem letzten erfolgreichen Boot nun eine Uptime von über zehn Tagen, bin aber mit meiner Arbeit noch nicht zur Hälfte durch und will deshalb auch derzeit nicht weiter testen und was ändern.
 
Weil das hier nicht so schön bunt gemalt ist
Das das nicht bunt gemalt ist, gut iss halt so. Das die "Formatierung" aber ähm suboptimal ist ... muss doch nicht sein.
Und egal ob smartctl oder GSmartControl, man erhält doch da per default ne schöne Textausgabe die man einfach nur Copypasten muss und fertig. Warum mutest Du uns da so ein "Zeichensalat" zu?
 
Das das nicht bunt gemalt ist, gut iss halt so. Das die "Formatierung" aber ähm suboptimal ist ... muss doch nicht sein.
Und egal ob smartctl oder GSmartControl, man erhält doch da per default ne schöne Textausgabe die man einfach nur Copypasten muss und fertig. Warum mutest Du uns da so ein "Zeichensalat" zu?
das ist natürlich die Ausgabe per cp_n_Paste eingefügt und weil ich derzeit nicht viel Zeit damit zubringen will, habe ich das nicht mehr umgebastelt. Vielleicht passt die Schrift der Ausgabe bei mir nicht. Es ist als root auf meinem Display gestartet und ich habe mich bisher nicht um roots Schriften gekümmert.

@pit234a - Ist da eine der Ausgabedaten von der fraglichen Disk, also die mit dem beim zdb Lauf angezeigten Error?
die erste Ausgabe ist quasi identisch für alle SSDs und dies war eine von drei im Mirror laufenden SSDs aus diesem Pool.
Auch die Tests geben da keine Fehlermeldung aus, bei keiner dieser SSDs.
 
das ist natürlich die Ausgabe per cp_n_Paste eingefügt und weil ich derzeit nicht viel Zeit damit zubringen will, habe ich das nicht mehr umgebastelt.
Du brauchst nix umbasteln. Der gibt eigentlich von sich aus schon ne ordentlich formatierte Ausgabe aus. Man muss eigentlich eher rumbasteln, damit es so verwurschtelt ist.
Daher bin ich ja so verwundert.

Vielleicht passt die Schrift der Ausgabe bei mir nicht.
Es ist ganz sicher kein Schriftproblem.
 
Code:
ID# ATTRIBUTE_NAME          FLAGS    VALUE WORST THRESH FAIL RAW_VALUE
  5 Reallocated_Sector_Ct   PO--CK   100   100   010    -    0
  9 Power_On_Hours          -O--CK   096   096   000    -    16148
 12 Power_Cycle_Count       -O--CK   099   099   000    -    146
177 Wear_Leveling_Count     PO--C-   097   097   000    -    27
179 Used_Rsvd_Blk_Cnt_Tot   PO--C-   100   100   010    -    0
181 Program_Fail_Cnt_Total  -O--CK   100   100   010    -    0
182 Erase_Fail_Count_Total  -O--CK   100   100   010    -    0
183 Runtime_Bad_Block       PO--C-   100   100   010    -    0
187 Uncorrectable_Error_Cnt -O--CK   100   100   000    -    0
190 Airflow_Temperature_Cel -O--CK   074   055   000    -    26
195 ECC_Error_Rate          -O-RC-   200   200   000    -    0
199 CRC_Error_Count         -OSRCK   100   100   000    -    0
235 POR_Recovery_Count      -O--C-   099   099   000    -    46
241 Total_LBAs_Written      -O--CK   099   099   000    -    20974274320
                            ||||||_ K auto-keep
                            |||||__ C event count
                            ||||___ R error rate
                            |||____ S speed/performance
                            ||_____ O updated online
                            |______ P prefailure warning
habe was gefunden, wie man sehen kann. Unter "View Output" gibt es eine andere Darstellung mit mehr Text auf einer Seite und daraus habe ich nun das von oben genommen.
Ob das zufällig die gleiche SSD ist, wie zuvor, weiß ich nicht.
Es ist auch eine aus dem Root-Pool und wie gesagt, sehen eigentlich alle SSDs gleich aus, außer einer in einem Daten-Pool.
 
2023.04.27-151721.jpg

tut zwar nichts zur Sache, aber aus diesen Fenster hatte ich den Text zuerst genommen und dies ist das Fenster der einen Platte aus dem Datenpool, die einen Fehler zeigt und bei der auch die Selbsttests Fehler zeigen.
 
die erste Ausgabe ist quasi identisch für alle SSDs und dies war eine von drei im Mirror laufenden SSDs aus diesem Pool.
Auch die Tests geben da keine Fehlermeldung aus, bei keiner dieser SSDs.
Lustig, dass genau die alle keinerlei Verschleiß/Probleme in den Countern anzeigen würden.
Steht hinten auf dem Typenschild ein Produktionsdatum der Platten? Bin mir nicht sicher, ob man das elektronisch auslesen kann.

Irgendwie erinnere ich mich noch schwach an nen Foreneintrag, dass 870 EVOs aus dem Produktionszeitraum um 2020 - 2021 - 2022 rum (kann mich nicht genau erinnern) fehlerhaft waren und "prone to errors". Ich schau mal, ob ich dazu noch was finde.

EDIT: Vergiß meine Aussage - du hast ja QVO, nicht EVO
 
Habs jetzt auf die schnelle nicht gefunden, aber deine Disk vom anderen Pool is ja EVO, ich such also weiter; ob die 1TB da auch betroffen waren, daran kann ich mich ausm Stegreif jetzt nicht mehr dran erinnern, ich meinte es waren nur die 2T/4T/8T, kann mich aber auch irren;

Wenn bei ner Samsung die Werte 179, 183 und 187 ansteigen, kann man von einem (sich anbahnenden) Defekt ausgehen;

Die Werte bei 195, 199 und 235 müssen nicht unbedingt eine schlechte SSD anzeigen, steigende Werte können da mehrere verschiedene Ursachen haben, z.B. Wackler in der Verkabelung, harte Power-offs etc.
 
Lustig, dass genau die alle keinerlei Verschleiß/Probleme in den Countern anzeigen würden.
Steht hinten auf dem Typenschild ein Produktionsdatum der Platten? Bin mir nicht sicher, ob man das elektronisch auslesen kann.


Das geht über die Seriennummer (wusst ich bislang selber nicht):

FYI if you want to know the manufacture date of your Samsung drive and can't be bothered removing it from the system -- you can figure it out by looking at the serial number:
Eighth number will tell you the year in hexadecimal:
N = 2020
R = 2021
T = 2022
Ninth number is the month
1=Jan
2=Feb, etc...

Quelle: Forenbeitrag


Irgendwie erinnere ich mich noch schwach an nen Foreneintrag, dass 870 EVOs aus dem Produktionszeitraum um 2020 - 2021 - 2022 rum (kann mich nicht genau erinnern) fehlerhaft waren und "prone to errors". Ich schau mal, ob ich dazu noch was finde.

Hier der entsprechende Foreneintrag welchen ich meinte (Aussage: "All drives made after 12/2020 are garbage") und hier der Thread-Anfang
 
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 war ja die Meldung zu meinem Problem-Pool, der auch der root-Pool dieses Systems ist und mit dem es die Panic gegeben hatte.

Meine Arbeit im Frühjahr ist vielfältig und findet nicht nur vor dem PC statt. Ich nenne das Arbeit und es ist Arbeit, aber die entsteht aus meinen diversen Hobbys, die aber nichts desto trotz sehr ernst für mich sind. Deshalb habe ich eben grad nicht viel Zeit, mich um PC-Probleme zu kümmern.

Als ich vorhin von meiner Arbeit auf den Feldern nach Hause kam, war es mal wieder so weit und der PC hatte gecrashed. Ich konnte also nicht sogleich meine unterbrochene PC-Sitzung wieder aufnehmen, sondern brauchte einen Neustart.

Während der letzten Tage hatte ich vermehrt auch Backups auf externe Medien gefahren und mich nicht nur auf die Sicherungen in der Nacht verlassen. Außerdem warf ich hin und wieder mal einen Scrub an. Es gab vereinzelte Meldungen hinsichtlich fehlerhafter Dateien mit Checksum-Errors, nach Scrub waren die aber verschwunden. Insgesamt arbeitete das System die letzten zehn Tage sehr gut durch.

Nach dem Neustart heute gab zpool status gar keine Fehler aus und auch zdb sah dann so aus:
Code:
root@Celsius ~:-# zdb -bc Celsius

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

loading concrete vdev 0, metaslab 115 of 116 ...
 368G completed (1472MB/s) estimated time remaining: 0hr 00min 00sec        leaked sp
ace: vdev 0, offset 0x700822be00, size 1536
block traversal size 395517827072 != alloc 395517828608 (leaked 1536)

        bp count:               7159771
        ganged count:                 0
        bp logical:        550432318464      avg:  76878
        bp physical:       394302113280      avg:  55071     compression:   1.40
        bp allocated:      395517827072      avg:  55241     compression:   1.39
        bp deduped:                   0    ref>1:      0   deduplication:   1.00
        Normal class:      395513733632     used: 40.04%
        Embedded log class        3321344     used:  0.04%

        additional, non-pointer bps of type 0:     419207
        Dittoed blocks on same vdev: 442157
also gleicher Pool wie zuvor, mein Root-Pool halt, direkt nach System-Start, aber noch auf der Konsole.
Nach Einloggen in X und Start meiner Standard-Anwendungen, Browser und Mail-Clienten, sah das dann zuerst so aus:
Code:
...
leaked space: vdev 0, offset 0xca3ee5ea00, size 6656
leaked space: vdev 0, offset 0xca3ef4a200, size 30720
leaked space: vdev 0, offset 0xca3ef57000, size 10240
leaked space: vdev 0, offset 0xca3ef61200, size 14848
leaked space: vdev 0, offset 0xca3f362000, size 11776
leaked space: vdev 0, offset 0xca3f636000, size 2560
leaked space: vdev 0, offset 0xca3f63fe00, size 7680
block traversal size 395382038528 != alloc 395545256448 (leaked 163217920)

    bp count:               7156473
    ganged count:                 0
    bp logical:        550200589312      avg:  76881
    bp physical:       394169773056      avg:  55078     compression:   1.40
    bp allocated:      395382038528      avg:  55248     compression:   1.39
    bp deduped:                   0    ref>1:      0   deduplication:   1.00
    Normal class:      395535304192     used: 40.04%
    Embedded log class        3358208     used:  0.04%

    additional, non-pointer bps of type 0:     419111
    Dittoed blocks on same vdev: 440995
also mit sehr viel "leak"
nun sind diese leaks wieder weg und es sieht fast genau aus, wie im ersten Code-Block:
Code:
pit@Celsius /home/pit:-# zdb -bc Celsius

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

loading concrete vdev 0, metaslab 115 of 116 ...
 368G completed (1306MB/s) estimated time remaining: 0hr 00min 00sec        leaked space: vdev 0, offset 0x700822be00, size 1536
block traversal size 395545660928 != alloc 395545662464 (leaked 1536)

    bp count:               7160990
    ganged count:                 0
    bp logical:        550479946752      avg:  76872
    bp physical:       394327937024      avg:  55066     compression:   1.40
    bp allocated:      395545660928      avg:  55236     compression:   1.39
    bp deduped:                   0    ref>1:      0   deduplication:   1.00
    Normal class:      395542321664     used: 40.04%
    Embedded log class        3333632     used:  0.04%

    additional, non-pointer bps of type 0:     419254
    Dittoed blocks on same vdev: 442722
das erwähne ich nun, weil ich mit diesen zdb-Kommandos einfach überfordert bin und nicht möchte, dass ich einen Aufhänger hier setze, der es womöglich gar nicht in sich hat.
Ist die Zeile
Code:
block traversal size 395545660928 != alloc 395545662464
das BÖSE?
Bei den anderen Pools gibt es weder leaks noch diese Zeile. Aber, das mit den leaks im Root-Pool sieht für mich nun auch nicht so konstant aus?
Können die entstehen, wenn während der Prüfung durch zdb gleichzeitig auf den Pool zugegriffen wird?
 
Ist die Zeile
Code:
block traversal size 395545660928 != alloc 395545662464
das BÖSE?

Ich bin nicht so tief in den zfs Interna drin, aber gesund schauts auf alle Fälle nicht aus.
Wie in nem Beitrag weiter oben von mir geschrieben - die zfs-Entwickler sehen das zfs.recover=1 als "last resort" an;

Meine Interpretation dessen ist: um den Pool zumindest noch ein (letztes) Mal hochzukriegen, und die Daten runterzuretten - und dann den Pool hernach neu zu machen.

Bei den anderen Pools gibt es weder leaks noch diese Zeile. Aber, das mit den leaks im Root-Pool sieht für mich nun auch nicht so konstant aus?
Können die entstehen, wenn während der Prüfung durch zdb gleichzeitig auf den Pool zugegriffen wird?

Das könnte sein, aber da zdb ja diesbezgl. definitiv die Möglichkeit eines "online" Laufs hat - und man den Pool nicht unbedingt offline nehmen muss - würd ich davon ausgehen, dass das dann korrekt im zdb-Lauf eingepflegt wird; wie gesagt reicht meine Kenntnis der Interna dazu jedoch nicht aus, hier eine verläßliche Aussage zu treffen.

Ich persönlich würde jetzt, wenn das meine Maschine wäre und ich die Zeit hätte, die Daten retten (machst ja eh regelmäßig wie du schriebst), den Pool löschen und neu erstellen - was allerdings halt auf eine Neuinstallation rausliefe, da das ja der root-Pool deiner Maschine ist.
 
Ich persönlich würde jetzt, wenn das meine Maschine wäre und ich die Zeit hätte, die Daten retten (machst ja eh regelmäßig wie du schriebst), den Pool löschen und neu erstellen - was allerdings halt auf eine Neuinstallation rausliefe, da das ja der root-Pool deiner Maschine ist.
metoo
aber ich zaudere dennoch.

Das ist vielleicht unvernünftig, aber weißt du, ich habe einen kräftigen Bauch und mich oft auf mein Bauchgefühl verlassen.
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.

Aber mit diesen unzuverlässigen Zusammenbrüchen auf Grund mangelhafter HW, will ich das nun nicht machen.
Es geht ja gerade (bis zum nächsten Crash) mal wieder alles einfach gut.
Am 16.05. muss ich meine letzte "Arbeit eingereicht" haben, um das mal so auszudrücken. Ich fühle mich nun irgendwie auf der Zielgeraden und obwohl meine Füße schmerzen und ich kaum noch Luft kriege, will ich da erst mal durch.

Dann sehen wir weiter...
 
Meine Arbeit im Frühjahr ist vielfältig und findet nicht nur vor dem PC statt. Ich nenne das Arbeit und es ist Arbeit, aber die entsteht aus meinen diversen Hobbys, die aber nichts desto trotz sehr ernst für mich sind. Deshalb habe ich eben grad nicht viel Zeit, mich um PC-Probleme zu kümmern.
Was willst Du damit sagen?
Das Du nicht willst das hier irgendwer noch was zu Deinem Problem schreibst, weil Du eh keine Zeit hast Dich drum zu kümmern? Das es manchmal länger mit antworten dauern kann, weil Du halt anderweitig viel eingespannt bist? Das Du ne Antwort haben willst die Dein Problem sofort und ohne Umschweife löst?
Oder das Du die Community einfach nur an Deinem Leben teilhaben lassen willst?

Können die entstehen, wenn während der Prüfung durch zdb gleichzeitig auf den Pool zugegriffen wird?
Also zumindest ist das keine gute Idee, weil sich der Poolstatus zwischendurch ja jederzeit ändern kann, weshalb zdb-Prüfungen verfälscht werden können.

Anyway. Mit dem Pool scheint etwas nicht in Ordnung zu sein. Ich würde mich meinem Vorredner anschließen und eher dazu tendieren die Daten zu retten und nen neuen Pool aufzubauen. Es droht sonst einfach nur, das sich die Fehler weiter aufschaukeln und gar nichts mehr geht.
Das macht natürlich dann am meisten Sinn, wenn man verlässliche Hardware hat sonst droht einfach, das der Kram wieder von vorne los geht.

Gerade weil offenbar nur ein überschaubares Zeitkontingent da ist, würde ich die Zeit nicht in irgendwelche fragwürdigen Frickeleien mit geringen Chancen auf guten Ausgang stecken.
 
Zurück
Oben