[Gelöst] Einige Fragen zum ZFS und Btrfs Dateisystem unter Debian

[ralli]

Hallo,

ich möchte mich ernsthaft mit der Installation und Konfiguration von ZFS auseinandersetzen. Bevor ich mich daran wage, habe ich Klärungsbedarf zum besseren Verständnis.

Wenn ich auf eine zweite interne HD einen Datenpool anlege, belegt der ja den gesamten Platz auf der HD. Kann ich später noch einen zweiten Pool anlegen? Kann ich bei der Neuanlage eines Pools die Größe bestimmen oder begrenzen?

Wenn ich ein Dataset im Pool anlege, kann ich ja die Komprimierung aktivieren. Ist das überhaupt sinnvoll oder kostet das Rechenzeit? Wenn ich von meiner SSD das Homeverezeichnis mit allen Daten in einem zuvor angelegten Dataset Home mit aktiver Komprimerung sichere, werden die Daten in diesem Dataset ja komprimert. Ist das wie in einem Zip Archiv, das alles sozusagen verdichtet und verkleinert wird, so das dadurch Platz gespart wird?

Kann ZFS bereits bei der Installation von Debian eingerichtet werden? Die nachträgliche Einrichtung scheint ja ziemlich kompliziert zu sein, oder?

Das soll für den Anfang genügen. Danke.

Gruß ralli

[bluestar]

Hallo,

ich möchte mich ernsthaft mit der Installation und Konfiguration von ZFS auseinandersetzen. Bevor ich mich daran wage, habe ich Klärungsbedarf zum besseren Verständnis.

Wenn ich auf eine zweite interne HD einen Datenpool anlege, belegt der ja den gesamten Platz auf der HD. Kann ich später noch einen zweiten Pool anlegen? Kann ich bei der Neuanlage eines Pools die Größe bestimmen oder begrenzen?

Du kannst die HDD in Partitionen unterteilen und deinen Pool auf eine Partition legen. Vielleicht komme ich deiner Frage mal mit einer Gegenfrage zuvor: Welchs Ziel verfolgst du mit zwei Pools auf einer HDD?

Wenn ich ein Dataset im Pool anlege, kann ich ja die Komprimierung aktivieren. Ist das überhaupt sinnvoll oder kostet das Rechenzeit?

Wenn du ein wenig dazu Recherche betreibst, dann wirst du feststellen das die Komprimierung zwar Rechenzeit kostet, die jedoch durch den gewonnen höheren Datendurchsatz mehrfach ausgeglichen wird.

Wenn ich von meiner SSD das Homeverezeichnis mit allen Daten in einem zuvor angelegten Dataset Home mit aktiver Komprimerung sichere, werden die Daten in diesem Dataset ja komprimert. Ist das wie in einem Zip Archiv, das alles sozusagen verdichtet und verkleinert wird, so das dadurch Platz gespart wird?

Ja die Kompression spart Speicherplatz und erhöht die Leistung.

An dieser Stelle direkt eine Warnung: Du solltest auf jeden Fall die Finger von dem ZFS Feature Deduplikation lassen, das Feature lässt sich im Nachhinein leider nicht mehr deaktivieren und kostet - im Gegensatz zu Komprimierung - wirklich Rechenleistung und führt zu einem erhebliche höheren RAM Bedarf.

Kann ZFS bereits bei der Installation von Debian eingerichtet werden? Die nachträgliche Einrichtung scheint ja ziemlich kompliziert zu sein, oder?

Der Installer bietet keine Unterstützung für ZFS, jetzt gilt es zwei Varianten zu unterscheiden:
1) Dein System auf ex4 und einen zfs-Pool als Datenablage
2) Dein System auf einem zfs-Pool

Für ersteren Fall installierst du einfach die ZFS Pakete nach und legst deinen Pool an und für den zweiten Fall empfehle ich dir die Installation via Live-CD und offizieller Anleitung: https://openzfs.github.io/openzfs-docs/ ... 20ZFS.html

