ZFS 2.1.8 evtl ein Bug?

[Bohnenhans]

Auch wenn ich nicht abschätzen kann wie häufig das auftritt und unter welchen Vorausetzugen evtl trotzdem interessant für andere ZFS Nutzer.

Mein Mainserver mit ZFS 2.1.8 (also Build aus dem GITHub) hat sich gestern das verschlüsselte SubVolume verabschiedet. Der unverschlüsselte Teil ist weiterhin da allerdings stürzt das ZFS Modul mit Exception beim z.B. unmounten ab - und zwar reproduzierbar immer. RAM etc ist alles OK. Es wurden auch kien updates duchgef+rt - das war einfach mitten im Videoschauen.

Obwohl ich 2.1.8 schon eine "Weile" - halt seit es das gibt - im Einsatz habe. Interessant war dass scrub keine Fehler fand und 1 Verzeichnis mit 10 Datien noch da war im verschlüsselten Teil - von was weiss ich sicher > 100.000 xD

Irgendwo scheint da wohl ein Bug drin zu sein, der in meiner Konstellation auftrat - aktuell kopiere ich den Backupserver (FreebSD mit ZFS "Stock" auch RAIDZ3) halt wieder zurück, was natürlich ein paar Tage dauert.

Mein Konstellation ist FreeBSD 13.1 (ECC-RAM, RaidZ3)

2.1.8 lasse ich also mal aus - FreeBSD 13.2. setzt ja eh dann wohl auf 2.1.9

 

[kieleich]

wenn du Kernel Panics hast ... dann entweder Bug im Kernel (- Modul) oder direkt kaputte RAM CPU usw.

auch ECC RAM kann kaputt werden und muss man testen

gerade bei Free BSD wo das ZFS seit Jahren standard ist und nicht so dazu gebastel Linzenz Ärger wie bei Linux ist das aber sehr schräg. Da gehst du am besten mal die entsprechenden Mailing Listen abklopfen denn wenn es hier Probleme gibt bist du sicher nicht alleine damit?!

Ps: falls du mit build aus github eigene compile meinst kann auch da ein fehler her kommen

 

[Bohnenhans]

ECC RAM tut problemlos sind auch keine Einträge im SPMI.

Die Kernel panics haben ausschliesslich das ZFS Kernel Modul als Ausgangspunkt und zwar reproduzierbar - und es waren ja noch Daten da - nur halt vielleicht 0,01% von denen die ein paar Sekunden vorher da waren

Naja es ist halt evtl eine Kombination von RAIDZ3-Level, der Anzahl HDDs, der Datenmenge Crypt oder sonstwas in der Konstellation - kann ich halt nicht abschätzen.

Meinte ja nur weil das ist bei mir der erste Compile aus Github der halt nach ein paar Wochen Probleme gemacht hat - vielleicht interessant für jemand der eben auch immer auf einem System die aktuellen Sourcen nutzt - die halt einfach auch viele Bugfixes enthalten.

 

[kieleich]

Compilefehler kannst du ausschließen (make clean vergessen udgl). Du hast schon ein Tag/Release genommen und nicht einfach master? Blöde fragen ja ich weiss.

Bei einem Dateisystem das man ja extra benutzt um keine Daten zu verlieren (alles wird bis auf den kleinsten Bit Fehler geprüft) dann alles zu verlieren ist natürlich übel

man hat den Eindruck das bei ZFS mehr Daten verloren werden als bei traditionell Dateisystemen

 

[Bohnenhans]

Ich habe die ZFS Module seit 3 Wochen auf dem System im Einsatz - ich nutze die immer 1 Woche nach "release" - falls mal ein ganz grober Fehler drin ist der viele betrifft ist der sicher gefixt - also auch schon 1x einen Scrub drüberlaufen lassen.

