Re: GrXXe von Snapshots (softupdates)

Nicola Tiling <nt(at)w4w.net> wrote:
>
> > Zum Zeitpunkt X wird ein Snapshot angelegt.
> > Wenn du Daten auf dem dahinterliegenden FS änderst wird das
> > Snapshot größer,
>
> Achso. Ist ja Toll! Der snapshot wird permanent aktualisiert?!

Nein, eigentlich nicht. Der behält seine Daten unverändert
bei. Sein Inhalt ändert sich nach dem Anlegen nicht mehr,
also gibt es nichts, was aktualisiert werden müßte.

Daß der vom Snapshot beanspruchte Platz größer wird, ist
einfach eine Folge davon, daß alte Datenblöcke, die im ak-
tiven Dateisystem gelöscht oder überschrieben wurden, bei-
behalten werden.

Ich beschreibe mal ein einfaches Beispiel. Die Mail wird
jetzt ein wenig lang, aber ich glaube, daß es sehr vor-
teilhaft für das Verständnis von Snapshots ist.

Du hast drei Dateien "A", "B" und "C", die jeweils 10 kbyte
groß sind, in einem aktiven Dateisystem "D". Sie belegen
dort zusammen also 30 kbyte.

A ---> D
B ---> D
C ---> D

Jetzt legst Du einen Snapshot "S" an. In diesem Snapshot
brauchen A, B und C erstmal gar keinen zusätzlichen Spei-
cherplatz, da sie im Snapshot-Image mit den originalen Da-
ten übereinstimmen (grob vergleichbar mit Hardlinks). Es
würde ja keinen Sinn machen, identische Daten doppelt zu
speichern.

A -+-> D
   `-> S

B -+-> D
   `-> S

C -+-> D
   `-> S

D und S sind beide jeweils 30 kbyte »groß«, aber auf dem
Datenträger belegen sie zusammen nur 30 kbyte, nicht etwa
60. Der Snapshot braucht für sich alleine also praktisch
»null kbyte«.

Jetzt änderst Du den Inhalt der Datei A (der Einfachheit
halber die ganzen 10 Kbyte). Hättest Du keinen Snapshot,
würden einfach die ursprünglichen Blöcke der Datei auf
dem Datenträger überschrieben werden, und alles wäre wie
gewohnt. Aber wenn Snapshots existieren, passiert etwas
anderes: Die neuen Daten werden in neue (bisher freie)
Blöcke auf der Festplatte geschrieben. Im Snapshot zeigt
die Datei nach wie vor auf die alten Datenblöcke; dort
öndert sich also nichts. Man nennt diesen Mechanismus
»COW« (copy on write). Der »Hardlink« wird sozusagen auf-
gelöst, und es existeren jetzt zwei verschiedene Versionen
der Datei A auf dem Datenträger; nennen wir die beiden mal
einfach A1 (alt) und A2 (neu).

A2 ---> D
A1 ---> S

B -+-> D
   `-> S

C -+-> D
   `-> S

D und S sind immer noch jeweils 30 kbyte groß, unverändert.
Aber wie Du sehen kannst, werden jetzt auf dem physikali-
schen Datenträger insgesamt 40 kbyte belegt. 20 kbyte sind
immer noch gemeinsam S und D zugeordnet (die Dateien B und
C). 10 kbyte sind nur im aktiven Dateisystem D vorhanden
(der neue Inhalt von A), und 10 kbyte sind exklusiv dem
Snapshot S zugeordnet (der alte Inhalt von A).

Wenn wir jetzt den Inhalt der Datei A erneut verändern,
ändert sich an der Belegung gar nichts. Der Snapshot be-
hält seine alten Daten (A1), und im aktiven Dateisystem
wird A2 einfach überschrieben, da es keinen Snapshot gibt,
der A2 behalten müßte.

Machen wir's interessanter: Legen wir jetzt einen zweiten
Snapshot S2 an (den alten benennen wir mal in S1 um).

A2 -+-> D
    `-> S2

A1 ---> S1

B -+-> D
   +-> S2
   `-> S1

C -+-> D
   +-> S2
   `-> S1

Wie erwartet, ändert das an der Belegung erstmal nichts:
der alte Snapshot S1 bleibt unverändert, und alle Daten des
aktiven Dateisystems D sind jetzt zusätzlich in S2 »ver-
linkt«, sozusagen. Nach wie vor sind physikalisch 40 kbyte
belegt.

