Was genau sind snapshots (zfs, btrfs) ?

[schwedenmann]

Hallo


Ich habe das bisher nie so rchtig kapiert, aus den Beschreibungen Howos der FS. Was sind , bzw. was speichern snapshots von z.B. zfs oder btrfs ?

Ich hab edas bisher imme rso vesctanden, das das quasi Inhaltsverzeichnisse des FS sind mit links auf die Originaldatei.

mfg
schwedenmann

 

[Scutus]

Hey,

beim initialem Backup werden alle originalen Dateien aus dem zu sichernden System (lokal oder remote) in die ZFS-Struktur kopiert. Dabei hast du in der Regel deine Snapshots nach einem zeitlichen Intervall konfiguriert, z.B.: "Mach jede Stunde einen Snapshot". Falls sich eben in dieser Stunde eine Datei verändert hat, wird diese Datei auf das ZFS kopiert, falls nicht, wird ein symlink auf die bereits im ZFS-System enthaltende Datei erstellt. Somit hast du zu jeder Stunde eine entsprechende Ordnerstruktur von deinem Zielsystem, was kurz Snapshot genannt wird.

Mal ganz grob und sehr vereinfacht...

Grüße,
Scutus

 

[schwedenmann]

snapshots

Hallo

Ok, was aber wenn ich snapshots mache und im filesystem was schiefläuft ?

Da hilft doch kein dann kein snapshot (hier zum Wiederherstelllen der Daten), sondern nur ein stinknormales backup, also eine physische Kopie.

Oder habe ich da wieder was mißverstanden ?

mfg
schwedenmann

 

[bitmuncher]

Ein Snapshot ersetzt kein Backup. Er ist nur dafür da ungewollte Änderungen am Dateisystem rückgängig zu machen, wenn Bedarf besteht.

 

[Scutus]

Ein Snapshot ersetzt kein Backup. Er ist nur dafür da ungewollte Änderungen am Dateisystem rückgängig zu machen, wenn Bedarf besteht.

Wie machst du das, wenn du keine "alte" Kopie der Datei beim Snapshot liegen hast? Es müssen also für Snapshots die Dateien vorliegen - sprich ein Backup...es macht wenig Sinn die beiden Begriffe auseinander zu ziehen.

sondern nur ein stinknormales backup, also eine physische Kopie.

Jap. Das Problem, welches Snapshots beseitigen (wieder sehr vereinfacht gesprochen...) ist folgendes:

Bei einem "normalen" Backup kopierst du einfach alle Daten, die gerade auf dem Zielsystem liegen rüber. Das machst du mehr oder weniger regelmäßig. Dadurch stauen sich logischerweise die Daten auf. Somit hast du früher oder später ein Platzproblem. Irgendjemand hat dann die Idee von inkrementellen - oder auch differenzielle - Backups. Bei beiden kopierst du dann nicht wahllos alle Daten vom Zielsystem zum Backup, sondern nur die geänderten und neuen Daten. Nun kannst du bei inkrementellen Backup-Lösungen natürlich sehr kleine Zeitintervalle angeben, bei denen man eben Snapshots macht - also schaut, ob und was sich geändert hat.

Man hat logischerweise bei jeder Lösung immer eine "physische Kopie". Ansonsten könnte man ja nichts zurückspielen, wenn man die Datei nicht in seinem ZFS hat. D.h. in deinem ZFS liegt die physische Kopie deines Zielsystems. Das Zielsystem - wovon du ja ein Backup erstellen willst - sollte ja nicht auf dem Backup-System liegen...und vor allem auch örtlich möglichst weit getrennt sein.

Der Vorteil, was nun ZFS, etc. bringen: Du musst es nicht selber schreiben. Sie nehmen dir Arbeit ab und bieten dir weitere sehr nette Funktionen an.

Falls sich das ZFS (oder ein anderes Filesystem oder auch meistens die Platte) verabschieden sollte, hilft entweder ein Raid, oder noch ein weiteres Backup.

Grüße,
Scutus

 

[bitmuncher]

Kurz gesagt: Bei einem Snapshot wird der Zustand des Dateisystems bzw. Änderungen an diesen Zustand gespeichert. Bei einem inkrementellen Backup wird zuerst ein Full-Backup gemacht und danach nur noch die Dateien, die sich geändert haben. Bei Dateien, die sich nicht geändert haben, wird die jeweilige Datei via Hardlink zum Full-Backup in das aktuelle Backup verlinkt. Da Snapshots nur Zustandsbeschreibungen sind, ersetzen sie keine Backups.

 

[schwedenmann]

snapshots

Hallo


Danke, jetzt sehe ich ein bißchen klarer.
Hier mal die Kommentare lesen, bes. zu zfs + snapshots

Kommentare zu "Welche Software nutzen Sie, um Backups zu erstellen?" - Pro-Linux

da wird mir ganz anders.

mfg
schwedenmann

 

[bitmuncher]

Tja, wer sich auf ZFS-Snapshots als Backups verlässt, der ist verlassen. Bei ZFS funktioniert ein Snapshot üblicherweise so, dass nur Änderungen am Dateisystem im Snapshot registriert werden. Dazu nutzt der Snapshot den sogenannten Hash-Baum (Merkle Tree). Erst wenn eine Datei sich ändert, d.h. ihr Abdruck im Merkle Tree sich ändert, wird die Datei in ihrem vorherigen Zustand im Snapshot gespeichert (Copy-on-write). Daher ist der Zustand eines Snapshots nur wiederherstellbar, wenn das original Dateisystem zu diesem Snapshot noch existiert. Und das ist auch der Grund, warum Snapshots üblicherweise recht klein sind und im Laufe der Zeit (mit zunehmender Anzahl der Änderungen) wachsen.

 

[schwedenmann]

snapshots

Hallo

@bitmuncher

Daher ist der Zustand eines Snapshots nur wiederherstellbar, wenn das original Dateisystem zu diesem Snapshot noch existiert.

Das war es, was ich wissen wollte, denn bei den ganzen howtos im Netz wird immer so getan, als ob ein snapshot die Relevanz eines "echten backup" hätte. Habe da mal bei youtube ein Video über FreeNAS von einem Admin aus Süddeutschland gesehen, für den waren zfs + snapshost bei einem NAS eine tolle, sichere Sache, der hat snapshots über allen Klee gelobt.

Video müßte ich jetzt raussuchen, ist schon mehrere Monate her.

mfg
schwedenmann

 

[bitmuncher]

Spätestens wenn man bei Oracle in der ZFS-Doku Dinge liest wie das folgende, sollte man sich fragen, wie eine quasi leere "Kopie" ein Backup sein soll:

Snapshots can be created almost instantly, and they initially consume no additional disk space within the pool.

Snapshots sind aber dennoch brauchbar um daraus Backups zu erstellen. Nämlich dann, wenn man die Daten aus dem Snapshot kopiert. So kann man sicherstellen, dass sie sich nicht während des Kopiervorgangs verändern. Daher ist die Backup-Strategie über Snapshots im Ablauf immer so: 1. Snapshot erstellen, 2. Daten aus dem Snapshot kopieren, 3. Snapshot verwerfen, damit der nicht anfängt unnötig Platz zu fressen.

 

[Scutus]

Daher ist der Zustand eines Snapshots nur wiederherstellbar, wenn das original Dateisystem zu diesem Snapshot noch existiert.

Bei zfs werden die Datenblöcke nicht gelöscht, falls dazu ein Snapshot existiert...somit existieren zu jedem existenten Snapshot auch die jeweiligen Daten.

...sollte man sich fragen, wie eine quasi leere "Kopie" ein Backup sein soll

Ein Snapshot ist keine Kopie, sondern eine Verlinkung (oder Sammlung) der auf dem zfs (was ja sogar das Filesystem ist!) liegenden Datenblöcke. Somit macht es für einen neuen Snapshot keinen Sinn Datenblöcke zu halten, da dieser auf die aktuellen Datenblöcke zeigt - die ja noch nicht gelöscht werden sollen.

Eventuell mal zwei Beispiele:
1) zfs auf Ziel, zfs auf Backup: Dazu gibt es von zfs eingebaute Übertragungsmethoden, zudem einige Skripte, die das Ganze extrem vereinfachen. Prinzipiell ist das ZFS-Backup ein Slave vom ZFS-Ziel - ähnlich wie bei mysql.

2) anderes Filesystem auf Ziel, zfs auf Backup. Kopiere Dateien auf das Backup (z.B. rsync). ZFS kümmert sich jetzt eigenständig um die Snapshots. Somit überschreibt man bei rsync schlicht das alte Backup...und ZFS liefert recht eigenständig die zeitliche Komponente.

Wer mehr lesen möchte kann sich ja mal die Artikelsammlung zu ZFS on Linux durchlesen...

