Linux Vserver nutzt daher eine andere Technik: Unification und Copy-on-Write-Link-Breaking. Zunächst werden die Teilbäume der virtuellen Server durch Hardlinks vereinigt. Das Schreiben entfernt den Hardlink und setzt die geänderte Datei ein.
Vereinigung und Copy-on-Write-Link-Breaking
Liegen die Verzeichnisse der virtuellen Server in einem Dateisystem, kann der Admin mit Hilfe des Werkzeugs »vhashify« identische Dateien in einem zentralen Verzeichnis zusammenfassen und in den Vservern durch Hardlinks ersetzen. Somit sind die Dateiobjekte tatsächlich nur einmal vorhanden und es wird Speicherplatz gespart. Ein schreibender Zugriff darf sich natürlich nur im ausführenden Vserver auswirken.
Die Lösung heißt Copy-on-Write-Link-Breaking (COWLB). Der Hardlink auf das zentrale Verzeichnis wird dabei entfernt, die Datei durch die geänderte Kopie ersetzt. COWLB ist allerdings erst ab der Entwicklerversion 2.1.0 in den Vserver-Patches enthalten.
Die Technik lässt sich auch auf beliebige Verzeichnisse anwenden, wie das folgende Beispiel verdeutlicht. Die Datei »x« ist in den Verzeichnissen »/vservers/a0[12]« vorhanden:
gs vservers # ls -li a0[12]/x 685511 -rw-r--r-- 1 root root 942 Jan 17 07:12 a01/x 685514 -rw-r--r-- 1 root root 942 Jan 17 07:12 a02/x
Der folgende Aufruf ersetzt die Datei durch eine Kopie mit dem Inode 122620. Zu kleine Dateien überspringt er:
gs vservers # /usr/lib/util-vserver /vhashify --manually --destination /vservers/.hash /vservers/a01 exclude /vservers/vexclude
Für die Datei »a01/x« setzt »vhashify« das »immutable« sowie das »unlink«-Flag. Damit kann die Datei nicht mehr verändert, wohl aber können Hardlinks darauf entfernt werden. Dies wird verwendet, um das Copy-on-Write zu implementieren:
gs vservers # showattr a0[12]/x ----UI- a01/x ----ui- a02/x
Damit ist aber noch kein großer Effekt erzielt. Das Verzeichnis »/vservers/a02« wird nun ebenso behandelt:
gs vservers # /usr/lib/util-vserver/vhashify --manually --destination /etc/vservers/.defaults/apps/vunify/hash /vservers/a02 exclude /vservers/vexclude gs vservers # ls -li a0[12]/x 122620 -rw-r--r-- 3 root root 942 Jan 17 07:12 a01/x 122620 -rw-r--r-- 3 root root 942 Jan 17 07:12 a02/x
Nun sind beide Einträge als Hardlink auf den Inode 122620 vorhanden. Verändert man nun die Datei, wird der Hardlink wieder entfernt und die Datei durch eine Kopie ersetzt:
gs vservers # echo "test" >> a02/x gs vservers # ls -li a0[12]/x 122620 -rw-r--r-- 2 root root 942 Jan 17 07:12 a01/x 685511 -rw-r--r-- 1 root root 947 Jan 17 07:14 a02/x
Das Werkzeug »vhashify« vereinigt die beiden Verzeichnisse des Vservers »vs01« und des Clone »vs02«. Die Datei »/vservers/vexclude« beinhaltet eine Ausschlussliste mit Pfaden, deren Vereinigung nicht sinnvoll ist. Dies betrifft beispielsweise inhärent variable Daten wie unter »/var« oder auch Gerätedateien unter »/dev«.
»vhashify« ist der Nachfolger von »vunify« und kann auch dieselbe Standard-Ausschlussliste in »/usr/lib/util-vserver/defaults/vunify-exclude« benutzen. Mit dem Link »ln -s /vservers/.hash /etc/vservers/.defaults/apps/vunify/hash/0« ist die Vereinigung auch noch einfacher als »/usr/lib/util-vserver/vhashify vs02« ausführbar.
Zu erkennen ist, dass das ».hash«-Verzeichnis deutlich größer geworden ist, allerdings scheint sich bei »/vservers/vs0[12]« nichts getan zu haben:
