Klingt wenig vertrauensvoll

[/mecki78]

ZFS hat das einfachste Nutzerinterface aller Dateisystem, die ich kenne, und bietet alle Features, die man von einem modernen Dateisystem erwartet. Es hat nur drei "Probleme":

1. Es ist nicht Teil des Linux Kernels, was aber nur an der Lizenz liegt, da nicht GPL. Einmal insalliert funktioniert es aber super unter Linux.

2. Es kotet viel Ressourcen, da es nicht als Consumerdateisystem ausgelegt ist, sondern als Serverdateisystem für große Filecluster.

3. Es ist nicht das schnellste Dateisystem, da es auf kleinen Servern bzw. Endnutzerrechnern seine eigentlichen Performancevorteile nicht wirklich ausspielen kann.

Ich wünschte, es gäbe so etwas wie ZFS-light unter GPL, das Teil des Linux Kernels ist und auf in Sachen Geschwindigkeit und Ressourcenverbrauch auf kleine Systeme hin optimiert ist, das aber ansonsten das gleiche Nutzerinterface und die gleichen Nutzerkonzepte hätte.

Btrfs ist es sicher nicht. Das Interface ist grausam, das FS bis heute buggy and nicht feature-complete; und bei Performance und Ressourcenverbrauch schneidet man zwar leicht besser ab, aber auch nicht wirklich gut. Außerdem unterstützt Btrfs gerade mal zwei Plattformen, ZFS unterstützt 5 und diverse Untervarianten (eigentlich jedes moderne Desktop/Server System).

Bcachefs soll anscheinend diese Lücke füllen, aber würde gar nichts außer Linux unterstützen und selbst dort scheint es eben den halben Kernel umbauen zu müssen, was aus meiner Sicht klingt, als hätte man hier was zusammengehackt, was nicht nach einem überzeugenen Konzept klingt.

/Mecki

[Firebat]

Bcachefs nutzt das schon ewig im Linux-Kernel vorhandene bcache und baut es zum Dateisystem aus. Wenn man die Entwicklung in den letzten Jahren verfolgt hat, hat sich Kent Overstreet schon einige Gedanken gemacht.

Man könnte die Argumentation "umdrehen": alle bisher im Linux-Kernel vorhandenen Dateisysteme haben Schwächen, bcachefs versucht, diese Schwächen auszumerzen. Dafür sind Umbauarbeiten erforderlich, weil es die genutzen Funktionen bisher so nicht gibt. Ich empfehle, einfach mal die Patreon-Seite anzuschauen und gerade auch die unregelmäßigen Blogbeiträge dort. Er weiß definitiv, wovon er redet.

Wobei ich ganz klar sagen muss, ich bin "Pro-Bcachefs". Einfach, weil es ein GPL-lizenziertes Filesystem geben muss, was mit ZFS mithalten oder es irgendwann vll auch übertreffen kann. Aber deine Begeisterung für ZFS teile ich uneingeschränkt.

[nubar]

Das mit den I/O Ops stimmt zum Teil aber das mit dem RAM-Verbrauch ist mMn. Blödsinn.

Man kann den RAM-Verbrauch von ZFS einschränken so, wie man will. Das ist ja sozusagen die "bcache"-Funktion die ZFS da mitbringt. Wenn man das also in nem anderen Dateisystem haben will und dafür bcache laufen lässt, hat man den RAM-Verbrauch auch an der Backe. Das hat mit "scheren sich nicht um Consumer" gar nichts zu tun außer, dass die Defaults andere sind. Benchmarks zeigen, dass man etwa 1GB RAM je TB Plattenspeicher ausgeben sollte. Danach steigt dich Caching-Performance nicht mehr. Und 1GB RAM hat man auf jedem Knödelnotebook übrig oder man hat ganz andere Sorgen. AUSSERDEM: Bei steigendem Speicherdruck verringert ZFS automatisch den RAM-Verbrauch. Das wird nur dann ein Problem, wenn man schnell viel RAM braucht und kein Swap hat. Also auf 'nem Notebook mit marginaler Ausstattung eine VM startet, die dann erstmal den halben RAM "ballooned". Daraus jetzt aber Unbrauchbarkeit für Notebooks zu konstruieren, halte ich für von Unwissenheit getrieben.

