Autor: andreas

Warum Snapshots nur temporär verwendet werden sollten

· · 0 Kommentare

Snapshots sind eine tolle Sache: einen Snapshot erstellen, etwas ausprobieren und entweder wird das Ergebnis für die Ewigkeit konserviert (indem der Snapshot dauerhaft in die virtuelle Maschine übernommen wird) oder es geht zurück auf den Stand des Snapshots, weil man die Änderung nicht behalten möchte.

Da Snapshots sowohl Speicherplatz benötigen als auch Leistung kosten sollte darauf geachtet werden, sie lediglich temporär einzusetzen.

Hier ein an manchen Stellen vereinfachter Erklärungsversuch, die verwendeten Farben bedeuten folgendes:

Ausgangsszenario

Eine virtuelle Maschine speichert ihre Festplatte in einer Datei "Festplatte" (dazu kommt noch die ein oder andere Verwaltungsdatei, diese sind aber für die Betrachtung unerheblich). Diese Festplatte ist in viele Blöcke einer festen Größe unterteilt, in der die Daten liegen.

Diese Datei hat eine maximale Größe, welche der für die Festplatte festgelegten Kapazität entspricht. Sämliche Lese- und Schreibzugriffe finden innerhalb der Datei "Festplatte" statt.

Snapshot "Snapshot 1"

Nun wird ein Snapshot "Snapshot 1" angelegt. Ab diesem Moment wird auf die Datei "Festplatte" nur noch lesend zugegriffen, alle Änderungen die Blöcke der Festplatte betreffend (neue Dateien, geänderte Dateien etc ...) werden in der Datei "Snapshot 1" gespeichert.

Nach einiger Zeit der Nutzung ergibt sich folgendes Bild:

Für jeden Lesezugriff muß die virtuelle Maschine nun schauen, ob sie einen angefragten Block aus der Datei "Festplatte" (Blöcke 2, 4 und 5) oder aus der Datei "Snapshot 1" (Blöcke 1, 3, 6, 7 und 8) nehmen muß.

Mit jedem Schreibzugang, der einen in "Snapshot 1" noch nicht geänderten Block betrifft, wächst die Datei "Snapshot 1". Im Extremfall, wenn jeder Block der Festplattte geändert wurde, wird die Datei "Snapshot 1" so groß wie die ursprüngliche Datei "Festplatte". Im Beispiel ist der benötigte Platz von ursprünglich 8 Blöcken auf 13 Blöcke angewachsen.

Snapshot "Snapshot 2"

Nun wird ein weiterer Snapshot "Snapshot 2" angelegt. In diesem Moment wird auf die Dateien "Festplatte" und "Snapshot 1" nur noch lesend zugegriffen, alle Änderungen die Blöcke der Festplatte betreffend werden in der Datei "Snapshot 2" gespeichert.

Nach einiger Zeit der Nutzung ergibt sich folgendes Bild:

Für jeden Lesezugriff muß die virtuelle Maschine nun schauen, ob sie einen angefragten Block aus der Datei "Festplatte" (Block 2), der Datei "Snapshot 1" (Block 7) oder der Datei "Snapshot 2" (Blöcke 1, 3, 4, 5, 6 und 8) nehmen muß.

Mit jedem Schreibzugang, der einen in "Snapshot 2" noch nicht geänderten Block betrifft, wächst die Datei "Snapshot 2". Im Extremfall, wenn jeder Block der Festplattte geändert wurde, wird die Datei "Snapshot 2" so groß wie die ursprüngliche Datei "Festplatte". Im Beispiel ist der benötigte Platz von ursprünglich 8 Blöcken auf 19 Blöcke angewachsen, d.h. es wird bereits mehr als der doppelte Platz der Maximalgröße von "Festplatte" verwendet.

Problematik

Wenn sich ein Block oft ändert, wird für diesen nun auch dreifach Speicherplatz belegt: in der Datei "Festplatte", in der Datei "Snapshot 1" und in der Datei "Snapshot 2".

Bei Lesevorgängen muß immer geschaut werden, in welcher der drei Dateien die aktuelle Version des Blocks zum Zurückliefern vorhanden ist.

Löschen von "Snapshot 1"

Wenn man nun sicher ist, daß alles, was zu dem Zeitpunkt, als "Snapshot 2" erstellt wurde funktioniert, kehrt man i.d.R. nie wieder zu "Snapshot 1" zurück.

Als Konsequenz daraus löscht man in der Verwaltungsoberfläche der Virtualisierungssoftware "Snapshot 1". Die Virtualisierungssoftware überträgt alle Blöcke aus "Snapshot 1" zurück an die entsprechenden Stellen von "Festplatte" (Blöcke 1, 3, 6, 7 und 8) und löscht anschließend die Datei "Snapshot 1".

Als Ergebnis ergibt sich folgendes Bild:

Die Leistung wird besser, weil bei Lesezugriffen nur noch geschaut werden muss, ob ein Block aus "Festplatte" (Blöcke 2 und 7) oder "Snapshot 2" (Blöcke 1, 3, 4, 5, 6 und 8) gelesen werden muß und der Speicherplatz, den die Datei "Snapshot 1" bisher benötigt hat, ist wieder verfügbar. Im Beispiel ist der benötigte Platz von 19 Blöcken auf 14 Blöcke geschrumpft.


Hörenswert #25: Smith/Kotzen - Taking My Chances

· · 0 Kommentare

Glücklicherweise ohne jegliches "Supergroup"-Marketinggeschwafel kommt die Veröffentlichdung von Smith/Kotzen aus, dem gemeinsamen Projekt von Adrian Smith und Richie Kotzen.

Das Album wurde von den beiden weitestgehend im Alleingang aufgenommen, sogar für das Schlagzeug wurde nur bei einigen wenigen Songs auf "externe" Hilfe zurückgegriffen.


John Lawton R.I.P.

· · 0 Kommentare

John Lawton & Uriah Heep

Am 29. Juni 2021 ist John Lawton verstorben. Bekannt wurde er vor allem als Sänger von URIAH HEEP, auch wenn er mit zahlreichen anderen Bands wie z.B. den The Les Humphries Singers und LUCIFER'S FRIEND unterwegs war.

Zu seinen beeindruckendsten Frühwerken gehört die Live-Performance bei der (einzigen) Aufführung von Roger Glovers "The Butterfly Ball and the Grasshopper's Feast" 1975 in London, bei der er mehr als würdig Ronnie James Dio vertrat.

Das Foto wurde am 8. Mai 2013 in der alten Seilerei in Mannheim aufgenommen, als John Lawton nochmals für einige Konzerte ans Mikrofon von URIAH HEEP zurückkehrte.

R.I.P.


UFO 2006-07-29 Bildergalerie

· · 0 Kommentare

UFO am 29. Juli 2006 beim Rock Of Ages Festival in Seebronn


Hörenswert #24: Phoebe Bridgers - Funeral

· · 0 Kommentare

"Weniger ist mehr" gekonnt umgesetzt: Phoebe Bridgers "Funeral", aufgezeichnet im Rahmen der NME Basement Sessions.