FreeBSD 12.0 erschienen

[-Nuke-]

Darum gehts doch gar nicht.

Naja doch schon, nur ist die Situation hier genau anders herum. Hier ist der Linux-Kernel im Hintertreffen und müsste erst mal zum FreeBSD Kernel in dem Bereich aufschließen. Hat das FreeBSD aufgehalten? Ich glaube niemand hat sich bei den entsprechenden Features überhaupt nur annährend gefragt ob und wie das unter Linux implementierbar wäre. Damals ging es FreeBSD nur darum so schnell wie möglich ZFS zum Laufen zu kriegen, auch wenn man dabei den halben Kernel umbauen musste. Da hat auch keiner gefragt ob man vielleicht auch ZFS anpassen könnte, damit es auf weniger passenden Kerneln läuft.

Es ist meiner Meinung nach überhaupt auch gar nicht die Pflicht eines Kernels aufzupassen, ob die eigenen Treiber auch auf allen anderen Kerneln funktionieren würden. Dann kommt man nie voran, egal aus welcher Sicht. Linux bei Grafiktreibern nicht und FreeBSD bei ZFS nicht.

Die Diskussion kann von mir aus auch gerne raus getrennt werden, aber ich glaube die Standpunkte sind hier eh relativ fest, vermute ich

 

[bsfd]

Trotzdem, es wäre genial, wenn mehr darauf geachtet werden könnte das wichtige Teile/Elemente mit anderen Kernel leicht zu implementieren sind. Ich denke und hoffe auch, das die Zukunft in diese Richtung geht.
Die ferne Zukunft, ob wir das erleben ....

 

[schorsch_76]

Das Update meines Desktoprechners mit Pitcairn war nicht problemlos. Ich bin wieder auf 11.2 zurück.

Das Kernel Modul amdgpu meinte: set_scheduler not implemented: see your local kernal hacker". In den Releasenotes wird amdgpu für HD7000+ Karten empfohlen. (Pitcairn ist HD7000 Serie).

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234171

Thanks to zfs Rollback war kein Problem

Mit Hilfe von Upstream konnte ich es jetzt lösen!
https://github.com/FreeBSDDesktop/kms-drm/issues/116

Die Punkte waren:
a) Der alte .config Ordner musste gelöscht werden (zumindest bei Plasma5)
b) amdgpu driver und nicht mehr radeonkms.
c) Unter UEFI Boot: hw.syscons.disable=1 in loader.conf

 

[ralli]

Da sich FreeBSD 12 bei mir wegen des weiter oben beschriebenen Fehlers nicht installieren ließ, mußte ich mit FreeBSD 11.2 vorlieb nehmen. Heute nun wagte ich ein freebsd-upgrade. Das klappte ganz gut, aber nach dem Neustart hing er genau an der selben Stelle, wo schon der Installationsvorgang bei der Grundinstallation von FreeBSD 12 hing.

 

[Lance]

Hmm bzgl. ZFS hört sich das insgesamt beängstigend an. Gerade bei einem Dateisystem muss Stabilität und Fehlerfreiheit an erster Stelle stehen und ich fürchte das wird nicht so einfach gehen.
Mensch, lasst doch das ZoL Ding und bleibt bei "euerem" ZFS!

 

[Andy_m4]

Mensch, lasst doch das ZoL Ding und bleibt bei "euerem" ZFS!

Ich seh die ganze Sache etwas entspannter. Die FreeBSD-ZFS-Leute werden schon wissen, was sie tun. Zumal ja ZFSonLinux nicht 1:1 übernommen werden soll.

Letztlich ist ja auch die Frage: Was ist die Alternative?
Klar. Man könnte bei dem bleiben was man hat. Ob das aber langfristig ne gute Entscheidung ist, wage ich zu bezweifeln. Denn beim "Open-Solaris"-ZFS tut sich nicht mehr all zu viel. Man steht also vor der Frage, ob man das komplett selbst trägt. Ob da genügend Leute mit dem entsprechenden Know-How da sind ist fraglich.

Man droht vielleicht sogar den Anschluss an die ZFS-Entwicklung zu verlieren.

 

[Yamagi]

Man muss hier unterscheiden:

Einmal ist dort ZFS on Linux als Projekt, das ist grundsätzlich einfach eine OpenZFS Geschmacksrichtung. Am Anfang war es nur eine Geschmacksrichtung von mehreren, in den letzten Jahren hat sich ZFS on Linux aber immer mehr zum sozusagen inoffiziellen Haupt-Repo von OpenZFS entwickelt. Einfach weil nach und nach die meisten kommerziellen Firmen, welche sich an der OpenZFS-Entwicklung beteiligen, von Illumos als OpenZFS-Basis zu ZFS on Linux gewechselt sind. Der Wechsel von Delphix als mit Abstand größte beitragende Firma im letzten März war sozusagen der Todesstoß für Illumos, was alle anderen noch Illumos als Upstream nutzenden Projekte vor die Wahl stellt, ebenfalls das Schiff zu wechseln oder mit Illumos unterzugehen.

Dann ist dort ZFS on Linux als eine / die ZFS-Implementierung für Linux. Genauso wie ZFS unter FreeBSD spricht auch ZFS auf Linux nicht direkt mit dem Kernel, es befindet sich zwischen ZFS und dem Kernel ein Abstraktionslayer. Anders als unter FreeBSD oder Illumos hat ZFS auf Linux aber das Problem, dass sie nur eine Seite anpassen können. FreeBSD hat zum Beispiel extra für ZFS Änderungen an der virtellen Speicherverwaltung, am virtuellen Dateisystem, an GEOM und so weiter vorgenommen. ZFS für Linux kann das nicht, sie müssen sich mit dem zufriedengeben, was der Kernel ihnen bietet und wenn Kernelentwickler auf die Idee kommen die GPL-Keule rauszuholen und Schnittstellen sperren auch noch auf schlechtere Lösungen zurückgreifen. ZFS für Linux erreichte schon daher niemals die Stabilität wie ZFS für FreeBSD oder Illumos. Aber das ist eben nicht ZFS selbst, dass ist die Integration zwischen ZFS und dem Kernel.

FreeBSD will nun auch nicht ZFS on Linux ungesehen übernehmen. Es sollen die Features, die FreeBSD hat, aber bei ZFS on Linux fehlen, portiert werden und vor allem soll die Abstraktionsschicht zwischen ZFS und FreeBSD-Kernel Teil des ZFS on Linux Repos und Teil der ZFS on Linux Testinfrastruktur werden. Und das ist ein riesiger Schritt nach vorne, denn bisher werden Änderungen in ZFS auf Illumos händisch auf FreeBSD gemerged, wobei es immer wieder zu massiven Fehlern kommt. Aktuelles, sehr unschönes Beispiel war FreeBSD-EN-18:18.zfs [0]. Tatsächlich läuft die OpenZFS Testsuite mit FreeBSDs derzeitigem ZFS-Code nicht durch. Mit ZFS on Linux schon.

Nein, ich denke nicht, dass sich FreeBSD durch den Wechsel des Upstreams auf ZFS on Linux verschlechtert. Im Gegenteil, ZFS on Linux ist die reifere ZFS-Implementierung. Das größte Risiko sehe ich einem "Bitch-Move" von Oracle. Es ist schon mal diskutiert worden, ob Oracle sein ZFS nicht unter GPL und in Linux Mainline einbringen möchte. [1] Das würde wahrscheinlich dazu führen, dass einige OpenZFS-Entwickler ihre Arbeit ebenfalls auf GPL relizensieren und auf den Linux Mainline Zweig wechseln, OpenZFS als Ganzes darüber austrocknet und FreeBSD sowie Illumos in Folge dessen auf gut Deutsch gesagt am Arsch sind. Aber gegen dieses Szenario ist man sowieso wehrlos, es sei denn es findet sich genügend Manpower um einen eigenen ZFS-Zweig zu pflegen. Was nicht absehbar ist.

0: https://www.freebsd.org/security/advisories/FreeBSD-EN-18:18.zfs.asc
1:

Um diese Inhalte anzuzeigen, benötigen wir die Zustimmung zum Setzen von Drittanbieter-Cookies.
Für weitere Informationen siehe die Seite Verwendung von Cookies.

Drittanbieter-Cookies akzeptieren

Die Folien sind unter https://drive.google.com/file/d/0B_J4mRfoVJQRblFlalNmb0U3ZG9BS3A3VDRlUi1YRnVMNXow/view?usp=sharing

 

[foxit]

Ich habe im FreeBSD.org Forum ein paar Aussagen einen ZFS Entwicklers [1] gesehen:

As one of the ZoL developers, I must say that these remarks are rather hurtful. It is bad enough having to deal with this attitude from mainline Linux, but being accused of it is rather nasty.

