Caramon2 schrieb:
Mit zfs habe ich mich noch nie beschĂ€ftigt und habe es auch nicht vor. Gleiches gilt fĂŒr lvm und auch btrfs nutze ich (wegen der zstd-Komprimierung: da bereite ich gerade einen Thtead vor) nur als reines Dateisystem, ohne dieses Snapshot und so.
ZFS ist inzwischen quasi mein Default-Dateisystem. Was anderes nutze ich nur, wenn es dafĂŒr gute GrĂŒnde gibt (sehr schwache Hardware, oder wenns sich nicht anbietet wie bei USB-Sticks oder andere Erfordernisse wo sich ein anderes Dateisystem besser eignet).
Weil selbst wenn man die Snapshots jetzt mal weg lĂ€sst bleiben immer noch genĂŒgend interessante Features ĂŒbrig. Allein schon wenn ich mehrere Disk im Rechner hab und die gemeinsam nutzen will. Klar kann ich das mit LVM oder SoftRAID zusammenbasteln aber bei ZFS hab ich die Funktion gleich inklusive was einige angenehme Nebeneffekte hat dadurch das Plattenverwaltungslayer und Dateisystemlayer nicht mehr strikt getrennt sind.
Man kann partition-like Unterteilungen machen ohne aber die InflexibilitĂ€t von Partitionen zu haben was es dann z.B. ermöglicht dynamisch zur Laufzeit die GröĂe zu Ă€ndern.
Man hat Features fĂŒr höhere Datensicherheit wie Checksummen auf Blockebene. Das senkt das Risiko von (unbemerkter) Datenkorruption drastisch.
Ich hab Deduplication womit dann identische Daten nur einmal auf der Platte gespeichert werden. Das macht Sinn wenn ich z.B. ne handvoll Windows-VMs habe weil da ein groĂer Teil der Dateien gleich sind. Wenn ich die nur einmal speichern muss spare ich natĂŒrlich drastisch Speicherplatz.
Kompression hast Du ja schon genannt. Und zwar individuell einstellbar per Dataset. Das heiĂt ich kann sagen bei meiner JPEG-Bildern oder auch MPEG-Videos die sich eh kaum noch weiter komprimieren lassen lass ich die (letztlich ja auch zeitraubende) Komprimierung weg. Bei Sachen die ich selten brauche und die sich gut komprimieren lassen nehme ich nen starken Kompressionsalgorithmus. FĂŒr alles andere was nen guten Kompromiss aus Kompressionsrate und Geschwindigkeit darstellt.
Ăhnliches gilt fĂŒr VerschlĂŒsselung.
/usr/bin enthĂ€lt nix Geheimes dementsprechend kann ich mir sparen das zu verschlĂŒsseln.
Aber ja. Auch Snapshots sind ein cooles Feature welche auch gleich einen ganzen Strauà an Möglichkeiten aufmachen. Man kann gefahrlos was Àndern. Man kann Upgrades machen und wenn was schief geht problemlos den vorherigen Zustand wieder herstellen.
Man kann es benutzen fĂŒr Backups. Weil normalerweise hat man bei Backups ja immer das Problem, das man wĂ€hrend dessen eigentlich nicht am Computer "arbeiten" kann weil man ja nie weiĂ, wann die Dateien kopiert werden und dann wird vielleicht ne Datei gebackupt die gerade noch gespeichert wird und dann hat man im Backup ne kaputte Kopie. Mit Snapshots mach ich vorher ein Snapshot und "backuppe" dann den Snapshot.
Ein anderes Problem was Backup-Programme immer haben (wenn ich nicht gerade einfach stumpf ein Vollbackup mache) ist, das die bei inkrementeller Sicherung ja immer vergleichen mĂŒssen. Hat sich ne Datei geĂ€ndert oder nicht. Mit der Snapshot-FunktionalitĂ€t fĂ€llt das weg. Denn das Dateisystem fĂŒhrt ja fĂŒr mich Buch darĂŒber welche Daten geĂ€ndert worden sind. Ich kann also einfach den Snapshot so wie er ist wegsichern und fertig.
Was dann insbesondere bei VerschlĂŒsselung noch hinzu kommt. Wenn ich normal ein verschlĂŒsseltes Dateisystem habe mĂŒssen die gelesenen Daten ja erst mal entschlĂŒsselt werden und ggf. vom Backupprogramm wieder verschlĂŒsselt (damit ich es in der Cloud speichern kann oder was auch immer). Mein Snapshot kann ich aber "raw" wegsichern. Ich brauch nix entschlĂŒsseln. Ich sichere den so verschlĂŒsselt wie er ist einfach weg.
Gibt letztlich so viele Vorteile das man eher ĂŒberlegen sollte: "Gibts GrĂŒnde das nicht zu nehmen?" als "Gibts GrĂŒnde das zu nehmen?".
