Folge dem Video um zu sehen, wie unsere Website als Web-App auf dem Startbildschirm installiert werden kann.
Anmerkung: Diese Funktion ist in einigen Browsern möglicherweise nicht verfügbar.
Ich hoffe immer noch, dass das mal jemand in freebsd-update einbaut. HardenedBSD hat das seit Jahren drin:Ganz einfach: Das sind Boot Environments. ZFS oder besser gesagt dasbectl
Tool (ist baugleich zubeadm
, aber seit einiger Zeit im Basisystem enthalten) klont das Dataset, auf dem / liegt. Anschließend wird das neue Dataset gemountet und das darin liegende System aktualisiert. Danach wird es aktiviert und man rebootet ins neue System.
hbsd-update -b <MeinNeuesBE>
macht all diese Schritte automatisch. Nach einem Neustart ist man automatisch im neuen Boot Environment <MeinNeuesBE>.Wie halt bei Solaris? :-)Ich hoffe immer noch, dass das mal jemand in freebsd-update einbaut. HardenedBSD hat das seit Jahren drin:hbsd-update -b <MeinNeuesBE>
macht all diese Schritte automatisch. Nach einem Neustart ist man automatisch im neuen Boot Environment <MeinNeuesBE>.
Das scheint mir aber ein gravierendes Problem zu sein. Zwischen OpenBSD (wo ich kaum Einfluss von Unternehmen vermute) und Linux (wo es sehr viel z.T. konkurrierende Unternehmen gibt), scheint mir "Core-Team winkt alles von einem Unternehmen durch" die schlechteste Lösung.Eigentlich ist es nur so zu erklären, dass Netgate den Kram um jeden Preis in 13.0 haben wollte und es wider besseren Wissens durchgepeitscht wurde. Auf FreeBSD-Seite wiederum keiner so genau hingeschaut, weil Netgates Beiträge bisher Hand und Fuß hatten, außerdem mehrere erfahrene Entwickler unten drunter standen.
Ja, das wünsche ich mir auch. Es gibt so viel gute Dinge, aber sie scheinen einfach nicht "verdrahtet" zu sein. Warum kann FreeBSD update nicht einfach das System hochziehen und mir beim nächsten Start im Bootloader einen Eintrag anzeigen [boot into last version].Ich hoffe immer noch, dass das mal jemand in freebsd-update einbaut. HardenedBSD hat das seit Jahren drin:hbsd-update -b <MeinNeuesBE>
macht all diese Schritte automatisch. Nach einem Neustart ist man automatisch im neuen Boot Environment <MeinNeuesBE>.
zfsnap
vor pkg upgrade
manuell aufzurufen.Man muss bei der Geschichte auch ein wenig differenzieren. Nämlich zwischen generellen 32-Bit-Support und überhaupt der Fähigkeit auf einem konkreten 32-Bit-Prozessor (wie halt der angesprochene 80386) zu laufen.i386 ist ja auch rausgeflogen aus FreeBSD 13
Der heise.de-Artikel deutet ja auch ein wenig an, das i386 nicht völlig auf Tier-2 abrutscht, sondern es eher so eine Art Tier-1,5-Support werden wird. :-)Nicht ganz weg, aber Tier 2
Ja. Im Prinzip können die sogar noch 16-Bit-Code ausführen (also MS-DOS und Co). Wobei bei solchen Sachen auch meist nicht die CPU das Problem ist, sondern das drum herum. So hat halt MS-DOS eben nicht die Treiber, die Du für moderne Hardware brauchst und solche Sachen.Soweit ich weis, sind doch alle neuen CPUs immer noch in der Lage i386 auszuführen.
ALLOW_MAKE_JOBS
ließ sich das System nicht tiefer in die Swap drücken, stattdessen gab der ARC den benötigten RAM innheralb von Mikrosekunden frei.Beim gemeinsamen Analysieren von Performanceproblemen im Zusammenhang mit ZFS (teilweise >10 Sekunden I/O-Stalls und ab an "Bad Filedescriptor" Fehler beim Öffnen von Dateien) in ##bsdforen.de haben wir festgestellt, dass es nicht mehr notwendig ist den ZFS ARC zu begrenzen. Es ist sogar sehr kontraproduktiv.
Auch wenn es ein Cache ist, ist der ARC aber ein integraler Bestandteil von ZFS. Vor allem werden alle Daten erst in den ARC gelesen, bevor sie an den Aufrufer gegeben werden. Und sie werden erst in den ARC kopiert und dann asynchron auf das Speichermedium geschrieben. ZFS braucht also eine gewisse Menge ARC, sowohl in Form von RAM, als auch virtuellen Speicheradressen. Als ZFS on FreeBSD (ZoF) vor weit über 10 Jahren begann, war FreeBSD/i386 mit seinem sehr begrenztem Adressraum aber noch weit verbreitet und auch auf FreeBSD/amd64 hatten viele Maschinen nicht mal 4 Gigabyte RAM. Daher wurde ZoF ARC die ersten Jahre stark darauf optimiert, auch mit sehr kleinen Größen gut klarzukommen, ohne die Performance zu verhageln. Umgekehrt war unter ZoF immer ein großes Problem, dass das Freigeben von Speicher träge war. Wenn bei unbegrenztem ARC eine große Speicheranforderung wie z.B. eine startende VM kam, wurde das System tief in die Swap gedrückt oder es schaute sogar der Out of Memory Killer vorbei. Daher wurde oft und auch von mir empfohlen, den ARC zu begrenzen.
Vor einiger Zeit hat Joyent den ARC für ZFS on Linux (ZoL) komplett überarbeitet. Als man die drei ZFS-Zweige von FreeBSD, Illumos und Linux zu OpenZFS mergte, übernahm man die ARC-Implementierung von ZoL. Die verhält sich deutlich anders als ZoF-Implementierung. Sie kommt augenscheinlich mit einem zu sehr begrenztem ARC nicht wirklich gut klar, aber sie kann Speicher äußerst schnell freigeben. Selbst bei größeren Poudriere-Builds wie llvm9, llvm10 und chromium mitALLOW_MAKE_JOBS
ließ sich das System nicht tiefer in die Swap drücken, stattdessen gab der ARC den benötigten RAM innheralb von Mikrosekunden frei.
Bei Problemen mit OpenZFS kann es also helfen die ARC-Begrenzung rauszunehmen.
kann mich dem voll anschliessen: FreeBSD ist weiterhin meine erste WahlAlso, nachdem @Yamagi das ja auch nochmal gut erklärt hat und wenn ich auf das Ergebnis und meine eigenen Erfahrungen blicke, fühle ich mich doch gerade wegen des Umgangs mit solchen Problemen bei FreeBSD besonders wohl!
Für mich kann ich sagen: so gehört das doch!
Ich kann es nicht 100% genau sagen, aber dem Versionsstand nach dürften 13.0 und der openzfs-Port für 12.2 größtenteils gleich sein. 13-STABLE ist inzwischen eine OpenZFS-Version voraus, aber das waren nur Kleinigkeiten.Wie verhält es sich derzeit mit ZoL/FreeBSD aus den Ports auf FreeBSD 12.2? Ist das vergleichbar zu 13.0 was Testabdeckung und Versionsstand betrifft? Ich bin ja immer eher Vorsichtig und warte meist auf die .1 Version beim Majorupgrade wenn ich nicht zwingend die neuen Features brauche.
Und wer keine Fehler macht, kann auch nicht aus seinen Fehlern lernen.Die Frage ist nur, wie damit umgegagnen wird![]()
Virtuell? Na da gibts doch die Sache mit QEMU:Etwas OT, aber hat jemand schon mal probiert, FreeBSD/arm64 auf Apples neuen M1 Rechnern virtuell zum Laufen zu bekommen?
So, es scheint soweit zu sein: FreeBSD 13 ist da und das Upgrade steht also demnächst an. Ich würde es nach dieser Prozedur "Upgrade FreeBSD with ZFS Boot Environments:" (gefunden bei Vermaden) vorgehen. Das entspricht der "Clone"-Variante, richtig?Danke Yamagi,
mit Teil 1 der Antwort wäre ich ja schon zufrieden gewesen (wie ich nach einem schief gelaufenen Update das rollback machen muss, such ich mir noch raus). Aber genau das war der Grund - und Experimentierfreude - ZFS zu probieren.
In Teil 2 werde ich mich auch mal in Ruhe einlesen (Vor- bzw. Nachteile von clone gegenüber snap). Wenn es zu wirr wird, melde ich mich nochmal.
Wir verwenden essentielle Cookies, damit diese Website funktioniert, und optionale Cookies, um den Komfort bei der Nutzung zu verbessern.
Siehe weitere Informationen und konfiguriere deine Einstellungen