Erfahrungen mit Upgrade von FreeBSD 13.2 auf 13.3?
- Ersteller mark05
- Erstellt am
turrican
Well-Known Member
bei mir liefs ohne Probleme durch, von 13.2 auf 13.3; bin nach dem üblichen Schema vorgegangen
bei den "freebsd-update install" Schritten wird automatisch ein Boot Environment erzeugt, du könntest also jederzeit zurück, auch auf das vorherige aktuelle BE
turrican
Well-Known Member
ZFS Magie machts möglich (Boot Environment)
ist quasi ne Art "Neuinstallation" - auf Basis der vorherigen... zu welcher du dank BE wieder rückkehren kannst (zumindest solang du kein "zpool upgrade" auf den root pool gemacht hast)
Es handelt sich hier ja nicht um ein Problem mit dem Design von ZFS oder der Filesystemstruktur. Soweit ich weiß wurde einfach an einer bestimmten Stelle, ein zusätzlicher Check eingeführt.
Macke1979
FreeBSD-User
Ich erstelle mir auch immer bei einem
pkg upgrade zunächst ein BE, in dem ich teste, ob alles wie gewünscht funktioniert und wenn dies der Fall ist, dann aktiviere ich dieses, behalte das alte BE aber noch eine Weile. Diese Funktion ist echt Gold wert. 
Ich weiß jetzt gerade ehrlich gesagt gar nicht, von welchem Bug genau die Rede ist.
dnode_is_dirty: check dnode and its data for dirtiness by robn · Pull Request #15571 · openzfs/zfs
Motivation and Context Closes #15526. Description Over its history this the dirty dnode test has been changed between checking for a dnodes being on os_dirty_dnodes (dn_dirty_link) and dn_dirty_rec...
github.com
Dieser spezielle Bug war doch völlig überschätzt. Er konnte auch deshalb so lange unentdeckt bleiben, weil es extrem unwahrscheinlich ist, dass man ihn in der Praxis trifft. Wer sich für die dreckigen Detail interessiert, kann sie hier nachlesen: https://despairlabs.com/blog/posts/2023-12-25-openzfs-data-corruption-bug/
Viel mehr nervt mich bei OpenZFS die grassierende Featureitis. Schon ZFS vorher, jetzt aber OpenZFS ganz speziell hat die unschöne Tendenz Features der Feature willen zu mergen, bevor sie wirklich fertig sind. Und wenn Dinge erstmal gemergt wurden, werden sie zu oft für die Entwickler uninteressant, weshalb sie ewig halbfertig bleiben. Das ging vor vielen Jahren mit Deduplication los, was nie benutzbar geworden ist, ewig als Schlangenölfeature mitgeschleift wurde und jetzt perspektivisch durch eine Reimplementierung ergänzt oder gleich ganz ersetzt werden soll. Und es endete bei Encryption, die ebenfalls in Teilen fragwürdig ist und wo man jetzt vielleicht sogar vor warnen will: https://github.com/openzfs/openzfs-docs/issues/494
Das alles trifft zugegeben in den meisten Fällen den Durchschnittsnutzer nicht, aber für mich ist ein Dateisystem eine binäre Sache. Entweder ein Feature ist vorhanden und funktioniert in allen Szenarien oder es gehört einfach nicht in den Hauptbranch. Oder sollte zumindest deutlich als experiementell gekenntzeichnet sein. Andernfalls muss man sich über verunsicherte Nutzer nicht wundern.
Viel mehr nervt mich bei OpenZFS die grassierende Featureitis. Schon ZFS vorher, jetzt aber OpenZFS ganz speziell hat die unschöne Tendenz Features der Feature willen zu mergen, bevor sie wirklich fertig sind. Und wenn Dinge erstmal gemergt wurden, werden sie zu oft für die Entwickler uninteressant, weshalb sie ewig halbfertig bleiben. Das ging vor vielen Jahren mit Deduplication los, was nie benutzbar geworden ist, ewig als Schlangenölfeature mitgeschleift wurde und jetzt perspektivisch durch eine Reimplementierung ergänzt oder gleich ganz ersetzt werden soll. Und es endete bei Encryption, die ebenfalls in Teilen fragwürdig ist und wo man jetzt vielleicht sogar vor warnen will: https://github.com/openzfs/openzfs-docs/issues/494
Das alles trifft zugegeben in den meisten Fällen den Durchschnittsnutzer nicht, aber für mich ist ein Dateisystem eine binäre Sache. Entweder ein Feature ist vorhanden und funktioniert in allen Szenarien oder es gehört einfach nicht in den Hauptbranch. Oder sollte zumindest deutlich als experiementell gekenntzeichnet sein. Andernfalls muss man sich über verunsicherte Nutzer nicht wundern.
Um fair zu sein: Mit den Änderungen an cp in den Linux Coreutils konnte das schon häufiger auftreten - so wurde es ja auch gefunden. Ist aber natürlich nur für Linux relevant, und die Enterprisedistors hats da auch nicht getroffen da die alte Versionen von den Coreutils verwenden.
Aber das war halt der einzig bestätigte relevante Bug der letzten Jahre.
Naja Dedup kam ja noch von Sun oder irre ich da und wurde das von ZoL neu gemacht? Und Sun hatte halt den Scale dicke fette Sun Server mit massig RAM.
Ad Encryption: Ich weiß ja nicht, das Feature ist seit 0.8 in ZFS und wurde sich auch von vielen gewünscht. Ich würde da erstmal nen Entwicklern vertrauen, wenn nicht, dürfte ich ZoL nicht verwenden. Die Entwickler haben sich das auch auch angesehen und sehen da wohl gerade keinen dringenden Handlungsbedarf. Auch hab ich bei vielen Ubuntu als OS gelesen, und Ubuntu macht eigenen Patches für ZoL - und dem Chaos beim aktuellem Datakorruption-Bug traue ich denen da überhaupt nichts mehr zu.
Ja, das kam von Sun. Aber damals war der Deal eigentlich noch schlechter als heute, weil RAM viel teurer als Festplatten oder inzwischen eben SSDs ist. Dedup in der Sun-Implementierung lohnte sich immer nur in sehr, sehr wenigen Anwendungsfällen.
Ich muss zugeben, dass ich das Thema nicht allzu intensiv verfolgt habe, da ich die native Verschlüsselung (noch) nicht nutze. Das mit Ubuntu ist definitiv ein Argument. Ich würde inzwischen dazu raten Ubuntu generell und Ubuntu Server speziell zu meiden.Die Distro hat sich wirklich nicht zum Guten entwickelt und macht zumindest bei mit - ich muss sie an einigen Stellen im Serverbetrieb einsetzen - teils erheblichen Ärger. Durch all die Ubuntu-Sonderlocken, aber auch durch Canonicals Unfähigkeit.
Ja, der Bug im ZFS ist gefixt. Dafür ist ein anderer drin, der zwar keine Datenkorruption verursacht, aber nervt.
Erfahrungen: auf meinem Desktop heult nach upgrade die ganze Zeit der Lüfter. Rechner läuft im Turbo-Mode und der Kernel rechnet eine Endlosschleife.
In den build-guests läßt sich gcc12 nicht mehr bauen - die Instanz crasht reproduzierbar immer mit pfault/OOM.
Eine ganze Anzahl Leute geraten an andere Probleme, die auf denselben Hintergrund zurückgehen, zB
forums.freebsd.org
forums.freebsd.org
Hintergrund ist PR 275594. Dort gibt es patches. Die funktionieren hier und bei anderen.
Warum 13.3 in dem Zustand ausgeliefert wurde, entzieht sich für mich der Nachvollziehbarkeit. Das wusste man vorher.
Erfahrungen: auf meinem Desktop heult nach upgrade die ganze Zeit der Lüfter. Rechner läuft im Turbo-Mode und der Kernel rechnet eine Endlosschleife.
In den build-guests läßt sich gcc12 nicht mehr bauen - die Instanz crasht reproduzierbar immer mit pfault/OOM.
Eine ganze Anzahl Leute geraten an andere Probleme, die auf denselben Hintergrund zurückgehen, zB
ZFS - disappointing ZFS(?) performance from 13.3
This morning I got to watch my 13.3 (ZFS zroot)desktop take 14 minutes to rsync about 21GB of data to a locally attached UFS disk with a steady 85%-88% CPU usage. Both parameters double last week's typical run. I have a BE to "fall back to" but this morning's boot gave the attached message prior...
Unresponsive system after upgrade to 13.3
Hi folks, I wonder if somebody else has the same issues. I've upgraded my laptop from 13.2 to 13.3. Upgraded all the packages. Having the problem with rsync almost completely locking up the system with near-100% system load. Starting it up via nice (with the default increment of 10) doesn't...
Hintergrund ist PR 275594. Dort gibt es patches. Die funktionieren hier und bei anderen.
Warum 13.3 in dem Zustand ausgeliefert wurde, entzieht sich für mich der Nachvollziehbarkeit. Das wusste man vorher.
Ich benutze das, es funktioniert.
Im prinzipiellen hast Du dennoch völlig recht. Dinge werden irgendwie entwickelt, proof-of-concept, dann über den Zaun geschmissen, eingebaut, und das wars dann. Nicht nur bei ZFS.
turrican
Well-Known Member
Potztausend!
Die Maschine bei mir (die von 13.2 -> 13.3 wie oben beschrieben) läuft eigentlich ganz gut - jetzt auf deinen Beitrag hin ein (großes) rsync ausprobiert...
Stillstand nach etlichen GBytes... bei rsyncs von wenigen MBytes bis ein - zwei GBytes fällts erstmal nicht auf, deswegen hatte ich das noch nicht als Problem erkannt.
Sogar die Drive-Activity-LEDs am HBA hören ganz auf zu blinken; Netzwerk ist tot/offline - an der lokalen Konsole ist die Maschine aber noch bedienbar
Muss ich gleich mal testen
auf die Schnelle die System-Disk des Rechners gegen ein Linux-Mint 21.3 ausgetauscht, die Pools importiert und - rsync der gleichen Daten vom gleichen Server ohne Probleme ... und schnellere Übertragung...
Da ist ein kernel thread "arc_prune" der ständig rotiert, und der dazuhin derweil alles mögliche andere sperrt.
Ist ein bischen verwickelt; da muss man sich ein git repo holen und daraus die ungefähr fünf neuesten commits extrahieren und auf /usr/src patchen - oder irgendwie anders, je nachdem wie man mit git zurechtkommt.
turrican
Well-Known Member
hab jetzt erstmal nur den Teil mit dem Flag arc_prune_running im File arc_os.c aus D44170 / Diff 135270 eingepatcht
mit dieser Änderung kann ich zumindest die Testdaten erfolgreich per rsync übertragen, welche die Maschine gestern nach kurzer Zeit vom Netz nahmen, die Maschine bleibt die ganze Zeit über online verfügbar und bedienbar, Übertragungsgeschwindigkeit passt auch einigermaßen
weitere Tests stehen aus, aber da komm ich heut und morgen vermutlich erstmal nicht dazu