News Linux Kernel 6.7 mit BCacheFS: Updates für (i)GPUs von Nvidia und Intel, Itanium ist raus

[Steini1990]

Oh nein! Was machen jetzt die vielen Intel Itanium Besitzer? Die 2. Generation wurde ja sogar bis 2020 produziert.

 

[andy_m4]

Weil Du meintest, dass Linux nur wenig Dateisysteme unterstützt.

Nein. Genau das hab ich nicht gesagt (lies bitte meinen Beitrag nochmal sorgfältig). Wie kommst Du nur darauf?

 

[konkretor]

Die Itanium Systeme die ich die letzten 20 Jahre gesehen habe waren von HP und liefen mit HP UX

https://de.m.wikipedia.org/wiki/HP-UX

Habe nie einen mit Linux gesehen

 

[AGB-Leser]

Nein. Genau das hab ich nicht gesagt (lies bitte meinen Beitrag nochmal sorgfältig). Wie kommst Du nur darauf?

Genau hier steht das:

Ja. Weil Dateisystemmäßig ist Linux eher mittelmäßig aufgestellt. Man hat zwar einen ganzen Zoo von Dateisystemen. Aber so in der Liga der Großen hat man nur BTRFS, was so seit Jahren vor sich hin dümpelt und immer noch nicht so weit ist wie ZFS. Und ZFS selbst? Naja. Das ist halt auch schon ziemlich alt und hat ein paar unschöne Dinge drin, was auch dem geschuldet ist, das es das erste seiner Art war und man das heute nicht mehr so designen würde.

 

[sedot]

@AGB-Leser
Er schreibt von „einem ganzen Zoo“ und meint vermutlich „viel Auswahl“ – im Zoo gibts nicht nur zwei Tiere.

 

[AGB-Leser]

Womit er ja mich dann doch bestätigt hat. Das ist doch genau das, was ich geschrieben habe

 

[andy_m4]

Genau hier steht das:

Ja. Und Du hast es immer noch nicht (richtig) gelesen.
Ich schrieb von einem ganzen Zoo von Dateisystemen. Damit ist gemeint, das es unter Linux viele Dateisysteme gibt.
Es gibt/gab halt nur kein wirklich gutes in der Klasse BTRFS. Außer BTRFS selbst, was so lala ist. ZFS über Umwege, aber ZFS hat auch ein paar Probleme. Und bcachefs ist halt ein vielversprechender Kandidat/Ersatz in der Dateisystemkategorie.
Nirgends steht was davon, das Linux zu wenig Dateisysteme hätte/unterstützt.
Ich weiß auch nicht, wie ich es noch genauer erklären sollte. Erkläre Du mir doch mal bitte, wo es mit Deinem Verständnis hakt. Einfach nur den mein Geschriebenes zu zitieren bringt da ja nix.

 

[AGB-Leser]

Achso meinst Du das. Dann schreibe nächste mal, dass es auf dem Markt nur zwei CoW-Dateisysteme gibt. Der Rest ist ja was anderes. Das stimmt ja dann. Also klassischer Fall von Onlinediskussion.

 

[Haldi]

Das mit bCacheFS hört sich ganz interessant an.
btrfs hat ja immernoch probleme mit Raid5/6 ? und ZFS auf nem kleinen NAS mit 8GB RAM ist auch ein witz. Ansonsten noch der ganze lizenz kram mit Oracle.

Wobei allzuviel hab ich nicht verstanden vom FAQ und deren Homepage ^^
Glücklicherweise gibts dazu sonst im Internet noch mehr zu lesen:

Bcachefs is a next-generation CoW filesystem that aims to provide features from Btrfs and ZFS with a cleaner codebase, more stability, greater speed and a GPL-compatible license.
It is built upon Bcache and is mainly developed by Kent Overstreet.

Installation​

As of kernel 6.7 Bcachefs has been merged into the upstream Kernel so the linux-mainlineAUR kernel may be installed.
The Bcachefs userspace tools are available from bcachefs-tools.

Quelle: https://wiki.archlinux.org/title/Bcachefs


https://forum.endeavouros.com/t/my-testing-of-bcachefs/49607

 

[AGB-Leser]

ZFS auf nem kleinen NAS mit 8GB RAM ist auch ein witz.

Da reichen auch vier Gigabyte. Du musst diese Deduplizierung abschalten, dann reicht der Arbeitsspeicher. Ich habe ca dreißig Terabyte an Speicher und das lief am Anfang auch mit acht Gigabyte

 

[Pummeluff]

Wurde BTRFS nicht als Alternative zu zfs erschaffen, weil es da immer noch Lizenzprobleme gibt?

Hab ich anders in Erinnerung.

BTRFS wurde "irgendwie" aus dem Boden gestampft, als Reiser4 in Ungnade gefallen war. Dabei hatte BTRFS anfangs durchaus so einige konzeptionelle Probleme, die in Reiser4 schon gelöst waren.

