Zitat von
Penthesilea
[Copy-on-Write]
1)"Müllt" sich so ein System auf lange Sicht nicht selbst zu? Neue Dateien und Änderungen an vorhandenen Dateien werden ja gleichermaßen in leere Speicherbereiche geschrieben.
Normalerweise nicht, da die Verwaltungsstrukturen nach dem erfolgreichen Schreiben aktualisiert werden. Am einfachsten versteht man es, wenn man es mit der Arbeitsweise klassischer Dateisysteme vergleicht. Wenn ich normalerweise eine Datei verändere und speichere, dann sucht das Dateisystem die Sektoren auf der Platte, in denen die Datei liegt und schreibt die Änderungen da rein. Geht dabei etwas schief, ist die Datei ggf. inkonsistent. Ein Teil der Änderungen ist vielleicht schon geschrieben, ein anderer Teil aber noch nicht. Und die Anwendung, die mit der Datei arbeiten will, kann mit diesen widersprüchlichen Informationen nichts mehr anfangen und meldet einen Fehler (oder steigt gleich aus).
Bei COW dagegen bleibt die Datei erstmal im Original erhalten. Und nur die Blöcke, die sich geändert haben, werden in den freien Bereich der Platte geschrieben. Erst, wenn das geklappt hat, geht das Dateisystem her und biegt die Verweise von den alten Blöcken auf die neuen um. Dabei wird der Speicherplatz der alten Blöcke also freigegeben, denn er ist ja jetzt nicht mehr in den Metadaten referenziert (Ausnahme: s.u.) und entsprechend müllt sich nix zu.
Der Vorteil ist: Wenn jetzt während des Schreibens der Strom ausfällt, ist die Datei hinterher immer noch in einem konsistenten Zustand. Die alten Blöcke sind ja noch da. Das Dateisystem ist nur noch nicht dazu gekommen, die Bezüge zu ändern. Daher ist es immer noch in dem Zustand, in dem es vor dem Stromausfall war.
2) Aufbauen auf meine erste Frage: Die Snapshotfunktion ermöglicht Rollbacks zu diversen früheren Systemzuständen, sofern ein Snapshot angefertigt wurde. Diese Snapshots nehmen, laut diverser QUellen, zum Zeitpunkt der Erstellung keine physischen Speicherplatz in Anspruch, sondern werden erst anschließend "gefüllt", sobald Daten verändert werden, jedoch finde ich nichts darüber, was genau in den Snapshots gespeichert wird.
Und jetzt die Ausnahme von oben. Snapshots nutzen nämlich das COW auf clevere Weise aus. Wenn ich einen Snapshot erzeuge, lege ich einfach eine neue Kopie der Verwaltungsstrukturen (Metadaten) an. Und ich arbeite nun mit dieser Kopie. Ändere ich jetzt eine Datei, werden immer noch neue Blöcke in den freien Bereich geschrieben und anschließend die Bezüge umgebogen. Aber nur die Bezüge in dem Satz Metadaten, mit ich gerade arbeite. Also nur in meinem aktuellen Snapshot. Der alte Snapshot (die alten Metadaten) referenzieren immer noch die ursprünglichen Blöcke. Die werden deshalb auch nicht freigegeben (sie werden ja noch referenziert) und wenn ich auf den alten Snapshot umstelle (sprich, die alten Metadaten lade), dann sehe ich auch wieder die alte Version der Datei. Wechsle ich auf die neuen Metadaten (den neuen Snapshot), sehe ich die neue Version der Datei.
Deshalb nimmt ein Snapshot auch erstmal keinen Speicherplatz weg, abgesehen von dem bisschen, was die neuen Metadaten halt brauchen. Zu dem Zeitpunkt sind die beiden ja identisch und verweisen auf die selben Blöcke. Je mehr ich mit neuen Snapshots arbeite und ändere, umso driftet der Datenbestand auseinander und desto mehr füllt sich die Platte. Da kann sich also tatsächlich mal was zumüllen. Dann muss ich eventuell irgendwann einen alten Snapshot löschen. Was ich einfach dadurch mache, dass ich diesen alten Satz Metadaten lösche. Dann sind die Blöcke, die nur noch von diesem Snapshot benutzt wurden, nirgends mehr referenziert und damit zum Beschreiben wieder freigegeben. Blöcke, die sich der gelöschte Snapshot mit anderen Snapshots geteilt hat (weil sie nie geändert wurden), werden weiterhin von den anderen Snapshots referenziert und daher auch nicht freigegeben.