Btw.: ZFS bietet auch interne Redundanz um die Datenblöcke zu schützen - Strichwort zraid.

EDIT: Zu den Datenblöcken: Jeder Datenblock wird als Hash dargestellt. Datenblöcke werden dann innerhalb eines Baumes (wie bitmuncher schon geschrieben hat) zusammengefasst. Diese Hashsammlung wird dann als Snapshot gespeichert. Falls ein Datenblock via Copy on Write erneuert wird, behält sich das ZFS-Filesystem den alten Datenblock. Dieser alte Datenblock wird so lange gehalten, bis es keinen Snapshot mehr gibt, der dessen Hash in seinem Baum hält. Falls das der Fall wird, wird der Datenblock als löschbar markiert. Danach wird zuerst die leere Festplatte weiterbeschrieben. Erst sobald diese voll ist, werden die löschbaren Datenblöcke endgültig von der Platte genommen. Dadurch kommt es zur Fragmentierung...aber das ist ein anderes Thema.

Grüße,
Scutus

 

[bitmuncher]

Bei zfs werden die Datenblöcke nicht gelöscht, falls dazu ein Snapshot existiert...somit existieren zu jedem existenten Snapshot auch die jeweiligen Daten.

Falsch. Wenn das Dateisystem Fehler aufweist, muss dies noch lange nicht den Space des Snapshots betreffen. Somit ist keineswegs immer sicher, dass zu einem Snapshot auch das zugehörige Dateisystem noch existiert. Kopiert man nur den Snapshot, also den gespeicherten Merkle Tree und die veränderten Daten, hat man kein Backup. Und daher sind Snapshots keine Alternative zu Backups. Sie können lediglich genutzt werden um Backups daraus zu erstellen.

Ein Snapshot ist keine Kopie, sondern eine Verlinkung (oder Sammlung) der auf dem zfs (was ja sogar das Filesystem ist!) liegenden Datenblöcke. Somit macht es für einen neuen Snapshot keinen Sinn Datenblöcke zu halten, da dieser auf die aktuellen Datenblöcke zeigt - die ja noch nicht gelöscht werden sollen.

Wieder falsch. Im Prinzip ist ein Snapshot lediglich ein "Merken" des Systems wie der Zustand eines Dateisystems zu einem bestimmten Zeitpunkt war. Anders gesagt: Der Zustand des Merkle Tree zum Zeitpunkt des Snapshots wird gespeichert. Wird nun das zum Snapshot gehörende Dateisystem modifiziert, kopiert das System die ursprüngliche Datei in den Snapshot. Diese Technik ist auch bekannt als "copy on write". Mit Verlinkungen hat ein Snapshot absolut nichts zu tun.

Eventuell mal zwei Beispiele:
1) zfs auf Ziel, zfs auf Backup: Dazu gibt es von zfs eingebaute Übertragungsmethoden, zudem einige Skripte, die das Ganze extrem vereinfachen. Prinzipiell ist das ZFS-Backup ein Slave vom ZFS-Ziel - ähnlich wie bei mysql.

Ich vermute du beziehst dich dabei auf die Mechanismen 'zfs send' und 'zfs receive'. Ja, dabei wird eine Kopie des Snapshots erstellt, aber eben auch eine Kopie des dem Snapshot zugrundeliegenden Dateisystems.

Wer mehr lesen möchte kann sich ja mal die Artikelsammlung zu ZFS on Linux durchlesen...

Dann lies es doch bitte.

If a block gets overwritten after it has been snapshotted, it gets copied to the snapshot filesystem. This is possible, because the snapshot is a copy of the hash tree at that exact moment. As such, snapshots are super cheap, and unless the snapshotted blocks are overwritten, they take up barely any space.

Genau das, wovon ich die ganze Zeit rede. Es wird lediglich ein Hash-Baum gespeichert (bekannt als Merkle Tree oder Hash Tree). Und sobald sich im ursprünglichen Dateisystem etwas ändert, wird die original Datei im Zustand vor der Veränderung in den Snapshot kopiert. Daher auch der Begriff "copy on write", kopiere bei Veränderung/beim Schreiben. Somit sind Snapshots am Anfang winzig klein und wachsen mit jeder Veränderung, die vorgenommen wird. Dass du im Snapshot alle Dateien sehen kannst liegt lediglich daran, dass das Dateisystem transparent für dich die Zugriffe entweder auf die im Snapshot abgelegten Daten (modifizierte Daten) oder auf das original Dateisystem (nicht modifizierte Daten) leitet. Mit Links hat das nichts zu tun.

 