[MSfree]

Ja die Kompression spart Speicherplatz und erhöht die Leistung.

Dazu mal ein Einwurf. Ich weiß natürlich nicht, wie ZFS Kompression handhabt.

Ein großes Problem bei komprimierten Daten ist, daß ihnen die Fähigkeit des zufälligen Zugriffs abhanden kommt. Wenn ich bei einer 1MB großen Datein das 500000. Byte lesen oder ändern will, muß bei komprimierten Daten beim ersten Byte angefangen werden zu dekomprimieren, weil das 500000. Byte eben vom ersten Byte anhängig ist. Noch schlimmer sieht es beim Ändern des 500000. Bytes aus. Da muß ich zuerst alles bis zum 500000. Byte dekomprimieren, dann die Änderung vornehmen und dann alls Daten vom 500001. bis zum Dateiende neu komprimieren.

Eine simple Änderung eines einzigen Bytes, die auf einem unkomprimierten Dateisystem nur das Lesen und Schreiben eines Datenblocks (typischerweise 4096 Bytes) von der Platte bedeutet, kann das bei komprimierten Daten ganz extrem in die Performance gehen.

Man kann das Performanceproblem ein wenig entschärfen, in dem dekomprimierte Daten im Cache gehalten werden, und man kann es entschärfen, in dem man große Dateien nich am Stück komprimiert sondern Blockweise. Allerdings kann man die Blockgröße nich beliebig klein machen, weil dann der Kompressionsfaktor zu klein wir (wenn man nur 20% Kompression erreicht, kann man es sparen).

Meine Vermutung ist, daß ZFS sowohl blockweise komprimiert und zusätzlich cachet. Dennoch wird man durch Kompression nicht in allen Fällen eine höhere Leistug erreichen können, in Sonderfällen wird das auch 10 mal langsamer als unkomprimiert. Dazu kommt, daß es auch Datenarten gibt, die ohnehin schon komprimiert sind. Videos, Fotos und ZIP-Dateien sind beispielsweise komprimiert und lassen sich durch ein komprimierendes Dateisystem nicht noch weiter eindampfen, man gewinnt hier also keinen Speicherplatz, muß aber dennoch den Dekompressionsmechanismus durchlaufen, was die CPU-Last erhöht und somit das System ausbremst.

[bluestar]

Ja die Kompression spart Speicherplatz und erhöht die Leistung.

Dennoch wird man durch Kompression nicht in allen Fällen eine höhere Leistug erreichen können, in Sonderfällen wird das auch 10 mal langsamer als unkomprimiert.

Hier würden mich ein paar Fakten zu dem Thema interessieren, alles was ich bisher - auch abseits von ZFS - zu Dateisystemen mit Kompression gelesen habe zeigt auf, dass Kompression kein Performancekiller ist.

[heisenberg]

Was schlecht komprimierbare Daten angeht:

Zumindest die Standardmethode LZ4 von ZFS prüft jeweils am Anfang (von einem Block?) wie sie Kompressionsrate ist. Ist die zu schlecht, wird unkomprimiert gespeichert.

[ralli]

Hallo bluestar,

vielen Dank für die ausführlichen Informationen und wertvollen Tipps.

Welches Ziel ich mit zwei zwei Pools verfolge? Nun, war nur so eine Idee, dahinter stand keine konkrete Absicht. Ich sehe schon, das das wohl keinen wirklichen Sinn macht.

Natürlich habe ich auch ausgiebig und lange recherchiert. Aber ZFS ist sehr umfangreich, die Grundlagen waren mir ein wenig vertraut, weil ich einige Jahre mit FreeBSD gearbeitet habe. Damals habe ich allerdings nicht alle Vorteile von ZFS genutzt. Das mit dem höheren Datendurchsatz werde wohl mal testen. Danke auch für die Warnung vor Deduplikation, sehr aufmerksam.