I will admit that there was an instance where I complained about bashisms in the code and my complaints were overruled, but with FreeBSD support being added to the tree, getting those bashisms fixed will be fairly easy. That is trivial in comparison to the ZTS that was added long after those complaints, but Matt Macy is working on that and myself and others are available to him to answer questions and give advice.

Aside from those issues with some scripts, we make an effort to have platform independent code (to support as many Linux user lands as possible) and that effort will only become stronger after FreeBSD is added. While I do not maintain the test infrastructure, I expect that FreeBSD will be integrated into the buildbot such that anything that causes a regression on FreeBSD will prevent a patch from being merged. It is like this for all of the Linux distributions that are part of the builbot.

Anyway, I am thrilled to see the codebase being unified with the incoming addition of FreeBSD support to the repository. After FreeBSD is added, it will be easier to add Mac OS X, Windows, Illumos, FUSE, NetBSD, etcetera as targets, I am looking forward to that. Also, doing unification with FreeBSD’s ZFS driver will allow for the ZoL packaging to be reused for the FreeBSD kernel + FreeBSD userland on Gentoo when they are used in place of Linux and GNU. As the person responsible for the Gentoo ZFS packaging, I find that awesome,

Lastly, nothing prevents people from doing distribution specific stuff outside of the repository. Before someone points out the differences between FreeBSD and Linux distributions, I would like to state that BSD stands for the Berkeley Software Distribution. It would be best for everyone if we unified the codebase so that patches can go back and forth, but if we are moving too slowly at merging something, it need not block that from being in FreeBSD’s ZFS code.

The name ZFSOnLinux is for historical reasons and given that we can only build support for Linux at this time, the name is still appropriate. I imagine at some point it will be renamed to something more appropriate, but that discussion feels premature until the FreeBSD support is merged. That will likely happen after the 0.8 release. We would probably have the organizational things in place long before a name change is considered. As far as getting things done, what we call it for now is not very important though.

WRT license, I actually proposed a change a few days ago as part of an attempt to make peace with mainline, but that was a switch to a dual CDDL/GPL for the kernel code, with the assumption that we would somehow phase out or have alternative implementations of all of the Oracle owned kernel code over several years, subject to legal review and agreement among all of the OpenZFS developers (including those from FreeBSD).

Others have doubts that the plan would pass legal review and some suggested using a BSD/CDDL instead. Maintaining the original CDDL codebase in certain key locations would be a must for patent protection (especially on FreeBSD) and plenty of research would be needed to find out what those locations are. Unless the FreeBSD foundation can negotiate with Netapp and a few others for patent grants independent of the CDDL, the ZFS code on FreeBSD absolutely must remain under the CDDL to be covered by the agreement that Oracle made with Netapp.

Ich bin nach diesen Aussagen positiver eingestellt. Man ganz nüchtern betrachtet, hat man einfach auf den aktivsten ZFS Code gewechselt und möchte somit den Code für alle Platformen vereinheitlichen. Auch der Name soll später irgendwann geändert werden und man sieht, wie viel Politik (NetApp) noch dahinter steckt!

[1] https://forums.freebsd.org/threads/freebsd-moving-to-zfs-on-linux.68803/page-3

 

[Vril]

ryao said:
...
After FreeBSD is added, it will be easier to add Mac OS X, Windows, Illumos, FUSE, NetBSD, etcetera as targets...

Ein Stick mit ZFS, der auf FreeBSD und OSX r/w funtioniert - wäre natürlich irgendwann genial.
Denn OpenZFS on Mac ist ja auch noch recht holprig.
Spannend finde ich die Frage der Verschlüsselung ... Auf GEOM basiertes GELI wird auf anderen Systemen
ja immer verschlüsselt bleiben ;-)

 

[Yamagi]

Zu den Support-Zeiträumen:

Dear FreeBSD community,

In November, the FreeBSD Core Team announced that it was considering
changes to the support policy for the stable/12 branch.  After
discussions with different affected parties, it was determined that more
time is required for the community to adjust.  Thus, no major changes
will occur to the stable/12 branch; it will receive the same support as
stable/11 [1].  Any major support model changes [2] will apply to
stable/13 at the earliest, and those changes will be announced before
13.0-RELEASE.

FreeBSD Core Team

[1] https://www.freebsd.org/security/#model

[2] We are also considering updates to architecture tiers for
    stable/13. Any changes will be based on available usage data, survey
    results, and community discussions.

Es bleibt also (vorerst) alles so wie es ist. stable/12 wird mindestens 5 Jahre nach der Veröffentlichung des ersten Releases unterstützt werden, also bis Herbst 2023.