[bitmuncher]

Nachtrag: Beim Drüberlesen stelle ich fest, dass wir eventuell einfach aneinander vorbei reden. Vielleicht sollten wir erstmal definieren: Was ist der Snapshot? Wie stellt sich der Snapshot für den User dar? Ist das klar, wird vielleicht auch klar, warum es nicht reicht einen Snapshot zu kopieren.

Daher... der Snapshot ist erstmal ein getrenntes Pseudo-Dateisystem, das innerhalb des eigentlichen Dateisystems existiert. Dieses Snapshot-Dateisystem besteht anfangs ausschliesslich aus dem Merkle Tree des Originals. Wird auf eine Datei innerhalb des Snapshot-Dateisystems zugegriffen, leitet der Treiber den Zugriff völlig transparent für den User auf das Original weiter. Wird nun im Original eine Änderung vorgenommen, kopiert der Treiber die ursprüngliche Version der Daten in das Snapshot-Dateisystem und leitet zukünftige Zugriffe auf diese Kopie.
Kopiert man nur den Snapshot, kopiert man faktisch nur den Hash-Baum des Originals. Damit ist ein Zugriff auf die eigentlichen Dateien nicht möglich, sofern diese Snapshot-Kopie nicht in Verbindung mit dem Original verwendet wird.
Da aber der Zugriff auf die Dateien transparent erfolgt, kann man _den Inhalt_ des Snapshots, also das, was der Treiber als Daten dem User präsentiert, natürlich kopieren. In dem Fall kopiert man aber die Daten und nicht den Snapshot. Würde man nur den Snapshot kopieren, hätte man nur einen Hash-Baum, mit dem man im Fall einer Desaster-Recovery nichts anfangen kann.

 

[Scutus]

ah, jetzt verstehe ich was du aussagen willst...

Das Problem zwischen uns scheint zu sein, dass zfs als Dateisystem Snapshots integriert. D.h. wenn jemand über zfs-snapshots redet, dann ist auch zfs als Dateisystem vorausgesetzt.

Falsch. Wenn das Dateisystem Fehler aufweist, muss dies noch lange nicht den Space des Snapshots betreffen. Somit ist keineswegs immer sicher, dass zu einem Snapshot auch das zugehörige Dateisystem noch existiert. Kopiert man nur den Snapshot, also den gespeicherten Merkle Tree und die veränderten Daten, hat man kein Backup. Und daher sind Snapshots keine Alternative zu Backups. Sie können lediglich genutzt werden um Backups daraus zu erstellen.

Okay...wenn man von Fehler ausgeht, dann sind einige Systeme nicht immer sicher. Es stimmt, ein zfs-snapshot alleine macht keinen Sinn - jedoch macht auch keiner nur eine Kopie des Snapshots - weswegen ich auch angenommen hatte, dass ZFS als Ganzes, nicht nur das eine Feature herausgefiltert, betrachtet wird...

Wieder falsch. Im Prinzip ist ein Snapshot lediglich ein "Merken" des Systems wie der Zustand eines Dateisystems zu einem bestimmten Zeitpunkt war. Anders gesagt: Der Zustand des Merkle Tree zum Zeitpunkt des Snapshots wird gespeichert. Wird nun das zum Snapshot gehörende Dateisystem modifiziert, kopiert das System die ursprüngliche Datei in den Snapshot. Diese Technik ist auch bekannt als "copy on write". Mit Verlinkungen hat ein Snapshot absolut nichts zu tun.

Das Wort "Zustand" verwirrt mich hier sehr...ein Merkle Tree ändert nicht seinen Zustand, sondern der Merkle Tree ändert sich. Somit sollte jeder Snapshot seinen eigenen Merkle Tree haben und nicht nur einen Zustand von einem Baum - immerhin müssen die jeweiligen Hashes aktiv neu berechnet werden...Auch das mit den "Verlinkungen" lasse ich hier eigentlich gerne stehen: Falls der Datenblock nicht verändert wurde, dann wird dieser Datenblock als Hash im Baum referenziert - was für mich ein "Link" zu diesem Datenblock ist.

Ich vermute du beziehst dich dabei auf die Mechanismen 'zfs send' und 'zfs receive'. Ja, dabei wird eine Kopie des Snapshots erstellt, aber eben auch eine Kopie des dem Snapshot zugrundeliegenden Dateisystems.

zfs ist das Dateisystem...

Und sobald sich im ursprünglichen Dateisystem etwas ändert, wird die original Datei im Zustand vor der Veränderung in den Snapshot kopiert.

Nein, das macht auch überhaupt keinen Sinn (bei inkrementeller Datensicherung). Diese Datenblöcke können durch mehrere Snapshots referenziert sein, somit müsste man einen Datenblock in jeweils alle Snapshots kopiert werden. Z.B. hast du eine Datei, die ein Jahr unverändert auf dem System liegt, somit dürften alle existierenden Snapshots diese Datei in ihrem Baum durch den selben Hash referenzieren. Diese Datei wird verändert, somit würde jeder Snapshot eine Kopie dieser halten...

Dass du im Snapshot alle Dateien sehen kannst liegt lediglich daran, dass das Dateisystem transparent für dich die Zugriffe entweder auf die im Snapshot abgelegten Daten (modifizierte Daten) oder auf das original Dateisystem (nicht modifizierte Daten) leitet.

Hmm...nachdem ZFS beides ist - Snapshot und Dateisystem - macht diese Unterscheidung nicht wirklich Sinn...

Mit Links hat das nichts zu tun.

Okay...ich hatte das Wort "Link" als Vereinfachung verwendet, zudem wird bei meinen ZFSs in der Shell genau diese "Transparenz" als Links dargestellt...also scheine ich nicht alleine mit dieser Analogie zu sein.

Grüße,
Scutus

P.S.: Eventuell könntest du diese Absolutismen wie "Wieder Falsch." oder auch "Falsch." etwas einschränken. Wissensaustausch sollte doch etwas neutraler geschehen. Wir beiden können mit unseren Aussagen komplett daneben liegen, oder wir können auch beide richtig sein - unter jeweils anderen Aspekten. So gerade bei uns. Du diskutierst das Konzept "Snapshot" am Beispiel ZFS. Jedoch trennst du dabei Snapshot und Dateisystem, was gerade bei ZFS nicht der Fall ist. Dadurch erlangen deine Aussagen unter der alleinigen Betrachtung von Snapshots einen Wahrheitsgehalt, jedoch bei der Gesamtlösung ZFS verlieren sie den Blick zum Ganzen. Dadurch sind deine Aussagen weder falsch noch richtig, man muss sie eben nur in den richtigen Kontext werfen. Schonmal Danke!

 

[Scutus]

Nachtrag zum Nachtrag:

Daher... der Snapshot ist erstmal ein getrenntes Pseudo-Dateisystem, das innerhalb des eigentlichen Dateisystems existiert.

Und genau das behebt ZFS...

Dieses Snapshot-Dateisystem besteht anfangs ausschliesslich aus dem Merkle Tree des Originals. Wird auf eine Datei innerhalb des Snapshot-Dateisystems zugegriffen, leitet der Treiber den Zugriff völlig transparent für den User auf das Original weiter. Wird nun im Original eine Änderung vorgenommen, kopiert der Treiber die ursprüngliche Version der Daten in das Snapshot-Dateisystem und leitet zukünftige Zugriffe auf diese Kopie.
Kopiert man nur den Snapshot, kopiert man faktisch nur den Hash-Baum des Originals. Damit ist ein Zugriff auf die eigentlichen Dateien nicht möglich, sofern diese Snapshot-Kopie nicht in Verbindung mit dem Original verwendet wird.
Da aber der Zugriff auf die Dateien transparent erfolgt, kann man _den Inhalt_ des Snapshots, also das, was der Treiber als Daten dem User präsentiert, natürlich kopieren. In dem Fall kopiert man aber die Daten und nicht den Snapshot. Würde man nur den Snapshot kopieren, hätte man nur einen Hash-Baum, mit dem man im Fall einer Desaster-Recovery nichts anfangen kann.

Prinzipiell stimme ich da voll zu. Jedoch tickt zfs etwas anders - hier müssen keine Daten kopiert werden, da ZFS bereits das originale Dateisystem und das Snapshot-System in einem ist.

Grüße,
Scutus

 

[bitmuncher]

jedoch macht auch keiner nur eine Kopie des Snapshots - weswegen ich auch angenommen hatte, dass ZFS als Ganzes, nicht nur das eine Feature herausgefiltert, betrachtet wird...