Hab mich für

Code: Alles auswählen

1) Dein System auf ex4 und einen zfs-Pool als Datenablage

entschieden, denn ich möchte die interne zweite Platte tatsächlich für die Datenablage nutzen.

Die HD ist leer, aber noch GPT drauf. Muß ich die GPT vorher löschen? Bei FreeBSD beschädigt er eine noch vorhandene GPT, wenn ein Pool auf der gesammten HD angelegt wird. Beim Booten erscheint dann immer die Fehlermeldung

Code: Alles auswählen

GPT corrupt

.

Herzlichen Dank, Du hast mir gut weitergeholfen.

Gruß ralli

[ralli]

Ja die Kompression spart Speicherplatz und erhöht die Leistung.

Dazu mal ein Einwurf. Ich weiß natürlich nicht, wie ZFS Kompression handhabt.

Ein großes Problem bei komprimierten Daten ist, daß ihnen die Fähigkeit des zufälligen Zugriffs abhanden kommt. Wenn ich bei einer 1MB großen Datein das 500000. Byte lesen oder ändern will, muß bei komprimierten Daten beim ersten Byte angefangen werden zu dekomprimieren, weil das 500000. Byte eben vom ersten Byte anhängig ist. Noch schlimmer sieht es beim Ändern des 500000. Bytes aus. Da muß ich zuerst alles bis zum 500000. Byte dekomprimieren, dann die Änderung vornehmen und dann alls Daten vom 500001. bis zum Dateiende neu komprimieren.

Eine simple Änderung eines einzigen Bytes, die auf einem unkomprimierten Dateisystem nur das Lesen und Schreiben eines Datenblocks (typischerweise 4096 Bytes) von der Platte bedeutet, kann das bei komprimierten Daten ganz extrem in die Performance gehen.

Man kann das Performanceproblem ein wenig entschärfen, in dem dekomprimierte Daten im Cache gehalten werden, und man kann es entschärfen, in dem man große Dateien nich am Stück komprimiert sondern Blockweise. Allerdings kann man die Blockgröße nich beliebig klein machen, weil dann der Kompressionsfaktor zu klein wir (wenn man nur 20% Kompression erreicht, kann man es sparen).

Meine Vermutung ist, daß ZFS sowohl blockweise komprimiert und zusätzlich cachet. Dennoch wird man durch Kompression nicht in allen Fällen eine höhere Leistug erreichen können, in Sonderfällen wird das auch 10 mal langsamer als unkomprimiert. Dazu kommt, daß es auch Datenarten gibt, die ohnehin schon komprimiert sind. Videos, Fotos und ZIP-Dateien sind beispielsweise komprimiert und lassen sich durch ein komprimierendes Dateisystem nicht noch weiter eindampfen, man gewinnt hier also keinen Speicherplatz, muß aber dennoch den Dekompressionsmechanismus durchlaufen, was die CPU-Last erhöht und somit das System ausbremst.

Danke auch Dir MSfree. Ich denke, das ich das erstmal ausprobiere, die Komprimierung kann ja zu jeder Zeit deaktiviert werden. Allerdings kann ich Deine Bedenken nachvollziehen, denn sie sind ja durchaus logisch.

Gruß ralli

[ralli]

Was schlecht komprimierbare Daten angeht:

Zumindest die Standardmethode LZ4 von ZFS prüft jeweils am Anfang (von einem Block?) wie sie Kompressionsrate ist. Ist die zu schlecht, wird unkomprimiert gespeichert.

Hallo, hört sich doch gut an. Danke, ich denke, ich habe noch einiges zu lernen. ZFS ist ganz gut dokumentiert.

Gruß ralli

[ralli]

Habe folgende Pakete installiert:

ACHTUNG! Repo contrib muß in /etc/apt/sources.list aktiviert und vorhanden sein.

Code: Alles auswählen

