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.
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.
Von kamome umidori am Fr, 10. Januar 2020 um 14:35 #
Wenn die Abstraktionsschichten aber nicht gut zusammenspielen (oder für sich schon nicht der Bringer sind), ist es mir lieber, dass es das schon mal alles in einem gibt. Solle es mal irgendwann Abstraktionen geben, die das alles auf demselben Niveau Abbilden können, wäre das prima, aber darauf möchte wohl niemand warten!
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?).
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 …
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.
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.
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.
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.
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.
Man spricht hier auch von Abstraktionsebenen, und die sind i.A. von Vorteil.
Wo ist das Argument?
Wenn die Abstraktionsschichten aber nicht gut zusammenspielen (oder für sich schon nicht der Bringer sind), ist es mir lieber, dass es das schon mal alles in einem gibt. Solle es mal irgendwann Abstraktionen geben, die das alles auf demselben Niveau Abbilden können, wäre das prima, aber darauf möchte wohl niemand warten!
Nein, in dem Fall nicht.
Bezüglich der Datenintegration sind sie schädlich.
Genau so ist es!
Im Allgemeinen bieten Ebenen schon Vorteile. Im speziellen Fall hier ist ZFS dem Ebenenansatz aber deutlich überlegen.
Das wäre ein Thema, wo "Verflucht*" einsteigen könnte...
Wie man nur freiwillig auf solche Vorstellungen kommen kann...
Er hat Ferien oder eine Freundinn....hoffe dass sein Hass da mal bisschen gedaempft wird....ist ja gar nicht gut fuer seinen Blutdruck.
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?).
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 …
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.
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.
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.
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.
Ich würde da widersprechen.