Weil Dateisystemmäßig ist Linux eher mittelmäßig aufgestellt.

Mag durchaus sein. Bis auf die BSDs mit ZFS erscheint mir da aber auch kein OS, was besser aufgestellt wäre. Natürlich gibt's auch noch proprietäre Lösungen, wie WAFL bei der Netapp. Aber das spielt dann wohl eher thematisch in anderen Liga.

 

[andy_m4]

BTRFS wurde "irgendwie" aus dem Boden gestampft

Naja. btrfs hat schon starke Anleihen an ZFS genommen. Das ist kaum zu übersehen.

Und wegen Reiser4 und so. Das Ding bei ZFS war ja (neben Copy-on-Write), das die auch gleich ein Volume-Manager integriert haben.

Mag durchaus sein. Bis auf die BSDs mit ZFS erscheint mir da aber auch kein OS, was besser aufgestellt wäre.

So gesehen hast Du natürlich nicht ganz Unrecht.

 

[LEDs]

Ich dachte der GSP ist arm und es war nur eine Idee von NVidia den auf RISC-V umzustellen?

 

[AGB-Leser]

BTRFS wurde "irgendwie" aus dem Boden gestampft, als Reiser4 in Ungnade gefallen war. Dabei hatte BTRFS anfangs durchaus so einige konzeptionelle Probleme, die in Reiser4 schon gelöst waren.

Was ich bis heute nicht verstanden habe...

Ich dachte der GSP ist arm und es war nur eine Idee von NVidia den auf RISC-V umzustellen?

Die Architektur dahinter dürfte egal sein, wichtig ist, was das Teil macht. Und das weiß ich nicht

 

[Pummeluff]

Was ich bis heute nicht verstanden habe...

Was genau hattest du nicht verstanden?

Reiser4 hatte durch den Niedergang von Namesys keine Zukunft mehr. Als die Mordanklage gegen Hans kam, waren auch diverse Userspace-Tools noch nicht fertig.

Edward Shishkin, der damalige Chefentwickler bei Namesys, bekam anschließend (weiß nicht mehr von wem) den Auftrag zur Analyse von BTRFS, was in der Zeit um 2008 kurz nach der Finalisierung war und fand dabei konzeptionelle Designfehler.

 

[andy_m4]

Reiser4 hatte durch den Niedergang von Namesys keine Zukunft mehr. Als die Mordanklage gegen Hans kam, waren auch diverse Userspace-Tools noch nicht fertig.

Wobei, wenn man gewollt hätte, hätte man Reiser4 durchaus weiter betreiben können. Das wird ja immer als Argument für Open-Source hervorgetan. Das die "Pleite" einer Firma nicht mehr unbedingt die Folge hat, das das Produkt wegstirbt.

was in der Zeit um 2008 kurz nach der Finalisierung war und fand dabei konzeptionelle Designfehler.

Ja. Die "Linux-Commnuity" hat sich nicht gerade mit Ruhm bekleckert. Man wollte unbedingt so was wie ZFS und hat btrfs favorisiert, was aber Probleme hat die sich ja bis heute durchziehen. ZFS selbst haben die Lizenztaliban weggemobbt (auch wenn ZFS inzwischen durch ZoL bzw. OpenZFS ganz gut benutzbar ist). Mögliche Alternativen wie Reiser4 oder Tux3 nicht wirklich weiter verfolgt.

 

[Pummeluff]

Das wird ja immer als Argument für Open-Source hervorgetan.

Weiß nicht, unter welcher Lizenz damals Reiser4 stand. Mittlerweile ist GPL 2 hier angegeben. Open Source heißt ja noch lange nicht "frei".

ZFS selbst haben die Lizenztaliban weggemobbt

Im Normalfall würde ich Dir zustimmen. Aber wir reden hier von Oracle.

 

[andy_m4]

Weiß nicht, unter welcher Lizenz damals Reiser4 stand.

Gute Frage. Aber es wurde sich ja immer wieder drum bemüht es in den offiziellen Kernel aufzunehmen. Von daher gehe ich mal davon aus, das die Lizenz zumindest kompatibel war.
Müsste man mal anhand der damaligen Quelltexte nachvollziehen.

Im Normalfall würde ich Dir zustimmen. Aber wir reden hier von Oracle.

Als ZFS opensourced wurde, gehörte es ja noch zu Sun Microsystems.
Aber egal. Darum solls ja nicht gehen.
Wirklich problematisch kann ja die Lizenzfrage nicht sein, weil ZFSonLinux zeigt ja, das es geht. Und die haben sich ganz sicher damit auseinandergesetzt, weil die davon ihren Lebensunterhalt bestreiten und für die das Risiko besonders hoch ist, von Oracle weggeklagt zu werden. Die Kernel-Entwickler haben ein geringeres Risiko. Den könnte Oracle höchstens sagen: Nehmt den CDDL-Code wieder raus aus dem Kernel.
Und schon das ist unwahrscheinlich. Weil das mixen von CDDL-Code mit GPL-Code verstößt ja nicht primär gegen die CDDL, sondern gegen die GPL. Oracle hat dementsprechend ohnehin keine wirkliche Handhabe.

Warum man seinen Kram im Kernel haben will ist ja in der praktischen Auswirkung auch eher das Ding, das man möchte das das bei neuen Kernel-Versionen mitgezogen wird. Bisher hat man ja bei out-of-tree-Modulen das Problem, das wenn eine neue Kernel-Version raus kommt, die out-of-tree-Module anpassen muss.

Wenn man wollte, könnte man sich ja auf einen Kompromiss einigen. Das man aus Lizenzgründen OpenZFS nicht in das Linux-Repository merged, sondern das out-of-tree führt aber die Anpassungen trotzdem vornimmt.

Es ließen sich also schon Lösungen finden. Ist jetzt nicht so, das man auf der einen Seite die armen Kernel-Entwickler hat und auf der anderen Seite das böse Oracle-Sith-Imperium, was nur darauf wartet, das die Kernel-Jedi nen Fehler machen. :-)

 

[Pummeluff]

Aber es wurde sich ja immer wieder drum bemüht es in den offiziellen Kernel aufzunehmen. Von daher gehe ich mal davon aus, das die Lizenz zumindest kompatibel war.

Auch da muss ich wieder in meinen hintersten Gehirnecken nachkramen. Ist schon lang her.

Soweit ich mich noch erinnere, entsprach der Reiser4-Code nicht den Code-Richtlinien des Linux-Kernels. Um Reiser4 in den Standardkernel zu integrieren, hätten viele Code-Teile umgeschrieben werden müssen.

Aus dem Grund wurde der Reiser4-Code immer per Patch zur Verfügung gestellt. Bei jedem neuen Kernel musste man dann erst mal auf den Reiser-Gitrepos nachsehen, ob denn ein evtl. angepasster Patch schon zur Verfügung steht.

Auch nach dem Aus von Namesys stellte Edward noch lange zuverlässig die Patches zur Verfügung. Allerdings dauerte es bei einigen Versionen schon länger, bis der Patch verfügbar war. Ich glaub, ich hatte Reiser4 noch bis Kernel 3.8 in Verwendung. Danach wechselte ich zu btrfs.

Es ließen sich also schon Lösungen finden. Ist jetzt nicht so, das man auf der einen Seite die armen Kernel-Entwickler hat und auf der anderen Seite das böse Oracle-Sith-Imperium, was nur darauf wartet, das die Kernel-Jedi nen Fehler machen. :-)

Oracle hat in der Vergangenheit öfters gezeigt, dass sie ihre Lizenzbedingungen gern mal anpassen. ZFS-Betreffend ist das allerdings alles Spekuation. Linus Torvalds hat sich vor 4 Jahren gegen eine ZFS-Integration in den Kernel entschieden aufgrund der Lizenz.

Anmerkung zum eigentlichen Thema
Im Kernel 6.8 wurde im bcachefs-Code noch eine Menge optimiert. Scheint so, als hat der Reifeprozess gerade erst begonnen.

 

[andy_m4]

Soweit ich mich noch erinnere, entsprach der Reiser4-Code nicht den Code-Richtlinien des Linux-Kernels. Um Reiser4 in den Standardkernel zu integrieren, hätten viele Code-Teile umgeschrieben werden müssen.

Ja. So ist mir auch. Also zumindest eher als in die Richtung irgendwelcher Lizenzgründe.

Oracle hat in der Vergangenheit öfters gezeigt, dass sie ihre Lizenzbedingungen gern mal anpassen.

Das ist aber kein Problem. Denn der OpenZFS-Code kommt ja nicht von Oracle-Upstream, sondern ist ein eigenständiger Zweig für den man auch im nachhinein nicht mehr die Lizenz ändern kann.
Und selbst wenn der Upstream direkt bei Oracle liegen würde, könnten die die Lizenz auch nur für künftige Versionen ändern.
Insofern ist das eh kein Szenario, mit dem man sich befassen muss.

Linus Torvalds hat sich vor 4 Jahren gegen eine ZFS-Integration in den Kernel entschieden aufgrund der Lizenz.

Bei allem Respekt für Linus Torvalds. Der ist sicherlich ein guter Programmierer und Hardwarekenner und hat sicherlich auch ein gewisses Organisationstalent. Aber was rechtliche Fragen angeht, da würde ich jetzt nicht all zu viel Gewicht reinlegen.

Ich glaube ja, das Linus ZFS einfach nicht mag.
Man muss ja schon sagen, das ZFS eine recht eigene Welt mit eigenen Tools usw. ist. Zudem legt Torvalds viel Wert auf Simplizität (ZFS ist sehr komplex) und Effizienz (das Argument kam hier ja auch und das kennen wir schon aus Tagen der Diskussion mit Tanenbaum/MINIX).