apt install linux-headers-amd64 dkms --no-install-recommends

Code: Alles auswählen

apt install zfs-dkms --no-install-recommends

Code: Alles auswählen

apt install zfsutils-linux

Und zum Schluß:

Code: Alles auswählen

echo "zfs" >> /etc/modules-load.d/modules.conf

So, ZFS läuft. Dann werden es wohl die richtigen Pakete gewesen sein.

Datenpool backup auf sdb anlegen:

Code: Alles auswählen

/usr/sbin/zpool create backup /dev/sdb

Dataset home im Pool backup anlegen:

Code: Alles auswählen

/usr/sbin/zfs create backup/home

Code: Alles auswählen

/usr/sbin/zpool status

pool: backup
state: ONLINE
config:

NAME STATE READ WRITE CKSUM
backup ONLINE 0 0 0
sdb ONLINE 0 0 0

Code: Alles auswählen

/usr/sbin/zpool list

NAME SIZE ALLOC FREE CKPOINT EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT
backup 928G 360M 928G - - 0% 0% 1.00x ONLINE -

Code: Alles auswählen

/usr/sbin/zfs list

NAME USED AVAIL REFER MOUNTPOINT
backup 360M 899G 96K /backup
backup/home 359M 899G 359M /backup/home

Gruß ralli

[MSfree]

Hier würden mich ein paar Fakten zu dem Thema interessieren, alles was ich bisher - auch abseits von ZFS - zu Dateisystemen mit Kompression gelesen habe zeigt auf, dass Kompression kein Performancekiller ist.

Wenn man Daten nur linear und vollständig liest oder schreibt, wird Kompression durchaus zum Beschleuniger. Ein Textdokument wird man immer komplett in den Editor laden und komplett wieder raussichern, es finden also lineare Zugriffe statt.

Sobald man es mit mit Dateien zu tun hat, bei denen Daten ständig auf Dateiebene verändert werden, hat man mit Kompression ein Problem.

Besonders, wenn Datenmengen sehr groß werden und nicht mehr ins RAM passen, kommt man gar nicht umhin, Daten nut teilweise von der Platte zu lesen und zu verarbeiten. Wenn man zum Lesen von partiellen Daten in der Mitte einer Datei diese Datei von vorne durchlesen und dekomprimieren muß, ist das Performanceproblem unvermeidbar.

Mit blockweiser Kompression, beipielsweise alle 100kB ein neuer Kompressionsblock, braucht man zwar nicht ganz von vorne lesen, weil man an den Anfang des Kompressionsblocks direkt springen kann, aber auch dann muß man mehr Daten lesen als im unkomprimierten Fall und hat zusätzliche CPU-Last. Es gibt einen Punkt, bei dem die gewonnene Zeit durch lesen geringerer Datenmengen, durch die höhere CPU-Last durch De/kompression aufgefressen oder sogar überstiegen wird.

Vor allem, wenn man so einen ZFS-Pool dazu benutzen will, um ohnehin schon komprimierte Daten zu speichern (Videos, Fotos, tar.gz, zip), ist die Kompression auf Dateisystemebene Unsinn, weil die Daten durch eine weitere Kompression nicht schrumpfen. Man kombiniert hier dann die hohe CPU-Last durch Kompression/Dekompression mit nicht komprimierbaren Daten, was auf alle Fälle schlecht für die Geschwindigkeit ist.

Es gibt leider keine allgemeingültige Aussage, daß Kompression immer zu höherer Geschwindigkeit führt. Es kommt auf die Daten an, ob und wie viel sie sich komprimieren lassen und auf das typische Zugriffsmuster auf solche Dateien (linear von vorn bis hinten in einem Zug, oder willkürlich zufällige Zugriffe irgendwo in der Datei).

