Dotcache

Wozu Dotcache?

Viele Programme speichern häufig wechselnde, aber dauerhafte Informationen in SQLite-Datenbanken (oder Textdateien) im Home-Verzeichnis des aufrufenden Benutzers ab. Lagern diese Homeverzeichnisse auf einem Fileserver, dann führt die große Anzahl kleiner synchroner Schreiboperationen, die die Aktualisierungen dieser Datenbanken nach sich ziehen, zu einer enormen Schreibbelastung auf dem Server. Abgesehen davon gibt es Probleme bei Verwendung von SQLite in Zusammenhang mit NLM. Selbst, wenn die Homeverzeichnisse auf einer lokalen Festplatte liegen, verhindern die Schreibzugriffe, daß die Platte heruntergedreht werden kann. Dotcache geht dieses Problem an, indem es die Originaldateien oder -Verzeichnisse auf (eventuell flüchtigen) lokalen Speicher umlenkt, diese aber periodisch in ein Backup-Verzeichnis in nichtflüchtigem Speicher sichert. Es kann sogar damit umgehen, daß sich derselbe Benutzer auf mehreren Computern gleichzeitig anmeldet und dabei dasselbe (NFS-gemountete) Homedirectory benutzt.

Funktionsweise

Dotcache verwaltet (wenn es von pam_dotcache, s. u. aufgerufen wird), (grafische Login-)Sitzungen (sessions) und behandelt darin Objekte (also Dateien oder Verzeichnisse), die sich normalerweise im Homedirectory befinden. Für jedes Objekt benutzt es drei verschiedene Stellen: Den originalen Ort, eine Sicherungskopie (auch im Homeverzeichnis) und einen Cache auf lokalem, möglicherweise flüchtigem Speicher.

Will man mehrere Sitzungen gleichzeitig auf verschiedenen Rechnern unterstützen, dann darf nur eine darunter lokal durchgeführte Änderungen an den Originalort zurückkopieren (ansonsten bräuchte man einen Kommunikationskanal zwischen den einzelnen Rechnern). Eine solche Sitzung wird als primär bezeichnet, alle anderen als sekundär – deren Änderungen an von Dotcache behandelten Objekten sind für andere Sitzungen unsichtbar und gehen beim Schließen der sekundären Sitzung verloren.

Einzelheiten

Beim Öffnen der ersten Sitzung (die automatisch primär wird) wird jedes behandelte Objekt vom Original-Ort in ein Backup-Verzeichnis verschoben (dabei wird statt des originalen Pfadnamens ein codierter verwendet, der als Filenamen taugt), dann in den Cache kopiert und anschließend am Originalort ein Symlink dorthin gesetzt. Danach wird ein Hintergrundprozeß (syncer) gestartet, der periodisch den Cache in das Backup synchronisiert. Wird eine Sitzung geöffnet, während bereits eine andere läuft, werden das bestehende Backup und die Symlinks in den Cache weiterverwendet und nur die Objekte vom Backup in den lokalen Cache kopiert. Falls eine der parallel laufenden Sitzungen primär ist, wird die neue Sitzung sekundär und wird deshalb den Cache weder periodisch noch beim Schließen in das Backup synchronisieren. Anstelle des syncers wird ein pinger gestartet, der periodisch diese Sitzung als noch aktiv kennzeichnet. Beim Schließen einer primären Sitzung wird die Hintergrundsynchronisation gestoppt und noch einmal explizit der Cache ins Backup synchronisiert. Beim Schließen einer sekundären Sitzung wird der pinger gestoppt und ggf. der Cache geleert. Beim Schließen der letzten Sitzung (egal ob diese primär oder sekundär ist) werden die anstelle der Originalobjekte installierten Symlinks entfernt und das Backup an den Originalort zurückverschoben. Danach sieht alles wieder so aus, als wäre Dotcache nie gelaufen.

Da es keinen direkten Kommunikationskanal zwischen den einzelnen Rechnern, auf denen Dotcache läuft, gibt, muß man anderweitig erkennen, wenn eine Sitzung auf einem anderen Rechner zwar noch eingetragen, aber nicht mehr aktiv ist (zum Beipsiel, weil der betreffende Rechner abgestürzt ist). Derartige Sitzungen werden als „stale“ bezeichnet und, wenn sie erkannt werden, als solche deklariert. Genauer gesagt sucht das Öffnen einer Sitzung also zunächst nach solchen Kandidaten, zuerst lokal, d.h. solchen, die angeblich auf dem betreffenden Rechner laufen, aber entweder nicht lokal eingetragen sind oder wo der zugehörige Hintergrundprozeß (syncer oder pinger) nicht läuft; das ist ohne Zeitaufwand leicht zu erkennen. Danach wird versucht, als auf anderen Rechnern laufend eingetragene, aber nicht wirklich laufende Sitzungen zu erkennen, indem untersucht wird, ob der Zeitstempel, der eigentlich vom zugehörigen syncer/pinger regelmäßig aktualisiert werden müßte, zu alt ist. Solche Sitzungen werden dann aus der Liste der eingetragenen Sitzungen entfernt. Anschließend wird die neue Sitzung zu einer primären, wenn keine andere wirklich aktive Sitzung primär ist, ansonsten zu einer sekundären. Weiterhin wird festgehalten, ob irgendwelche anderen Sitzungen durch das oben beschriebene Verfahren als „stale“ deklariert wurden. Nachdem sich die neue Sitzung lokal und global eingetragen hat (wobei auf einem Rechner nur eine Sitzung pro Kombination aus Benutzer und Terminal erlaubt ist, da es keine Möglichkeit gibt, zwei Sitzungen auseinanderzuhalten, bei denen beides jeweils identisch ist), wird für jedes zu behandelnde Objekt eine Falluntescheidung getroffen, abhängig vom Vorhandensein von Objekten am Originalort und dem Backup sowie der Frage, ob diese Sitzung die einzige, die einzig wirklich laufende oder eine unter mehreren ist. Dabei wird versucht, aus inkonsistenten Situationen (die z.B. durch den Absturz einer Sitzung entstanden sein können) herauszukommen; gelingt dies nicht, schlägt Dotcache fehl. Die zuerst gestartete Sitzung legt dann die Liste der behandelten Objekte fest und speichert sie ab. Danach wird der zugehörige Hintergrundprozeß (syncer/pinger) gestartet. Beim Schließen der letzten aktiven Sitzung wird eine analoge Fallunterscheidung getroffen, diesmal aufgrund des Vorhandenseins von Objekten im Backup und am Originalort und wieder, soweit möglich eine Fehlerkorrektur versucht.

Ein Hilfsprogramm namens pam_dotcache vereinfacht es, dotcache selber (über pam_exec) beim Öffnen oder Schließen einer Login-Sitzung geeignet aufzurufen. Dabei kann Dotcache auch nur für eine bestimmte Menge von Benutzern aufgerufen (oder gerade nicht aufgerufen) werden. Momentan werden nur grafische Logins behandelt.

Implementation und Abhängigkeiten

Sowohl dotcache als auch pam_dotcache sind in POSIX-Shell geschrieben. Zusätzlich zu den Standard-POSIX-Utilities werden lediglich ein find, das die -mmin-Option unterstützt, sowie rsync benötigt.

Verfügbarkeit

Dotcache gibt es sowohl als tar.gz- und als dpkg-Datei unter einer 2-Clause-BSD-artigen Lizenz.