Schlimm ist es auch nicht für mich, ist halt nur dass die Zeit bis der restore durch halt etwas länger dauert weil ich natürlich alles neu aufgesetzt habe. Hatte natürlich die 2.1.5,6,7 und 8 Features aktiviert auf den ZFS Volumes

 

[andy_m4]

Die Kernel panics haben ausschliesslich das ZFS Kernel Modul als Ausgangspunkt und zwar reproduzierbar

Gut wäre natürlich zu wissen, wie der "Panic" genau aussah.
Hast Du möglicherweise sogar in Crashdump, wo man mal reingucken könnte?

2.1.8 lasse ich also mal aus

Ja. Es gibt eigentlich keinen gute Grund nicht das ZFS aus Base zu nehmen außer man braucht zwingend ein Feature aus einer aktuelleren OpenZFS Version.

ZFS 2.1.8 (also Build aus dem GITHub)

Was bedeutet das konkret?
Du meinst von https://github.com/openzfs/zfs ?
Kann man im Prinzip machen. Ich würde aber wenn dann via Port Konfigurieren/installieren.

man hat den Eindruck das bei ZFS mehr Daten verloren werden als bei traditionell Dateisystemen

Du meinst das Unix File System? :-)

 

[Bohnenhans]

Hehe ne hab leider dummerweise den Crash Dump nicht aufgehoben habe nuir ein paar mal probiert ob der immer kommt und sich reproduzieren lässt und hab einen scrub 4h laufen lassen um zu sehen ob der was findet.

Naja die Liste der Bugfixes ist schon immer noch echt lang in den Versionen - so ganz sinnlos ist das updaten ja nicht - es gibt keine Backports durch FreeBSD etc selber. Wenn man z.B. alle "echten" Bugfixes seit 2.1.2 (auf der ist mein BackuServer mit der "Original" ZFS Version von 13 FreeBSD) bis 2.1.9 zusammennimmt das ist schon ne relativ lange Liste.

Nächste Woche werden die Server mit jeweils einer weiteren HDD erweitert daher wollte ich die vorher wieder beide in einem stabilen Zustand haben - dachte das würde deutlich länger dauern, aber ist wohl schon morgen fertig.

Zumindest spare ich mir dann auf dem Backupserver das scrub - schliesslich werden jetzt alle Daten gelesen

 

[foofoobar]

gerade bei Free BSD wo das ZFS seit Jahren standard ist und nicht so dazu gebastel Linzenz Ärger wie bei Linux ist das aber sehr schräg. Da gehst du am besten mal die entsprechenden Mailing Listen abklopfen denn wenn es hier Probleme gibt bist du sicher nicht alleine damit?!

ZFS-upstream ist doch schon seit ein paar Jahren auf Linux?

 

[andy_m4]

Naja die Liste der Bugfixes ist schon immer noch echt lang in den Versionen - so ganz sinnlos ist das updaten ja nicht

Kommt ja auch immer darauf an, wie kritisch ein Bug tatsächlich ist.