Debian Bookworm läuft jedefalls auf meinem EeePC mit komprimierendem btrfs deutlich langsamer als mit einem nicht komprimierenden Dateisystem. Allerdings habe ich auf dem EeePC kaum eine Wahl, denn ohne Kompression paßt ein Debian mit LXDE, Firefox und Thunderbird gerade mal so auf die interne 4GB winzige SSD und läßt nur 100-200MB freien Plattenplatz über, der alleine durch Logs ziemlich schnell aufgebraucht ist. Mit Kompression habe ich 2.3GB frei.

[bluestar]

Debian Bookworm läuft jedefalls auf meinem EeePC mit komprimierendem btrfs deutlich langsamer als mit einem nicht komprimierenden

Bei deinem Sonnderfall EeePC gehe ich mit, da ist Kompression ein Performancekiller, dennoch ist das Ding auch ohne Kompression kein Geschwindigkeitswunder an sich.

[bluestar]

Die HD ist leer, aber noch GPT drauf. Muß ich die GPT vorher löschen? Bei FreeBSD beschädigt er eine noch vorhandene GPT, wenn ein Pool auf der gesammten HD angelegt wird. Beim Booten erscheint dann immer die Fehlermeldung

Ich benutze generell immer eine Partitionstabelle und nicht die gesamte HDD.

[ralli]

Die HD ist leer, aber noch GPT drauf. Muß ich die GPT vorher löschen? Bei FreeBSD beschädigt er eine noch vorhandene GPT, wenn ein Pool auf der gesammten HD angelegt wird. Beim Booten erscheint dann immer die Fehlermeldung

Ich benutze generell immer eine Partitionstabelle und nicht die gesamte HDD.

Aha ich verstehe. HDD mit mehreren Partitionen aufteilen und entsprechend nutzen.

Gruß ralli

[ralli]

Hallo bluestar,

jetzt möchte ich das Dataset im Pool backup komprimieren. Ist das so richtig?

Code: Alles auswählen

zfs set compression=gzip backup/home

Da habe ich noch ein paar Fragen .... Arbeitet die Komprimierung rekursiv? Welcher Komprimierer ist sinnvoll oder Standard. Gzip oder LZ4?

Wird durch meinen Befehl die Komprimierung dauerhaft aktiv für das Dataset? Danke

Gruß ralli

[heisenberg]

LZ4 ist Standard. Den würde ich auch verwenden. GZIP benötigt mehr CPU-Resourcen. Siehe [1]. Die Kompression wird dauerhaft aktiv für das Dataset, für dass Du sie einschaltest. Ob das auch untergeordnete Datasets einschließt weiß ich nicht. Das schließt auch untergeordnete Datasets mit ein.

Nur neu geschriebene Dateien werden komprimiert. Vorhandene Dateien bleiben, solange sie nicht neu geschrieben werden unkomprimiert. Wenn die Kompression ausgeschaltet wird, bleiben die Dateien komprimiert, bis sie neu und dann wieder unkomprimiert geschrieben werden.

Der Befehl für LZ4 wäre z. b.

Code: Alles auswählen

zfs set compression=on backup/home

[1] https://de.wikibooks.org/wiki/ZFS_auf_L ... primierung

[ralli]

LZ4 ist Standard. Den würde ich auch verwenden. GZIP benötigt mehr CPU-Resourcen. Siehe [1]. Die Kompression wird dauerhaft aktiv für das Dataset, für dass Du sie einschaltest. Ob das auch untergeordnete Datasets einschließt weiß ich nicht.

Nur neu geschriebene Dateien werden komprimiert. Vorhandene Dateien bleiben, solange sie nicht neu geschrieben werden unkomprimiert.

Der Befehl für LZ4 wäre z. b.

Code: Alles auswählen

zfs set compression=on backup/home

[1] https://de.wikibooks.org/wiki/ZFS_auf_L ... primierung

