Lagert ein wichtiges Dokument auf einem Fileserver, den der Client gerade nicht erreicht, dann braucht der User Kopien oder ein automatisches Offline-Filesystem. Die Autoren haben OFS entwickelt, das vorhandene Netzwerk-Dateisysteme entsprechend aufrüstet .

Auf der Reise zur Konferenz im Zug noch schnell eine Präsentation vervollständigen oder die nächsten Berichte im Flugzeug vorbereiten – solcherlei Fernarbeit ist heute an der Tagesordnung. Das Problem dabei: Gemeinsam genutzte Dateien liegen meist auf einem Fileserver in der Firma oder der Uni und auch die neuen Dokumente sollen dort wieder landen. Doch ist es weder möglich (Verfügbarkeit) noch sinnvoll (Kosten, Bandbreite), immer alle Dateien online zu bearbeiten.

Kopie nötig

Die Folge: Der Anwender kopiert die Daten auf sein Notebook, unterwegs bearbeitet er sie und nach der Rückkehr in die Firma sichert er alles wieder zurück. Schnell verliert er dabei den Überblick, vergisst einzelne Files oder überschreibt zwischenzeitliche Änderungen eines Kollegen, ohne das Malheur zu bemerken.

Unter Windows schaffen so genannte Offline Files Abhilfe (siehe Kasten “Ähnliche Ansätze”). Es gibt aber ein neues Projekt, das auch unter Linux ähnliche Funktionen anbietet: OFS, das Offline-Filesystem [1]. Die Abkürzung steht auch für Ohm-Filesystem, da OFS als Projekt an der Georg-Simon-Ohm-Hochschule Nürnberg entstand.

Online, offline – egal

Der Ansatz ist einfach: Der Benutzer bestimmt zunächst die Verzeichnisse, die er unterwegs mitnehmen möchte. Deren Inhalt kopiert das Offline-Dateisystem in einen Cache auf der lokalen Festplatte. Selbst wenn keine Verbindung mehr zum Server besteht, scheint es für den Benutzer, als würde er weiterhin auf dem Netzwerk-Dateisystem arbeiten. In Wirklichkeit greift er jedoch auf die Kopien im Cache zu. Das bedeutet: Alle Pfade bleiben gleich, egal ob mit oder ohne Verbindung zum Netzwerk. Ist die Verbindung wiederhergestellt, stößt OFS automatisch eine Reintegration an, die alle Änderungen auf den Server schreibt.

OFS ist kein Netzwerk-Dateisystem im eigentlichen Sinne, vielmehr stellt es eine Schicht zwischen dem Netzwerk-Dateisystem (etwa NFS oder Samba) und der Sicht des Benutzers dar. Sie dient als Weiche zwischen Netzwerk-Share oder Cache und erledigt die Synchronisation. Damit lässt sich OFS mit jedem Filesystem kombinieren. Die Trennung von Netzwerk-Dateisystem und Offline-Fähigkeit unterscheidet OFS von früheren Ansätzen.

Dank Fuse im Userspace

Der OFS-Code läuft komplett im Userspace. Möglich ist das dank Fuse (Filesystem in Userspace, [2]). Fuse stellt eine Schnittstelle bereit, über die der Kernel Dateizugriffe an Userspace-Programme weiterleitet. Im Wesentlichen besteht Fuse aus dem Kernelmodul »fuse.ko« und der Library Libfuse, beide sind in modernen Linux-Distributionen enthalten. Der VFS (Virtual Filesystem Switch) im Kernel akzeptiert das Fuse-Kernelmodul als Filesystem. Fuse leitet die Aufrufe dann über die Gerätedatei »/dev/fuse« an den OFS-Daemon im Userspace weiter.

OFS bedient sich bei Libfuse und den C++-Bindings des Fusexx-Projekts [3], um die Daten entgegenzunehmen (Abbildung 1). Jede Aktion auf eine Datei oder ein Verzeichnis in einem OFS-Dateisystem führt zu einem Funktionsaufruf via Fuse an den OFS-Daemon, der die Aufgabe bearbeitet.

Abbildung 1: Das Offline-Filesystem OFS benutzt Fuse für die Interaktion mit dem Kernel. Setzt eine Userspace-Task einen Syscall für eine Datei ab, dann bestimmt der VFS (Virtual Filesystem Switch), welches Dateisystem dafür zuständig ist. Fuse delegiert die Aufgabe an den OFS-Daemon.