2.1.2 (auf der ist mein BackuServer mit der "Original" ZFS Version von 13 FreeBSD

Ich bin mir ziemlich sicher, das zu FreeBSD 13.1
OpenZFS 2.1.4 mit geliefert wird.
Dort gabs übrigens zwischendurch auch mal Patches für. So von wegen "da wird nix geupdatet" und so.

Anyway. Jetzt ist immer noch nicht klar, wie Du OpenZFS denn nu installiert hast.

ZFS-upstream ist doch schon seit ein paar Jahren auf Linux?

Jaein. So kann man das nicht direkt sagen. Der Upstream ist eigentlich systemunabhängig.
Was Du vermutlich meinst ist ZFSonLinux, was dann in dem OpenZFS-Projekt aufgegangen ist.

 

[Bohnenhans]

Mein Backupserver ist noch auf 13.0 das meinte ich mit 13 der Backupsystem läuft eigentlich nie auf dem gleichen Stand wie mein Hauptsystem sondern meist auf der Vorgängerversion.

Auf Linux hatte ich vor ein paar Wochen noch den Bug dass mysql Datenbanken nicht liefen. auf ZFS also den hier "https://github.com/openzfs/zfs/issues/13329" fand ich auch etwas strange

Ich finde ZFS immer noch super aber es hat halt schon hier und da noch ein paar Überraschungen.

Na ich installiere halt Open ZFS indem ich mir den master Branch von Github ziehe compiliere und installiere . ausser halt auf dem Backupsystem, das läuft halt nur mit Systemupdates.

-------------------------

Nachtrag Montag 9 Uhr: So Restore ist nach 26h fehlerfrei (wie erwartet) durch - dann warte ich mal auf 2.1.9 bevor ich wieder upgrade

 

[andy_m4]

Mein Backupserver ist noch auf 13.0

FreeBSD 13.0 hat in Base OpenZFS 2.0.0
Also auch da passt ja die Angabe offenbar nicht.
Außerdem ist FreeBSD 13.0 seit einem halben Jahr out-of-support.
Verstehe ich übrigens auch nicht. Auf der einen Seite jammerst Du rum wegen jedem Fitzelbug und willst da zeitnahe Fixes. Auf der anderen Seite betreibst Du dann aber abgelaufene Systeme. :-)

Auf Linux hatte ich vor ein paar Wochen noch den Bug dass mysql Datenbanken nicht liefen. auf ZFS also den hier "https://github.com/openzfs/zfs/issues/13329" fand ich auch etwas strange

Habs nur überflogen, aber wenn ichs richtig verstanden hab ist das ein Linux-spezifisches Problem.

Na ich installiere halt Open ZFS indem ich mir den master Branch von Github ziehe compiliere und installiere

Wieso nimmst Du nicht einfach den Port bzw. das Package?
Wie stellst Du sicher, das nicht versehentlich Dein Kompilat und das in FreeBSD enthaltene ZFS-Zeugs gemixt werden. Aus meiner Sicht holst Du Dir da ohne Not potentiell Probleme rein. Und das letztlich um ein Bug zu "fixen", der für FreeBSD gar nicht relevant ist.

Jetzt mal so ganz generell:
Meiner Erfahrung nach ist es ne gute Idee den Kram default-mäßig zu betreiben. Die Leute, die sich darum kümmern, wissen nämlich im Zweifel darüber besser Bescheid als ich. Außerdem ist es auch das Szenario, was die meisten fahren. Das heißt, wenn ein Szenario auf Probleme abgeklopft ist, dann dies. Davon abzuweichen bedeutet immer, das man Gefahr läuft sich einen unbekannten Bug einzufangen.
Davon abweichen sollte man nur, wenn es einen spezifischen Grund gibt und man dann auch einigermaßen weiß, was man tut.

 

[Bohnenhans]

Es gibt keine eigenen ZFS FreeBSD Branch mehr auch "FreeBSD" erzeugt seit es OpenZFS gibt seinen Module doch aus ganz genau den gleichen Quellen.

Als es früher noch einen eigenen FreeBSD Branch gab war das natürlich das was ich genommen habe.

Viele im ZFS Code enthaltenen Bugs sind auch FreeBSD relevant - ausser eben wenn es um betriebssystemspezifische Funktionen geht, das sind aber doch vergleichhsweise wenige das macht sicher nur einen sehr kleinen Teil des Codes aus.
Wenn man den gleichen Sourecode nimmt aus dem auch das OS sien Module erzeugt ist die Gefahr dass man sich Probleme überschaubar minimal.

E sind halt auch immer wieder grössere Probleme nicht gefixt und offen in OpenZFS und viele davon betreffen auch FreeBSD, weil die eben auch genau diesen Branch nutzen.

https://github.com/openzfs/zfs/issues

 

[andy_m4]

Es gibt keine eigenen ZFS FreeBSD Branch mehr

Das ist mir bewusst.