Danke heisenberg, das hat wunderbar funktioniert. Ist doch richtig, wenn die Komprimierung für das leere Dataset aktiviert wurde, dann einfach den Inhalt aus meinem Ordner der SSD home ins Dataset kopieren, es wird dann automatisch komprimiert während des Schreibens. Und wenn ich Dateien aus dem Dataset zurück auf die SSD kopiere, wird automatisch entpackt. Das ist ja einfach. Einfach und effizient. ZFS gefällt mir.

Gruß ralli

[ralli]

Der Grad der Wirksamkeit der Kompression eines Dataset (in diesem Fall backup/home) kann überprüft und angezeigt werden:

Code: Alles auswählen

zfs get used,compressratio,compression,logicalused backup/home

Ausgabe:

Code: Alles auswählen

NAME         PROPERTY       VALUE           SOURCE
backup/home  used           288M            -
backup/home  compressratio  1.24x           -
backup/home  compression    on              local
backup/home  logicalused    355M 

Es wurde hier 355-288 = 67M Speicherplatz eingespart. Kompression bringt schon was. Audio und Videodateien sind naturgemäß schon komprimiert, aber viele ander Dateien eben nicht.

Hiier gibt es eine sehr gute deutsche Anleitung zu ZFS:

https://docs.freebsd.org/de/books/handbook/zfs/

Es ist aus dem FreeBSD Handbuch und eignet sich gut zum Lernen und Üben.

Gruß ralli

[ralli]

Nur der Vollständigkeit halber, installiert habe ich ZFS nach dieser Anleitung:

https://www.stefanux.de/wiki/doku.php/linux/zfs

Gruß ralli

[heisenberg]

Zwei schöne Programme, die man da vielleicht nutzen will sind...

zfsnap für flexible Snapshots und das Script zrep (gescriptetes zfs send/receive) zum effizienten inkrementellen replizieren auf eine andere Maschine.

[ralli]

Zwei schöne Programme, die man da vielleicht nutzen will sind...

zfsnap für flexible Snapshots und das Script zrep (gescriptetes zfs send/receive) zum effizienten inkrementellen replizieren auf eine andere Maschine.

Danke, gute Helferlein. Allerdings ist zrep nicht im Bullseye Repo, kann aber hier heruntergeladen werden:

Code: Alles auswählen

http://www.bolthole.com/solaris/zrep/

Gruß ralli

[wanne]

Eine simple Änderung eines einzigen Bytes, die auf einem unkomprimierten Dateisystem nur das Lesen und Schreiben eines Datenblocks (typischerweise 4096 Bytes) von der Platte bedeutet, kann das bei komprimierten Daten ganz extrem in die Performance gehen.

@MSFree. Deine Ausführungen mögen zwar allgemein für Kompression stimmen. Sind aber für ZFS im speziellen irrelevant. Warum? ZFS arbeitet eh (wie alle Dateisysteme) in Blöcken schon alleine um die Checksumme zu berechnen muss immer ein voller block gelesen werden. Schlimmer noch: Auch Festplatten können nur Blockweise gelesen werden. (Die intern für SSDs sogar oft weit größer als 4k sind. Aber selbst wenn du eine steinalt HDD hast, die 0,5k Blöcke hat, liest jedes Dateisystem gleich acht auf einmal weil das lesen von mehreren hinter einander liegenden üblicher weise Bruchteile von Prozenten langsamer ist und die Chance, dass man den Nachfolgenden Block aus Zufall nochmal gebrauchen kann, weit größer als die verlorene Performance ist.) Du musst also immer 4kiB lesen, wenn du ein Byte haben willst. Da aber jeder block einzeln komprimiert wird, kannst du die auch einzeln lesen.

und zusätzlich cachet.

Kann ich mir kaum vorstellen, da ich tippe, dass ein Cache kaum performant genug gebaut werden kann, dass er schneller als das dekomprimieren ist.

was die CPU-Last erhöht und somit das System ausbremst.

