Login
Newsletter
Werbung

Thema: Torvalds: Benutzt kein ZFS!

26 Kommentar(e) || Alle anzeigen ||  RSS || Kommentieren
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
2
Von kamome umidori am Fr, 10. Januar 2020 um 12:40 #

> Warum sollte man es überhaupt benutzen wollen?

Da es keine vollwertige Alternative gibt?! Man sollte sich vielleicht an der eigenen Nase fassen und das fortgesetzte Debakel bei der Entwicklung von BtrFS anschauen – ich verwende es, aber dass RAID 5/6 bis heute nicht empfehlbar sind, ist doch ein Armutszeugnis!

https://btrfs.wiki.kernel.org/index.php/RAID56
https://btrfs.wiki.kernel.org/index.php/Status

  • 2
    Von schmidicom am Fr, 10. Januar 2020 um 13:27 #

    Der Linux-Kernel bietet bereits ein wirklich gutes Software-RAID an. Das im Dateisystem zu implementieren führt nur zu einer weiteren unnötigen Fragmentation einer Funktionalität die mit der Kernaufgabe eines Dateisystems nicht einmal wirklich etwas zu tun hat.

    • 1
      Von kraileth am Fr, 10. Januar 2020 um 13:42 #

      Im Gegenteil zu der hier getroffenen Aussage würde ich behauten, daß die Kombination von Dateisystem und Volume-Manager einer der Geniestreiche hinter ZFS ist. Dadurch weiß ZFS, welche Teile eines Speichermediums überhaupt gewollte Daten enthalten und welche als leer angesehen werden können.

      Zieh mal bei einem mdadm-Spiegel (zu dem Tool sage ich besser mal überhaupt nichts) aus zwei 8-TB-Platten, auf denen nur 20 GB belegt sind, einen Teinehmer, weil sie kaputt ist und packe eine neue dazu. Das MDRaid muß das gesamte Gerät / die gesamte Partition synchronisieren, wovon der allergrößte Aufwand unnötig ist. ZFS resilvert die 20 GB + Metadaten und ist fertig. Wer darauf steht, seine Laufwerke unnötig zu quälen oder lange Zeiten mit verminderter Leistung durch das Synchronisieren von Datenmüll super findet, der sollte natürlich von ZFS Abstand nehmen.

      Aber auch sonst ist der ZFS-Ansatz massiv im Vorteil. Wenn Du etwas Flexibilität hinsichtlich der Partitionierung haben willst, hilft Dir das Softraid gar nichts, sondern Du brauchst gleich noch LVM - und damit eine weitere Schicht. Das ist bei ZFS alles gleich mit dabei (und erheblich besser ausgeformt).

      Entsprechend würde ich schon darauf bestehen, daß diese Dinge alle zusammengehören und es sehr sinnvoll ist, sie zu kombinieren, wenn alle Teile davon profitieren.

      1
      Von klopskind am Fr, 10. Januar 2020 um 13:52 #

      Ich glaube, dass sich die allermeisten bewusst sind, dass mdraid (und LVM) existieren, und dass es viele Vorteile hat, die Schichten sauber voneinander zu trennen. Die Frage ist, ob es die selben Features bietet.

      Ich glaube nicht, dass die Entwickler von btrfs und ZFS ohne gute Gründe an diesen Schichten vorbei programmier(t)en. Diese Dateisysteme bieten eine wesentlich performantere und skalierbarere Implementierung für Snapshots auf der wesentlich unterschiedlichen Grundlage des CoW-Konzepts. Auch die Fehlerkorrekturen und Self-Healing-Eigenschaften während des Betriebs können die Alternativen meines Wissens nach nicht bieten - jedenfalls nicht in dem Umfang und der Effizienz wie btrfs und ZFS.

      Deswegen sind btrfs oder ZFS nicht direkt "besser" als andere Lösungen. Man muss für jeden Anwendungsfall abwägen, welche Features man braucht (oder besser: auf welche man verzichten kann), und danach die Lösungsoptionen bewerten.

      Auch in ext4 wird derweil von Google für Android eine datei-spezifische transparente Verschlüsselung implementiert, obwohl dm-crypt (FDE!) & Co existieren. Die Motivation ist, dass es performanter auf kleinen Geräten wie Mobiltelefoncomputern ist. Soweit ich mich erinnern kann, gab es auch die Erkenntnis, dass sich die gewünschte Anforderungen an Authentifikation und Schlüsselverwaltung schlecht auf die bestehende Infrastruktur abbilden lassen würden. Zudem könnte der übliche Standbymodus ein Problem für bisherige Alternativen darstellen (Wie verwaltet man bspw. swap?).

      1
      Von kamome umidori am Fr, 10. Januar 2020 um 14:32 #

      RAID 5/6 ist ja auch nur der peinliche Dauerwitz, den ich hier erwähnen wollte. BtrFS bietet ja noch deutlich mehr: Subvolumes/Snapshots (viel Spaß mit der Geschwindigkeit bei LVM!), Checksummen-basierte Datenintegrität …

      • 1
        Von Markus B. am Fr, 10. Januar 2020 um 16:01 #

        Subvolumes/Snapshots (viel Spaß mit der Geschwindigkeit bei LVM!)
        LVM-Snapshots gehen mit thinly provisioned LVM sehr schnell

        Checksummen-basierte Datenintegrität
        Das geht problemlos mit dm-integrity

        • 0
          Von klopskind am Fr, 10. Januar 2020 um 18:01 #

          Korrigier' mich, falls ich mir irre...

          Aber beim thin-provisioning von LVM muss man aber umso mehr darauf aufpassen, dass die einzelnen Snapshots bzw. der Snapshot-Pool nicht überläuft. Sonst werden die Snapshots wie für LVM gewöhnlich ausgehangen, und werden damit quasi stillschweigend unbrauchbar. Als Nutzer erfährt das im Ernstfalls erst, wenn es zu spät ist. Zudem muss sich der Snapshot-Pool den Platz mit dem Rest teilen. Das macht es auch etwas statischer/unflexibler in der Speicheraufteilung/-reservierung im Vergleich zu btrfs-subvolumes.
          Im Endeffekt ist thin-provisioning mit LVM bspw. auf einem Desktop oder einer Workstation relativ aufwändig (und für manche auf etwas kompliziert), es risikoarm zu administrieren.

          dm-integrity ist erst seit 4.12 mainlined. Damit gab es für ZFS oder btrfs (beide älter) keine Möglichkeit, diese alternative Infratstruktur zu nutzen. Zudem liest sich das so, also ob es lediglich die Fehler erfasst, aber nicht automatisch korrigiert. Für eine Korrektur müsste man erst tätig werden. Das ist nicht self-healing wie bei ZFS und btrfs.
          Der Grund hierfür wird sein, dass dm-integrity als Teil von cryptsetup entwickelt wird, und vermutlich in erster Linie für das Zusammenspiel mit dm-crypt für authentische Verschlüsselung entworfen wurde. Dass man es alleinstehend verwenden kann, wirkt eher wie ein netter Nebeneffekt.
          Außerdem würde ich vermuten, dass diese Kompenente nicht besonders ausgiebig getestet worden ist.


          Fazit: Ja, es gibt Alternativen, die das sauber getrennt voneinander anbieten. Aber die haben eben so ihre eigenen Macken.

          • 0
            Von Markus B. am Sa, 11. Januar 2020 um 16:01 #

            Alles korrekt.

            Ich dachte an Server, wo man mit overprovisioning umzugehen gewohnt ist.

            Das Scrubbing stößt man periodisch per cronjob an, dabei werden von dm-integrity erkannte Inkonsistenzen automatisch repariert.

          0
          Von kamome umidori am Sa, 11. Januar 2020 um 19:12 #

          Danke, dm-integrity kannte ich nicht – gut, wenn man da ein integrierbares Werkzeug hat. Aber ich glaube noch nicht, dass alle Funktionen von ZFS/BtrFS/(bald) bcachefs in gleichem Komfort abgedeckt werden können.

      1
      Von Ghul am Fr, 10. Januar 2020 um 20:44 #

      Du kannst dem Error Checking des Controllers nicht vertrauen um Bit rots zu erkennen.

      Deswegen soll man über ZFS auch keine logische Schicht, wie bspw. ein LVM schieben, der diese Informationen dann abstrahieren und für ZFS unsichtbar machen würde.

      ZFS installiert man daher nicht in ein LVM und abstrahiert es auch nicht über VM Disks oder ein SW Raid und Co., sondern man installiert es raw direkt auf die Platte. Nur dadurch kann ZFS oder ein entsprechendes Dateisystem auch Bit Rots erkennen.

      Es hat somit wesentliche Vorteile für die Datensicherheit, wenn das Dateisystem das SW Raid selber macht und deswegen ist das bei ZFS auch so gelöst und nicht anders.

      1
      Von blubb am Sa, 11. Januar 2020 um 10:36 #

      nur zu einer weiteren unnötigen Fragmentation einer Funktionalität die mit der Kernaufgabe eines Dateisystems nicht einmal wirklich etwas zu tun hat.
      Sagt wer?
      Ich würde da widersprechen.

    1
    Von Caramba am Fr, 10. Januar 2020 um 15:47 #

    Da es keine vollwertige Alternative gibt?!
    Für große und/oder verteilte Volumes gibt es sehr wohl Alternativen für High-Performance-Dateisysteme:
    - https://ceph.io/
    - https://www.gluster.org/
    - https://www.beegfs.io/content/ (leider (noch) nicht OpenSource)

    Die Abstraktionsschichten sind hier zwar nicht auf Kernel-Ebene, aber die Dateisysteme sind auch in großen Rechenzentren erprobt.

    • 0
      Von glasen am Fr, 10. Januar 2020 um 18:41 #

      Das sind aber alle keine Alternativen zu ZFS, sondern verteilte Dateisysteme, welche einen ganz anderen Einsatzzweck haben. Zudem setzen alle drei "Alternativen" auf normalen Dateisystem auf (Bei CephFS z.B. BTRFS).

      Ich habe erst vor drei Wochen ein Storage-System mit ca. 50TB Plattenplatz basierend auf ZFS eingerichtet, da es dieses sowohl transparente Kompression, Deduplikation und vor allem eine Dateisystemeigene Verschlüsselung anbietet.

      Natürlich kann man alle diese Funktionalitäten auch mit Linux-Bordmitteln erreichen, aber lange nicht so bequem und übersichtlich. Ich hätte gerne BTRFS eingesetzt, aber eine Verschlüsselung der Daten ist zwingend notwendig und das geht mit ZFS halt deutlich einfacher und schneller als mit BTRFS und LUKS.

    0
    Von blubb am Fr, 10. Januar 2020 um 19:20 #

    Meines Wissens wurden die größten Probleme mit RAID56 inzwischen gefixt und es besteht nur noch ein Problem, für welches aber ein Patch existiert (aber aus mir unbekannten Gründen noch nicht eingepflegt wurde).
    In jedem Fall wird an dem Problem gearbeitet. Daher ja auch die neuere Änderung, dass man nun mehr als 2 Mirror unterstützt.
    Auch das zielt auf RAID5/6 ab um die Metadaten häufiger replizieren zu können.

    Ich finde es tatsächlich auch extrem ärgerlich, dass der Status bei RAID56 bei btrfs so schlecht ist, aber zumindest kann man nun Hoffnung haben, dass es sich mittelfristig bessert.
    Und wenn das dann mal funktioniert, dann sind wenigstens die gröbsten Kanten bei btrfs endlich raus.

    Witzig bei der ganzen Story finde ich übrigens, dass btrfs ja gerade von Oracle ins Leben gerufen wurde, weil ZFS nicht Lizenz-kompatibel war.
    Ausgerechnet Oracle, die jetzt den Lizenzwechsel (zumindest für den wesentlichen Teil des ZFS Codes) durchführen könnten. ^^

    0
    Von Anon am Sa, 11. Januar 2020 um 08:58 #

    Mein Pool erreicht bald eine mittlere zweistellige Terrabytezahl. Es ist mit ZFS äußerst stabil. Ich nutze es bereits seit etwa sechs Jahren. Es gibt soweit ich weiß auch kein anderes OS, das ohne Controller in Kombination mit ECC-RAM eine Garantie hat, dass die Daten nie (!) degradieren. Dabei spielt dir Poolgröße keine Rolle. Das ist für mich das k.o. Kriterium. So etwas bot ZFS vor einem Jahr nicht, als ich das letzte Poolupgrade durchgeführt habe.

    Soweit ich weiß ist BTRFS nicht einmal stable im RAID 6. Ich habe nicht viel Zeit zu frickeln, daher sind das meine zwei Gründe um auf ZFS zu setzen.

    Lizenzsachen interessieren mich als Privatmann eher weniger.

    0
    Von fragmalnach am Mo, 13. Januar 2020 um 10:24 #

    Warum wollt ihr mit euren (Normalo-)Server ein RAID fahren?

    In der Praxis wird dazu dedizierte Hardware verwendet, also ein SAN in der Firma und ein kleines NAS wie Synology, QNAP etc mit ext4 für zu hause....

Pro-Linux
Traut euch!
Neue Nachrichten
Werbung