FreeBSD" erzeugt seit es OpenZFS gibt seinen Module doch aus ganz genau den gleichen Quellen.

Ja. Ich hab nix gegenteiliges behauptet.

Viele im ZFS Code enthaltenen Bugs sind auch FreeBSD relevant

Auch hier hab ich nicht das Gegenteil behauptet.
Vielleicht solltest Du mal eher auf das eingehen, was ich sage anstatt daran vorbei zu reden.

 

[Bohnenhans]

Wieso nimmst Du nicht einfach den Port bzw. das Package?
eWie stellst Du sicher, das nicht versehentlich Dein Kompilat und das in FreeBSD enthaltene ZFS-Zeugs gemixt werden. Aus meiner Sicht holst Du Dir da ohne Not potentiell Probleme rein. Und das letztlich um ein Bug zu "fixen", der für FreeBSD gar nicht relevant ist.

----

Öh indem ich die gleichen Source-Branch und Compiler nutze mit dem auch FreeBSD selber compiliert.

Auch die ziehen einfach nur die Sourcen von OpenZFS und compilieren dann, den nur dort findet die FreeBSD ZFS Entwicklung noch statt.

Meine Module sind eben nur aktueller als die von FreeBSD das ist alles.

 

[andy_m4]

Öh indem ich die gleichen Source-Branch und Compiler nutze mit dem auch FeeesBSD selber compiliert.

Du hättest auch einfach mal die Schritte hinschreiben können. Dann müssten wir nicht rätseln, was Du meinst.
Und die Frage danach, warum Du nicht einfach den Port nutzt ist immer noch nicht beantwortet. Wie Du den versehentlichen Mix verhinderst auch nicht.
Ist ja kein Problem, wenn Du nicht antworten willst. Ist ja ganz Deine Sache. Aber wenn, dann gehe das doch bitte mit einer gewissen Ernsthaftigkeit an. Sonst bringt es ja nichts und ist für alle Seiten nur Zeitverschwendung.

Wie sollte denn FreeBSD was anderes compilieren können als ich?

Die Schritte beim Port sind halt automatisiert. Man kann nicht versehentlich ne Kleinigkeit vergessen.

Ist ja auch egal. Mich hatte es ja auch nur interessiert, ob es evtl. spezifische Gründe gibt oder so. Weil ich immer neugierig bin und da dann auch immer die Chance besteht, das ich für mich etwas dazu lernen kann.
Inzwischen kristallisiert sich so ein bisschen raus, das Du es nur so machst aus nem Gefühl heraus (Neuer ist besser). Kann man machen. Ich will das auch gar nicht verurteilen oder so. Ist aber für mich und den Erkenntnisgewinn nicht wirklich spannend.

 

[Bohnenhans]

Naja Ich habe doch in #3 geschrieben dass ich die Sourcen von Github nehme da gibt es nur ein Repository für Linux / FreeBSD - aber gut hätte man sicher ausführlicher scheiben können.

Vergessen kann man nichts wirklch das baut aufeinander auf - vergisst man einen Schritt kann man halt den nächsten nicht ausführen. Zumal man das eh wenn man das mehr als 2x macht als Script automatisiert xD

Nun ich sage mir ich habe einen Fix lieber heute sicher als irgendwann oder nie.

Aktuell offene Bugs ("Defect") - also noch ungeklärte Ursache (bei geklärt und/oder gefixes ändert sich der Status auf "closed") - gibt es halt noch aktuell knapp 500 die von nur Performance bis zu möglichem Data Loss gehen.

https://github.com/openzfs/zfs/issues?q=ispen+is:issue+label:"Type:+Defect"

Deshalb habe ich ja auch alle Server doppelt - einer auf den OS Package Stand (im Normalfall das Backupsystem) einen auf dem aktuellestem Stand das naja "Home-Produktivsystem" - dass ein OS/FS etc Fehler bei beiden System zuschlägt ist eben damit deutlich unwahrscheinlicher. Beide Systeme auf dem exakt gleichen Stand zu halten halte ich für wenig sinnvoll, weil man mögliche System-Fehler dann halt einfach eher doppelt hat.