Die Nachteile werden meiner Beobachtung nach erstens durch das gute Caching wieder wettgemacht. Insbesondere auf einem Notebook maskiert das bei warmgelaufenem Cache die eigentliche Geräteperformance. Denn der Anwender hat gar nicht so stark wechselnde Zugriffe. Zweitens macht die Flexibilität des Dateisystems die angeblichen Performance-Nachteile mehr als wett, insbesondere bei aktiver Kompression, da in der Regel, gerade auf Notebooks, ein Überangebot an Rechenkraft ggü. I/O herrscht und jedes Byte, dass nicht gelesen oder geschrieben werden muss, einen echten Gewinn darstellt.

Ich habe ZFS seit Jahren in der Breite im Einsatz und kann die im Labor festgestellten Performance-Unterschiede in der Praxis nicht nachvollziehen, wohl aber die Nachteile von einfacheren Dateisystemen. EXT4 z.B. ist besonders anfällig für inode Exhaustion und BTRFS für I/O penalties bei vielen hardlinks.

[robinx999]

Eigentlich muss ich sagen BTRFS hat für Privatpersonen durchaus Fähigkeiten die ZFS leider nicht hat und die dort auch nicht gewünscht sind, da man diese im Enterprise nicht benötigt
Ich meine ich hatte in meinem als NAS genutztem PC 2 Platten a 4TB und hatte die im Mirror
Irgendwann wurde es voll und ich habe eine weitere dabei gepackt 3 Platten a 4TB waren 6 TB nutzbar
Als es wieder voll wurde hatte ich eine 4te dabei gepackt und hatte einen Mirror mit 4 Platten a 4 TB und 8 TB nutzbar als es dann wieder voll wurde konnte ich es zu einem RAID 5 umwandeln und hatte dann 12TB nutzbar alles ohne das Dateisystem zu zerstören
Verkleinern klappt auch sehr gut und gerade der Mirror wo der nutzbare Platz die Hälfte der Plattenkapazität ist (sofern eine Platte nicht größer 50% der Gesamtkapazität hat) ist bei ungleichen Festplatten schon ein nettes Feature von BTRFS

[me2]

nubar schrieb:
--------------------------------------------------------------------------------
> Benchmarks zeigen, dass man etwa 1GB RAM je TB Plattenspeicher ausgeben
> sollte. Danach steigt dich Caching-Performance nicht mehr.

Da hat man ein 16 TB Datengrab und schwupp soll man 16 GB RAM abschreiben? Das finde ich jetzt aber schon ziemlich viel.

[zonk]

me2 schrieb:
--------------------------------------------------------------------------------
> nubar schrieb:
> ---------------------------------------------------------------------------
> -----
> > Benchmarks zeigen, dass man etwa 1GB RAM je TB Plattenspeicher ausgeben
> > sollte. Danach steigt dich Caching-Performance nicht mehr.
>
> Da hat man ein 16 TB Datengrab und schwupp soll man 16 GB RAM abschreiben?
> Das finde ich jetzt aber schon ziemlich viel.

Und beim Datengrab ist die Cachingperformance besonders wichtig.

[nubar]

Ja, wenn man solchen Plattenlimbo betreiben können muss, ist ZFS wohl nicht die richtige Wahl. Ich bin beeindruckt, dass das sorglos funktioniert hat.

[gadthrawn]

/mecki78 schrieb:
--------------------------------------------------------------------------------
> ZFS hat das einfachste Nutzerinterface aller Dateisystem, die ich kenne,
> und bietet alle Features, die man von einem modernen Dateisystem erwartet.
> Es hat nur drei "Probleme":

Nummer 4: Auf einem HardwareRaid ist es tödlich lahm. Nicht nur keine gute Performance, sondern echt lahm.

[robinx999]

Ja das hat alles funktioniert das Dateisystem war auch während der Umwandlungen permanent eingehangen
Allerdings muss ich sagen die Umwandlung Mirror auf Raid 5 ging unter arger Last zu ende (war aber vermutlich auch meine Schuld da ich recht viele Snapshots hatte), die hat von Freitag Abend bis Mittwoch morgen gedauert und die Zugriffszeiten währenddessen waren langsam. Aber ja eigentlich muss ich sagen bin ich mit BTRFS sehr zufrieden und es läuft auch gut auf dem Desktop / Notebook wo nur jeweils eine Platte ist und mit ZFS Send kann ich es zum NAS schicken

[lestard]

Kannst du bcachefs einordnen im Vergleich zu anderen Dateisystemen? Ich kenne Ext4, ZFS und BTRFS. Von bcachefs hab ich hier im Artikel das erste mal gehört.
Mit was ist es am ehesten vergleichbar? Was sind Vorteile, was Nachteile? Einsatzzwecke?

[BT90]