Würden wir jetzt die Datei A erneut ändern, hätten wir drei
Versionen (A1, A2, A3) auf dem Datenträger. Das kann man
leicht nachvollziehen, daher will ich das jetzt nicht genau
ausführen. Machen wir daher etwas anderes und ändern die
Datei B. Was passiert jetzt?

A2 -+-> D
    `-> S2

A1 ---> S1

B2 ---> D
B1 -+-> S2
    `-> S1

C -+-> D
   +-> S2
   `-> S1

Wieder werden die neuen Daten (B2) in neue Datenblöcke ge-
schrieben; der alte Inhalt B1 bleibt beiden Snapshots zuge-
ordnet. Der interessante Punkt, den wir jetzt feststellen
können, ist, daß B1 _beiden_ Snapshots zugleich gehört.

Der physikalische Platzverbrauch ist jetzt 50 Kbyte. Davon
sind 10 kbyte (Datei C) dem aktiven Dateisystem und beiden
Snapshots zugeordnet. Weitere 10 kbyte (A2) gehören D und
dem zweiten Snapshot, weitere 10 kbyte (B1) gehören den
beiden Snapshots gemeinsam. Und schließlich gehören 10
kbyte (A1) dem ersten Snapshot allein, und 10 kbyte (B2)
dem aktiven Dateisystem allein.

Spätestens jetzt sollte klar sein, daß es alles andere als
einfach ist, die Frage zu beantworten, wie »groß« ein Snap-
shot ist. ;-)

Wie ist das im obigen Beispiel? Rein virtuell sind beide
Snapshots S1 und S2 jeweils 30 Kbyte groß. S1 enthält A1,
B1 und C. S2 enthält A2, B1 und C. Rein physikalisch
belegen sie aber zusammen nur 20 kbyte, die nicht mehr dem
aktiven Dateisystem zugeordnet sind, nämlich die alten In-
halte A1 und B1. Wobei A1 beiden Snapshots zugeordnet ist,
B1 nur dem zweiten. Würdest Du S2 entfernen, würde also
der Platz von B2 freigegeben, und Du gewännst 10 kbyte
freien Platz. Würdest Du nur S1 entfernen, gewännst Du
gar keinen Speicherplatz, da sowohl A1 als auch B1 noch vom
zweiten Snapshot benötigt werden. Wenn Du beide Snapshots
entfernst, gewinnst Du natürlich den Platz von A1 und B1
zurück (also 20 kbyte).

Man kann also eigentlich nur sagen, wieviel phsyikalischen
Platz _alle_ Snapshots zusammen benötigen. Aber dies auf
einzelne Snapshots aufzudröseln, ist im allgmeinen nicht
möglich, da die Daten teilweise mehreren Snapshots gleich-
zeitig gehören. Bereits bei nur zwei Snapshots wird die
Situation rasch äußerst komplex, wie obiges beispiel er-
ahnen läßt. Zum Glück funktionieren Snapshots transparent
für den Benutzer, und man muß sich normalerweise keine Ge-
danken darüber machen, was wo für welchen Snapshot gespei-
chert ist.

Das war jetzt alles natürlich sehr vereinfacht. In der
Praxis ist es noch etwas komplizierter:

 - Snapshots arbeiten nicht dateiweise, sondern auf Block-
   level. Der Vergleich mit den Hardlinks hinkt daher.

 - Bei Fragmenten ist die Verwaltung komplizierter als be-
   schrieben.

 - Snapshots haben einen gewissen Verwaltungsoverhead, der
   zusätzlich etwas Platz benötigt.

Alle Klarheiten beseitigt? :-)

Gruß
   Olli

PS: Das ist übrigens alles nicht FreeBSD-spezifisch. Das
Funktionsprinzip von UFS-Snapshots unter Solaris oder von
WAFL-Snapshots auf NetApp-Filern ist genau dasselbe.

-- 
Oliver Fromme,  secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing
Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd
Any opinions expressed in this message may be personal to the author
and may not necessarily reflect the opinions of secnetix in any way.
"C++ is over-complicated nonsense. And Bjorn Shoestrap's book
a danger to public health. I tried reading it once, I was in
recovery for months."
        -- Cliff Sarginson
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message