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.

Nach dem Update von Nextcloud 21.0.2 auf 21.0.3 lief das "occ"-Kommando auf einen Fehler:

$ php occ upgrade
An unhandled exception has been thrown:
OC\HintException: [0]: Memcache \OC\Memcache\APCu not available for local cache (Is the matching PHP module installed and enabled?)

Keine Ahnung, warum dies bis einschließlich Nextcloud 21.0.2 reibungslos funktioniert hat, die Lösung fand sich aber recht schnell in der Nextcloud-Dokumentation:

Der Datei "/etc/php/7.3/cli/php.ini" musste der Eintrag

apc.enable_cli=1

hinzugefüht werden, dann war die Ausführung des "occ"-Kommandos wieder probemlos möglich.

Alternativ sollte lt. Dokumentation auch das Hinzufügen des Parameters

--define apc.enable_cli=1

zur Kommandozeile ausreichen.

Auch wenn global ein helles Thema gewählt ist, können Anwendungen (wie z.B. "Eye of Gnome") trotzdem ein dunkles Schema verwenden, ohne dem Benutzer eine diesbezügliche Wahlmöglichkeit zu bieten.

Für diese Anwendungen lässt sich die gewünschte Darstellung  erzwingen, in dem das  Thema mitsamt Variante dem Programmaufruf vorangestellt wird:

$ GTK_THEME=Materia-light-compact:light eog

Beim Versuch eine Oracle-Datenbank zu patchen, hat OPatch den Prerequisite check mit der Fehlermeldung "CheckActiveFilesAndExecutables" abgebrochen:

Prerequisite check "CheckActiveFilesAndExecutables" failed.
The details are:

Following active files are not used by opatch process :
E:\pfad_zu_oracle\18.0.0\jdk\jre\bin\vcruntime140.dll

Der einfachste Weg, herauszufinden, welcher Prozess die Dateien aktuell benutzt ist "tasklist":

E:\>tasklist -m vcruntime140.dll

Image Name                     PID Modules
========================= ======== ============================================
VGAuthService.exe             2232 VCRUNTIME140.dll

Leider bietet Windows keine Möglichkeit, einen Dienst anhand des Namens der ausführbaren Datei zu identifizieren. In den meisten Fällen kann aber aus dem Namen auf den Dienst geschlossen werden, hier von "VGAuthService.exe" auf den Dienst "VGAuthService".

Nach dem Anhalten des Diensts

E:\>net stop VGAuthService

The VMware Alias Manager and Ticket Service service was stopped successfully.

E:\>tasklist -m vcruntime140.dll

INFO: No tasks are running which match the specified criteria.

lässt sich OPatch ohne weitere Probleme ausführen.

Wer Ursachenforschung betreiben möchte, sollte sich den Pfad des betroffenen Systems genauer ansehen. Mit großer Wahrscheinlichkeit hat sich Oracle am Anfang des Pfads verewigt, so daß DLLs aus dem Oracle-Verzeichnis statt der ursprünglich bei der Installation mitgelieferten DLLs verwendet werden.

Seit ein paar Tagen ist Sublime Text 4 erhältlich. Leider hat sich der Hersteller entschlossen, diese Tatsache im entsprechenden Dialog nicht weiter zu erläutern:

Das böse Erwachen kommt nach der Installation, falls die vorhandene Lizenz älter als drei Jahre ist: mit Erscheinen von Sublime Text 4 hat der Anbieter das zu Grunde liegende Lizenzmodell geändert, so daß eine kostenpflichtige Lizenzverlängerung fällig wird. Der Preis für die Verlängerung ist mit $70 recht happig, die bisher vorhandene Lizenz wird lediglich mit $10 angerechnet.

Ein ausführlicherer Dialog wäre wünschenswert gewesen - nicht nur mit einem Hinweis, daß es sich um einen Versionswechsel handelt, sondern vor allem mit einem Hinweis, daß diese Aktualisierung u.U. kostenpflichtig ist.

Wer die Update-Prüfung deaktivieren möchte, kann dies in der "Preferences.sublime-settings" tun. Hier genügt ein

"update_check": true

damit nicht bei jedem Start des Editors ein entsprechender Hinweis erscheint.