Unterschätze nicht die Dummheit der Anwender. Ich war durchaus schon in Unternehmen, wo der Admin nur den Snapshot-Space kopierte und der Meinung war er hätte damit ein vollwertiges und platzsparendes Backup.

Das Wort "Zustand" verwirrt mich hier sehr...ein Merkle Tree ändert nicht seinen Zustand, sondern der Merkle Tree ändert sich. Somit sollte jeder Snapshot seinen eigenen Merkle Tree haben und nicht nur einen Zustand von einem Baum - immerhin müssen die jeweiligen Hashes aktiv neu berechnet werden...
Auch das mit den "Verlinkungen" lasse ich hier eigentlich gerne stehen: Falls der Datenblock nicht verändert wurde, dann wird dieser Datenblock als Hash im Baum referenziert - was für mich ein "Link" zu diesem Datenblock ist.

Der Merkle Tree ist nur eine Zustandsbeschreibung. Er gibt keine Auskunft darüber welche Daten enthalten sind. Ein Link hingegen ist ein Datenblock, der auf eine spezielle Inode verweist. Im Merkle-Tree wird aber nicht nur auf Inodes verwiesen sondern auf alle Datenblöcke, unabhängig davon ob sie von einer Inode referenziert werden oder nicht.

somit müsste man einen Datenblock in jeweils alle Snapshots kopiert werden.

Und genau das geschieht. Mir ist durchaus bewusst, dass hier shared data durchaus Abhilfe schaffen kann, aber meine Erfahrung ist, dass dies in der Praxis nicht der Fall ist. Ich hatte schon mit einem System zu tun, dessen Plattendurchsatz irgendwann fast dicht war, weil es zu viele Snapshots hielt, in die ständig bei Änderungen Daten kopiert wurden. Ist zwar schon einige Jahre her, aber mich würde wundern, wenn das in ZFS tatsächlich mittlerweile geändert wurde. Vor allem glaube ich nicht, dass Oracle in seiner ZFS-Doku dann noch immer davon reden würde, dass die Daten "in den Snapshot" kopiert werden und nicht "in einen shared space, den sich die Snapshots teilen". Aber ich müsste im Treiber nachschauen wie das in der Realität mittlerweile gelöst ist.

Okay...ich hatte das Wort "Link" als Vereinfachung verwendet, zudem wird bei meinen ZFSs in der Shell genau diese "Transparenz" als Links dargestellt...also scheine ich nicht alleine mit dieser Analogie zu sein.

Das mag der Grund sein, warum die Solaris-Leute über die Linux-Implementierung immer so fluchen. Links erstellt man z.B. mit inkrementellen rsync-Backups, aber nicht mit Snapshots. Denn Links sind per Definition spezielle Dateien, die anstelle von Daten einen Datenpfad enthalten. Und diese gibt's in Snapshots nicht.

Du diskutierst das Konzept "Snapshot" am Beispiel ZFS.

Ja, ich benutze ZFS hier aber nur als ein Beispiel. Die Frage bezog sich aber allgemein auf Snapshots. Man könnte auch LVM oder sonstiges als Beispiel nehmen. Und spätestens dann wird es wichtig zwischen dem eigentlichen Dateisystem und dem Snapshot zu unterscheiden. So weist man z.B. bei LVM jedem Snapshot üblicherweise eine feste Grösse zu und es landen gesonderte Dateien mit dem Inhalt des Snapshots im Dateisystem. Wird diese definierte Grösse überschritten, werden Schreibzugriffe auf das Dateisystem gestoppt, da die Originale nicht mehr in den entsprechenden Snapshot kopiert werden können, womit weitere Änderungen am Original zu einer Inkonsistenz des Snapshots führen würden. Dort findet also eine wesentlich striktere Trennung zwischen Snapshot und Dateisystem statt als bei ZFS. Vielleicht war einfach das Beispiel ungünstig gewählt um Snapshots allgemein zu beschreiben. Bei ZFS verschwimmt die Grenze aus Anwendersicht etwas. Da gebe ich dir Recht. Aus Sicht des Systems wird aber für den Snapshot ein eigenes Dateisystem erstellt, womit dort also schon eine strikte Trennung stattfindet, die der Treiber lediglich für den Anwender "unsichtbar" macht.

Eventuell könntest du diese Absolutismen wie "Wieder Falsch." oder auch "Falsch." etwas einschränken. Wissensaustausch sollte doch etwas neutraler geschehen.

Ja, hab mich etwas mitreissen lassen. Tut mir Leid. Einfach nicht persönlich nehmen.