Das OFS-Projekt besteht neben dem OFS-Daemon noch aus einem Mounthelper und einem Filebrowser-Plugin (Abbildung 2 und Tabelle 1). Das Plugin bildet die Benutzerschnittstelle zum OFS-Daemon. Beide Komponenten kommunizieren via D-Bus miteinander [4]. Dadurch ist es recht einfach möglich, OFS um weitere Filebrowser-Plugins zu erweitern, egal für welchen Desktop. Zudem kann der Benutzer mit OFS über die Extended-Fileattribute von Linux interagieren (siehe auch den Abschnitt “Kommunikation”).

Abbildung 2: Überblick über die Komponenten beim Betrieb eines Offline-Filesystems. Die Bestandteile von OFS sind gelb hinterlegt. Die Plugins für Dolphin und Konqueror kommunizieren via D-Bus mit dem OFS-Daemon, der sowohl über das Filesystem-API, als auch über Fuse mit dem Kernel arbeitet.

Der Mounthelper »mount.ofs« bindet das ferne Filesystem ein, etwa ein Samba-Share, und startet den OFS-Daemon. Der OFS-Daemon greift vom Userspace aus auf das Remote-Filesystem zu. Ganz so wie eine gewöhnliche Applikation nutzt OFS für diese Zugriffe das Standard-Filesystem-API. Damit das reibungslos klappt, hängt der Mounthelper das Remote-Filesystems nicht an der Stelle ein, die der Admin im Aufruf angegeben hat, sondern unter »/var/ofs/remote/URL-Hash«. Am ursprünglichen Mountpoint reagiert Fuse und übergibt die Anfrage an den OFS-Daemon.

Freie Wahl

OFS ist daher unabhängig vom Remote-Filesystem und arbeitet mit jeder beliebigen Implementierung zusammen, solange der Linux-Kernel sie unterstützt. Einige andere Lösungen (siehe Kasten “Ähnliche Ansätze”) implementieren hingegen neue Protokolle und benötigen Eingriffe in die Infrastruktur, etwa geeignete Serversoftware. Die interne Struktur des OFS-Daemon ist Service-orientiert und damit leicht erweiterbar. Für die wichtigsten Funktionen gibt es Manager, die ihrerseits Agent-Klassen verwalten, welche dann die nötige Funktionalität bereitstellen.

Der OFS-Daemon bildet die zentrale Komponente. Im einfachsten Fall leitet er alle Anfragen an das tatsächliche Remote-Filesystem weiter. Er ist aber auch für das Cacheing und die Synchronisation verantwortlich. Aktiviert der Anwender das Cacheing – entweder für das ganze Filesystem oder für einzelne Verzeichnisse -, so erzeugt OFS beim Öffnen eines File eine Kopie davon im Cache. Arbeitet der User mit dem File, dann schreibt der OFS-Daemon die Änderungen sowohl in die Kopie im Cache als auch in das Remote-File auf dem Server, vorausgesetzt Letzteres ist verfügbar.

Schreib-Weiche

Der Ablauf im Einzelnen (Abbildung 3): Eine Programm will in eine Datei schreiben. Es bedient sich dazu beim Systemcall-Interface (die Libc kapselt diesen Vorgang), um den Auftrag an den Linux-Kernel zu geben. Dort erkennt der VFS, dass Fuse für den vorliegenden Mountpoint zuständig ist. Fuse wiederum leitet den Auftrag an den OFS-Daemon weiter.

Abbildung 3: Greift ein Programm auf eine Datei zu, dann merkt der VFS im Kernel, dass Fuse zuständig ist. Das Fuse-Modul leitet den Aufruf an den OFS-Daemon weiter und empfängt auch dessen Antwort.

In Abbildung 3 nicht weiter ausgeführt ist, dass der Daemon wiederum über das Linux-Dateisystem, also über den VFS, auf die gemountete Freigabe oder auf den Cache zugreift. Der OFS-Daemon koordiniert dabei das Kopieren der Daten in den Cache. Ist das Cacheing für ein Verzeichnis nicht aktiviert, reicht der OFS-Daemon die Aufrufe unverändert an das Netzwerk-Filesystem weiter.

Abschließend gibt der OFS-Daemon das Resultat einer Operation durch das Fuse-Modul an das anfragende Programm zurück – diese Schritte gibt die Abbildung 3 wieder.

Abbildung 4: Um den Original-Mountpoint (links) kümmern sich Fuse und OFS. Im Offline-Fall bedient der OFS-Daemon alle Anfragen aus dem Cache (Mitte), solange eine Verbindung zum Fileserver besteht, greift der Daemon aber auf das Remote-Directory zu (rechts).

Cacheing

Im Fall von OFS fungiert der lokale Cache als Mirror der Freigabe. Da der Benutzer selbst auswählt, welche Verzeichnisse er offline verfügbar haben will, spiegelt OFS nur die gewünschten Teile, die jedoch vollständig. Andere Offline-Dateisysteme kopieren entweder die komplette Freigabe oder wählen selbst die Files aus, beispielsweise die am häufigsten verwendeten oder die zuletzt benutzten Dateien. OFS belässt die Kontrolle und die Verantwortung lieber beim Benutzer, statt ihm einen Algorithmus vorzusetzen.

Obwohl OFS nur einzelne Offline-Bereiche auf die lokale Festplatte kopiert, erzeugt der OFS-Daemon immer den gesamten Pfad von der Freigabe-Wurzel bis zum offline verfügbaren Verzeichnis. Dies hat den Vorteil, dass OFS die Zugriffe bei Verbindungsverlust unmittelbar auf den Cache umleiten kann, ohne fehlende Vaterverzeichnisse zu emulieren.

Dreifaltigkeit

Intern kennt OFS drei Verzeichnisbäume: Einen lokalen Cache (Cache-Dir), ein Remote-Share-Verzeichnis (Remote-Dir, in das OFS die Freigabe mountet) und das Verzeichnis, auf dem der Benutzer arbeitet (Working-Dir). Der komplette Cache sowie der Mountpoint für das Remote Share sind lokale Verzeichnisse, die OFS selbst anlegt.

Wo OFS diese Verzeichnisse deponiert, entscheiden Einträge in der Konfigurationsdatei des OFS-Daemon, typischerweise liegen sie unter »/var/ofs«. Als Verzeichnisname dient ein Hashwert der URL des Remote Share. Das vermeidet Konflikte und stellt sicher, dass der Admin die internen Verzeichnisse auch leicht kopieren oder verschieben kann. Abbildung 4 zeigt ein Beispiel für Cache-, Remote- und Working-Verzeichnisse.

Praxis

Das Kommando zum Erstellen eines OFS-verwalteten Mountpoints oder – anders ausgedrückt – zum Mounten einer Freigabe über OFS lautet »mount -t ofs Typ://Server/Freigabe /Mountpoint«. Der folgende Aufruf bindet daher die SMB-Freigabe »daten« des Dateiservers »fileserver.comp« in das lokale Verzeichnis »/network/daten« ein:

mount -t ofs smb://fileserver.comp/daten /network/daten 

Der Mounthelper »mount.ofs« klinkt den OFS-Daemon per Fuse in »/network/daten« ein. Außerdem zerlegt der Mounthelper die URL und führt einen weiteren Mount-Befehl aus, um das Remote-Verzeichnis einzubinden:

mount -t smb //fileserver.comp/daten /var/ofs/remote/URL-Hash 

Jeder OFS-verwaltete Mountpoint besitzt einen Zustand, der aussagt, ob die Freigabe verfügbar ist oder nicht. Entsprechend erfolgen Zugriffe auf den Cache oder die Freigabe selbst. Das Umschalten erfolgt bisher über ein D-Bus-Event. Beim Herausziehen des Netzwerkkabels erzeugt Linux per D-Bus ein Event, das OFS abfängt und den Status des Dateisystems auf »offline« setzt. In Zukunft möchten die Entwickler weitere Features integrieren, beispielsweise könnte ein Timer bei jedem Zugriff auf den Server mitlaufen und so Server- oder Netzwerkprobleme aufdecken. Durch regelmäßiges Polling des Servers könnte OFS erkennen, wenn dieser wieder online ist.

Attribute

OFS verhält sich gegenüber den Anwendungen im Prinzip wie jedes andere Filesystem. Zu seinen besonderen Features gehört ein Flag, das angibt, ob eine Datei im Ernstfall offline verfügbar sein soll. Viele Dateisysteme, beispielsweise AFS, bringen eigene Tools mit, um solche Parameter zu setzen. OFS verwendet allerdings einen anderen Kniff: Es bedient sich bei den erweiterten Attributen (Extended File Attributes), da Linux-Standardtools diese setzen und auslesen können. Eigene Werkzeuge sind nicht nötig.

Extended File Attributes ermöglichen es, Dateien mit Metadaten zu versehen, sofern das Dateisystem dies unterstützt. Um die Get- und Set-Kommandos kümmert sich der Kernel nicht selbst, er gibt sie an das Dateisystem-Modul weiter. Damit ist es Sache des Filesystems, die Attribute zu verarbeiten oder zu speichern. Fuse unterstützt Extended File Attributes und bietet Callback-Funktionen für das Setzen, Löschen, Lesen und Auflisten von Attributen an.

Kommunikation

OFS nutzt dieses Feature für eigene, spezifische Attribute. Sie dienen ausschließlich dazu, Informationen zwischen dem Dateisystem und der Shell auszutauschen. OFS speichert sie nicht und gibt sie auch nicht an das darunter liegende Filesystem weiter, es sind quasi virtuelle Attribute. In der aktuellen Version unterstützt OFS zwei Attribute im Namensraum »ofs«:

• »ofs.offline« zeigt an, ob eine Datei offline
  verfügbar ist. Das Setzen dieses Attributs stößt
  den Aktualisierungsprozess an und ergänzt den entsprechenden
  Baum in der Liste der offline verfügbaren Verzeichnisse.
• »ofs.available« verdeutlicht, ob die Datei remote
  verfügbar ist oder OFS die Version aus dem Cache nutzt. Es
  zeigt also an, ob die Verbindung zum Server momentan besteht oder
  nicht. Dieses Attribut ist nur lesbar.

In beiden Fällen gibt es nur die Zustände “gesetzt” (yes) und “nicht gesetzt” (no). Für das Setzen ist der Befehl »setfattr -n Attribut Pfad« zuständig, fürs Lesen »getfattr -n Attribut Pfad«. Wer das Attribut komplett löschen will, verwendet »setfattr -x Attribut Pfad«.

Synchronisation

In zwei Situationen ist eine Synchronisation nötig: OFS muss seinen Cache auf dem Laufenden halten, solange die Verbindung zum Server steht, und es muss sich nach einem Verbindungsabbruch um die Reintegration der Änderungen kümmern, sobald der Server wieder erreichbar ist.

Coda und Intermezzo (siehe Kasten “Ähnliche Ansätze”) haben den Vorteil, dass sie auch die Serversoftware bereitstellen. Dadurch können sie Änderungen unmittelbar an alle relevanten Clients melden. OFS ist eine reine Clientlösung, weshalb der Benutzer die Aktualisierung des Cache manuell starten muss. Andernfalls geht OFS davon aus, dass sich auf dem Server nichts ändert.

Bei der Cache-Aktualisierung stützt sich OFS auf die Modifikationszeit der Dateien. Der OFS-Daemon vergleicht die Zeitstempel der Originaldatei in der Freigabe und ihrer Kopie im Cache. Hat sich die ferne Datei verändert, kopiert OFS sie in den lokalen Cache. Für den Abgleich muss OFS den kompletten Offline-Verzeichnisbaum durchsuchen. Da dieser Prozess sowohl das Netzwerk als auch die Festplatte sowie die CPU stark belastet, besonders wenn viele Clients OFS verwenden, haben die Entwickler auf eine vollständige Automatisierung per Polling verzichtet.

Immer aktuell

Öffnet jedoch ein Programm eine Datei per »open()«-Systemaufruf, wird der Aktualisierungsprozess aktiv. Wie oben beschrieben prüft OFS, sofern sich die Datei in einem offline verfügbaren Verzeichnis befindet, ob sie noch aktuell ist, und lädt bei Bedarf die neue Version vom Server. Lesende Zugriffe bedient OFS dann aus dem lokalen Cache, während Schreibzugriffe sowohl den Cache als auch die Freigabe verändern (Abbildung 5). Dies führt sowohl zu performanten Lesezugriffen als auch zur Aktualität der Dateien, die der Benutzer vor Kurzem verwendet hat.

Abbildung 5: Beim Öffnen einer Datei (links) aktualisiert OFS möglichst die Kopie im lokalen Cache. Lesende Anfragen (rechts oben) bedient OFS Performance-steigernd direkt aus dem Cache. Schreibzugriffe ändern sowohl den Cache als auch – wenn verfügbar – das Original auf dem Server (rechts unten).

Den zweiten Teil, die Reintegration, aktiviert OFS automatisch, sobald sich der Client wieder mit dem Server verbunden hat. Dazu bedarf es einiger Vorbereitung. Während die Verbindung getrennt ist, protokolliert OFS sämtliche Schreibzugriffe, die das System in dieser Situation nur im Cache ausführt. Jeder Eintrag im Logfile enthält neben dem Pfad zur Datei noch einen Parameter, der die Änderung spezifiziert. Mögliche Werte sind: angelegt, gelöscht und geändert. Die Entwickler haben darauf verzichtet, die genaue Position und den Inhalt von Änderungen innerhalb der Dateien zu speichern.

Steht die Verbindung zum Server wieder, dann bedient sich der Reintegrationsprozess dieses Logfiles. Er arbeitet es durch und vollzieht jeden Schritt auf dem Server nach: Datei neu anlegen, löschen oder die Variante aus dem Cache auf den Server hochkopieren. Das stellt sicher, dass alle lokalen Änderungen wieder gemeinsam verfügbar sind. Es ist ebenfalls möglich, einzelne Dateien zu reintegrieren.

Abbildung 6: Der OFS-Reiter in den Eigenschaften eines Verzeichnisses erlaubt es KDE-Anwendern, alle OFS-Einstellungen für den Ordner zu verändern.

Konflikte bewältigen

Bei der Reintegration kann es passieren, dass eine Datei, die der Benutzer lokal verändert hat, in der Zwischenzeit auch auf dem Server modifiziert ist. Um die fremde Version nicht einfach zu überschreiben, prüft OFS zunächst die Aktualität der Remote-Datei. Liegt deren Modifikationszeit nach dem Zeitpunkt der letzten Synchronisation, dann wurde sie verändert. In diesem Fall startet OFS die Konfliktbewältigung.

In einigen Fällen lässt sich der Konflikt sehr einfach lösen, etwa wenn ein Benutzer die lokale Datei verändert, während ein anderer User die Version auf dem Server nur umbenannt hat oder zwei Benutzer eine identische Änderung vorgenommen haben. Mitunter kommt es jedoch zu unlösbaren Konflikten, etwa wenn während der Offline-Phase zwei Benutzer die gleiche Datei unterschiedlich verändert haben. OFS löst solche Konflikte nicht automatisch auf, sondern überlässt dies dem Benutzer. Ein Diff-Mechanismus analysiert beide Versionen der Datei. Welcher Diff zum Einsatz kommt, bestimmt die OFS-Konfiguration. Bei reinen Textfiles klappt das sehr gut.

Um dem Benutzer die Konfliktauflösung zu erleichtern, zeigt eine Vorschau das Resultat einer vorgeschlagenen Konfliktauflösung. Bei Textdateien ist die Verknüpfung in den meisten Fällen problemlos. Die Ausnahme hierbei ist, wenn beiden Seiten an der gleichen Stelle die Datei geändert haben. Bei Binärdateien ist sowohl die Darstellung der Unterschiede als auch das Zusammenführen von Änderungen weitaus schwieriger und einem Benutzer in der Regel nicht zuzumuten. Da bleibt nur, sich für eine Variante zu entscheiden.

KDE-Integration

Ähnlich den Windows Offline Files bei Windows 2000/XP ergänzen das Plugin »KFilePlugin« für Dolphin und Konqueror im Dialogfeld »Eigenschaften« einen Reiter »OFS«. Das Dialogfeld erscheint nach einem Rechtsklick auf eine Datei oder ein Verzeichnis unter dem Kontextmenü-Eintrag »Eigenschaften«. Die OFS-Registerkarte erlaubt es dem Benutzer, ein Verzeichnis in den lokalen Cache aufzunehmen oder Änderungen auf den Server zu übertragen.

Kommt es hierbei zu einem nicht lösbaren Konflikt, zeigt das Plugin eine Meldung. Sofern OFS zu dem Datentyp der problematischen Datei eine Konfliktbehandlung kennt, zeigt es überdies einen Lösungsvorschlag. Bestätigt der Benutzer, dass er den Vorschlag akzeptiert, dann löst OFS den Konflikt. Lehnt der Benutzer den Vorschlag ab oder gibt es keinen Vorschlag, bleibt dem Benutzer nichts anderes übrig, als die Dateien selbst zu untersuchen oder eine der beiden Varianten zu überschreiben.

Eine vollautomatische Konfliktbeseitigung kennt OFS nicht, da es in der Verantwortung des Benutzers bleiben soll, was mit seinen Dateien passiert. Bei eigenmächtigem Handeln durch das System wäre die Gefahr von Datenverlusten zu hoch. Das GUI-Plugin ist übrigens kein zentraler Bestandteil von OFS. Auch Systeme ohne grafische Oberfläche arbeiten problemlos mit OFS über das Kommandozeilen-Interface.

Weiterentwicklung

OFS ist noch kein fertiges Produkt, die aktuelle Version ist aber schon begrenzt einsetzbar. Künftig sind Erweiterungen vorgesehen. Das modulare Design ermöglicht es beispielsweise, weitere Agent-Klassen einzufügen, die genauere Daten über die Verfügbarkeit eines Remote-Filesystems liefern. Ähnliches gilt für die Bestimmung, ob sich ein File auf dem Server geändert hat. Außerdem bietet sich eine Portierung von OFS nach Mac OS X an. (fjl)