Und natürlich auch Backups, allerdings halt nur von den wirklich wichtigen Daten


Da der gerade läuft habe ich mal nachgeshaut mein 13.0 hat 2.1.2 selbst compilierte sind 2.1.99-[UniqueID] das also zumindest für -p4 die Systemversion.

 

[foofoobar]

Jetzt mal so ganz generell:
Meiner Erfahrung nach ist es ne gute Idee den Kram default-mäßig zu betreiben. Die Leute, die sich darum kümmern, wissen nämlich im Zweifel darüber besser Bescheid als ich. Außerdem ist es auch das Szenario, was die meisten fahren.

Tester die sich Daten schreddern lassen braucht es auch.

 

[Bohnenhans]

Das sind ja die released Versionen und keine "Daily Snapshots"

Ich hab jetzt in > 15 Jahren ZFS Nutzung dadurch 1x einen Restore machen müssen obwohl ich schon viele Jahre compiliere - auch auf ARM - das denke ich echt ok.

Und ein "Restore" geht ja wie ich gerade festgestellt habe echt recht fix

Ohne Backupsystem würde ich das wohl nicht machen.

 

[andy_m4]

aber gut hätte man sicher ausführlicher scheiben können.

Wie gesagt. Wenn Du nix dazu schreiben willst, ist das ok. Aber dann belasse es doch auch dabei, statt Ausreden zu suchen.

vergisst man einen Schritt kann man halt den nächsten nicht ausführen

Falsch. Aber hey. Du willst ja nicht drüber reden also sag ich auch nichts mehr dazu.

Aktuell offene Bugs ("Defect") - also noch ungeklärte Ursache

Ja und nu?
Es gibt immer offene Bugs mit ungeklärter Ursache. Und ein Haufen Bugs die noch gar nicht gefunden sind.
Wenns danach geht, dürftest Du die Software gar nicht einsetzen.
Außerdem passt das nicht zu dem, das Du alte Out-of-Support-Software einsetzt.
Du bist also nicht mal in Deiner eigenen Rule konsequent.

Beide Systeme auf dem exakt gleichen Stand zu halten halte ich für wenig sinnvoll, weil man mögliche System-Fehler dann halt einfach eher doppelt hat.

Na erstens kann man Backups noch anders machen als einfach nur das Dateisystem zu spiegeln. Zweitens kannst Du ja dennoch Unterschied reinbringen.
In dem Du einmal das ZFS aus Base nimmst und einmal das aus den Ports. Oder Du benutzt den 12er Zweig der ja immer noch aktiv gepflegt wird oder oder oder.

Ist mir auch letztlich wurscht wie Du es machst. Ich weise ja nur darauf hin, das so wie es sich jetzt darstellt, es widersprüchlich ist.

Tester die sich Daten schreddern lassen braucht es auch.

Ja. Unbedingt. :-)
Aus der Perspektive betrachtet hast Du natürlich Recht.
Ich mach das ja auch öfter mal. Also von den Standardwegen abweichen. Gerade um auch mal Dinge zu probieren oder optimieren.
Nur wenn dann ein Problem auftritt, dann bin ich auch interessiert daran zu wissen, worans liegt und versuche in einen konstruktiven Austausch zu gehen. Und geize nicht unnötigerweise mit Informationen.

 

[foofoobar]

Nur wenn dann ein Problem auftritt, dann bin ich auch interessiert daran zu wissen, worans liegt und versuche in einen konstruktiven Austausch zu gehen. Und geize nicht unnötigerweise mit Informationen.

Dann solltest du die Crashdumps den Entwicklern zur Verfügung stellen und deine Kiste auch so konfigurieren das du auch jederzeit Crashdumps auslösen kannst. Ich denke die Entwickler werden dafür dankbar sein.