Wer kombiniert ZFS und Hardware RAID? Ist doch völlig sinnbefreit? Und falls schon zufällig ein Controller da ist der genutzt werden soll, dann einfach als JBOD betreiben oder besser noch den Controller gleich auf IT Mode flashen.

[Firebat]

Im Prinzip greift Kent Overstreet die Erfahrungen der letzten 20 oder 30 Jahre im Filesystem-Bereich auf und versucht die Dinge zu vermeiden, die z.B. bei BTRFS schief gelaufen sind. Alle Copy-on-Write-Dateisysteme, wozu BTRFS, ZFS und auch BCacheFS gehören, folgen (mehr oder weniger) der selben Arbeitsweise. Wenn man BCacheFS einordnen müsste, dan auf jeden Fall in die selbe Schublade wie ZFS und BTRFS.

BTRFS hat(te) das Problem, dass es viel zu früh in den Kernel gewandert ist. Damit waren die Eckpfeiler in Stein gemeißelt, denn die "oberste Regel" der Kernelentwickler ist "Don't break userspace!". Die Designschwächen, die BTRFS hat, lassen sich nun nicht mehr ausbügeln, weil die Abwärtskompatibilität nicht mehr gegeben wäre. Die Ideen für BTRFS waren gut, das muss man auf jeden Fall anerkennen. Rückblickend betrachtet hat man aber ein paar Dinge vergessen.

Overstreet hat, seiner Aussage nach, vorher ganz viel Zeit mit Theorie verbracht, um diese Fehler, die die anderen vor ihm an der einen oder anderen Stelle gemacht haben, nicht zu machen. Das gesamte Konzept stand, bevor eine Zeile Code geschrieben wurde. Er sagt selbst, dass das eigentlich einer Herkulesaufgabe sei. Du kannst den Leuten keine Codeschnippsel zeigen und dich dann zum "fertigen" Produkt hangeln, du musst im Prinzip das fertige Produkt haben, wenn es in den Kernel wandern soll.

Wenn man unter bcachefs.org runterscrollt und unter "Status" schaut, bekommt man einen kurzen Überblick, was alles integriert ist.

[BT90]

Firebat schrieb:
--------------------------------------------------------------------------------

> BTRFS hat(te) das Problem, dass es viel zu früh in den Kernel gewandert
> ist. Damit waren die Eckpfeiler in Stein gemeißelt, denn die "oberste
> Regel" der Kernelentwickler ist "Don't break userspace!". Die
> Designschwächen, die BTRFS hat, lassen sich nun nicht mehr ausbügeln, weil
> die Abwärtskompatibilität nicht mehr gegeben wäre.

Stimmt so nicht zu 100%. Am extent-tree-v2 Patch wird eifrig gearbeitet und der ändert das on-disk Format.

https://github.com/btrfs/btrfs-todo/issues/25

[Firebat]

Das kannte ich so noch nicht, danke. Wie man an der Diskussion sieht, ist es aber gar nicht so einfach, nachträglich etwas grundlegendes zu ändern. Ich hab's nur überflogen, aber die Änderung muss auf jeden Fall offline durchgeführt werden. Nicht unmöglich, keine Frage, aber doch recht hohe Hürden. Wenn ich das richtig sehe, ist es bisher auch noch in der Entwicklung, oder?

[Vanger]

Firebat schrieb:
--------------------------------------------------------------------------------
> Das kannte ich so noch nicht, danke. Wie man an der Diskussion sieht, ist
> es aber gar nicht so einfach, nachträglich etwas grundlegendes zu ändern.

Wieso sollte das so sein? Richtig ist natürlich, dass es die "Don't break userspace"-Regel gibt, im Falle von Dateisystemen ist die aber kaum relevant: Es gibt abseits der Dateisystem-eigenen Tools gar keine Userspace-Software - und die darf geändert werden. Der übrige Userspace nutzt die über alle Dateisysteme hinweg ohnehin identische API zum Zugriff auf Dateien & Verzeichnisse.

[Firebat]

Ja, auch das ist technisch richtig, eigentlich findet davon nichts im Userspace statt. Das habe ich durcheinandergeworfen. Die Kernaussage bleibt aber: das Ändern des Diskformats geht nicht so ohne weiteres durch, wenn damit die Abwärtskompatibilität nicht mehr gegeben ist. Im Prinzip müsste daraus, meiner Meinung nach, ein BTRFS2 entstehen. Migrationspfad hin oder her.

Es ist natürlich trotzdem von Wert, wenn man aktiv versucht, die bestehenden Probleme zu lösen, keine Frage.