Das ist einfach nur falsch. Mir konnte zumindest noch nie irgend jemand irgend einen Fall konstruieren, der in nem unkomprimierten (btrfs LZO) Dateisystem Schneller ist, wenn die CPU flotter dekomprimiert als die HDD ließt. Das ist bei praktisch jedem Desktop-System der Fall. Oder etwas spezifischer als Richtwert immer dann, wenn du mehr für die CPU mehr ausgegeben hast als für deine SSD. Warum?
Moderne Rechner warten um viele Größenordnungen öfter auf die eine Festplatte als sie alle Kerne aus lasten. Selbst hoch optimierten Prozesse kommen nicht umhin hin und wieder mal auf die Platte zu warten. Selbst wenn es extrem selten ist, dass die Kompression hilft, bringt es dir extrem viel wenn deine 8? Kerne kürzer warten müssen weil weniger von der Platte gelesen werden muss. Als dass ein Kern mal zu einigen 10 Prozent zusätzlich ausgelastet ist. Das ist völlig unabhängig davon, wie groß der Anteil an I/O ist. Denn weniger I/O führt zu weniger Belastung der CPU durch die Kompression während mehr I/O das beschleunigen der I/O durch Kompression verbessert. Damit dir das hilft brauchst du also ein Prozess der (fast) vollständig ohne I/O auf die Platte auskommt, die durch die Kompression schneller wird aber trotzdem alle Kerne aus lastet und gleichzeitig einen Prozess der super I/O Heavy ist aber nicht länger als der Prozess auf der CPU braucht. Selbst wenn du das konstruieren willst ist ersteres extrem schwierig. Mit zweiterem das sauber balancen ist ungemein schwer. In der Realität taucht das nicht auf.

Anders sieht das natürlich aus, wenn du ne fette storage-Büchse rum stehen hast, die zig SSDs im RAID hat aber gleichzeitig ne nieder getaktete Server CPU die Energie sparen soll. Oder eben ein sparsamen Laptop mit Atom-CPU und SSD. Dann wird die I/O durch die wirklich langsamer.

[ralli]

Na ich spreche nur für mich und kann zu den technischen Spezifikationen (noch) nicht all zu viel sagen. Aber die Merkmale von ZFS sind schon beeindruckend und mit nichts zu vergleichen. Allerdings wurde ZFS jetzt nicht für den normalen Desktop Benutzer designt, das ist schon klar. ZFS spielt schon in einer anderen Liga. Heute habe ich mich weiter eingearbeitet und mit Schnappschüssen und Replikationen geübt. Klappt schon ganz gut. Allerdings kann ich die Leistung bei weitem nicht ausschöpfen. Und mal schnell einen Schnappschuß vom Homeverzeichnis machen, bevor ich etwas Neues experimentelles installiere, das geht ja leider nicht, weil die erste Platte ja eine SSD ist, auf der Debian mit ext4 installiert ist. Aber zur Datensicherung auf der zweiten Platte ganz gut zu gebrauchen. Ob sich der Aufwand des Lernens wirklich lohnt, weiss ich nicht, aber es war halt auch ein bißchen Neugier im Spiel und dümmer wird man ja auch nicht.

Gruß ralli

[bluestar]

Aha ich verstehe. HDD mit mehreren Partitionen aufteilen und entsprechend nutzen.

Nein nicht ganz, ich habe bei meinen ZFS SSDs/HDDs einfach nur eine Partitionstabelle mit einer Partition.

[ralli]

Aha ich verstehe. HDD mit mehreren Partitionen aufteilen und entsprechend nutzen.

Nein nicht ganz, ich habe bei meinen ZFS SSDs/HDDs einfach nur eine Partitionstabelle mit einer Partition.

Ok, dann habe ich es ja richtig gemacht, nämlich genau wie Du.

Gruß ralli

[ralli]

Kleiner Nachtrag, ZFS funktioniert auch unter Testing einwandfrei, habe es gerade ausprobiert. Gleiche Installation.

Gruß ralli