inforum 4/1997 - Das TVFS im LAN
4/1997 Inhalt -
Vorheriger Artikel -
Nächster Artikel -
ImpressumDas TVFS im LAN
von R. Jüngling
Unter dem Betriebssystem OS/2 löst das „virtuelle File-System“ TVFS, ein Shareware-Programm, das leidige Problem der starren Laufwerksbuchstabenzuordnung.
Einleitung
Das Konzept der Laufwerksbuchstaben in den gängigen PC-Betriebssystemen ist ein lästiger Anachronismus. Mag man sich an einem Einzelplatzsystem noch damit arrangieren (schließlich kennt man ja nichts anderes), in einer Netzwerkumgebung wird es schnell zu einem echten Ärgernis.
Zunächst ist die Zahl der Laufwerksbuchstaben begrenzt. Als LAN-Administrator wird man die zentral installierte Software über einige wenige Netz-Laufwerke einem Client-PC zugänglich machen. Programme aber, für die nur ein paar Lizenzen erworben wurden, muß man extra behandeln. Der einfachste Mechanismus, den PC-Fileserver hierfür bieten, ist, die Zahl der möglichen Anforderungen einer Dateiressource zu begrenzen. Auf der Client-Seite wird dann der Aufruf eines solchen Programmes für gewöhnlich mit einem Skript realisiert; etwa so:
REM *** Aufruf von MAPLE ***
NET USE P: \\FILESRV\MAPLE
P:
maple.exe
NET USE P: /d
Damit ist das Laufwerk P: dann schon für das
Programm Maple reserviert. Man könnte versuchen, die
Laufwerksbuchstaben mit etwas aufwendigeren Skripten
dynamisch zu reservieren, also statt Laufwerk P:
z. B. das erste nicht benutzte Laufwerk aus dem Bereich
N: bis Z: verwenden. Allerdings setzt das
voraus, daß man in den Konfigurationsdateien dieser Programme
alle Referenzen auf das Installationslaufwerk entfernen kann, was
zusätzliche Arbeit bereitet oder aber gar nicht möglich ist.
Ein anderes Problem ergibt sich, will man die Dateiressourcen
später auf mehrere Fileserver verteilen (etwa um der gewachsenen
Zahl von Clients Rechnung zu tragen und die Antwortzeiten zu
verbessern). Die Inhalte eines Netzlaufwerkes N:
beispielsweise sollen zukünftig auf zwei Fileserver verteilt
werden; man ist in diesem Fall gezwungen, zwei Netzlaufwerke zu
verwenden und damit die bisherige Installation zumindest
teilweise über den Haufen zu werfen und auf die neue
Situation umzustricken.
Zusammenfassend kann man sagen: Das Konzept der Laufwerke bereitet nur unnötige Arbeit und bietet eigentlich keine Vorteile; ein einziger hierarchischer Dateiraum wie unter Unix wäre wünschenswert.
Erklärung des Toronto Virtual File Systems (TVFS)
Ein Werkzeug, das hier Abhilfe schafft ist das TVFS, das es für OS/2 als Freeware gibt. Es löst nicht nur die genannten Probleme sehr elegant, sondern noch eine Reihe weiterer, die ich nach einer kurzen Beschreibung des TVFS weiter unten erläutern möchte.
Das TVFS besteht aus einem Dateisystemtreiber, der beim Booten
installiert wird und einem Set von Kommandos, mit denen sich ein
„virtuelles Dateisystem“ aufbauen läßt. Dazu reserviert man
sich mit TVMOUNT X: zunächst ein virtuelles
Laufwerk, das erst einmal nichts weiter enthält als das
Rootverzeichnis. Nun kann man Verzeichnisse anlegen und Referenzen auf
bestehende Dateiressourcen hinzufügen ("linken"), etwa:
TVLINK X:\WINWORD C:\WINPROGS\WORD60
MD X:\DOS
TVLINK X:\DOS\AUTOEXEC.BAT C:\AUTOEXEC.BAT
Es sind sowohl Referenzen auf Verzeichnisse als auch auf Dateien
möglich; der erste Befehl erzeugt einen Link auf das Verzeichnis
C:\WINPROGS\WORD60, der letzte einen Link auf die Datei
C:\AUTOEXEC.BAT. Im Laufwerk X: befinden
sich nun die Verzeichnisse \WINWORD und
\DOS. öffnet man z. B. mit einem Editor die Datei
X:\DOS\AUTOEXEC.BAT, so öffnet man tatsächlich
die Datei C:\AUTOEXEC.BAT; die Referenz
X:\DOS\AUTOEXEC.BAT ist also vergleichbar mit einem
Hard Link in Unix-Dateisystemen. Erlaubt sind auch Links auf
nichtlokale Dateiressourcen, z. B.:
TVLINK X:\MAPLE \\FILESERV\MAPLE
Weiter hat man die Möglichkeit, die Zugriffsrechte auf die
referenzierte Ressource einzuschränken, z. B. die Datei
C:\AUTOEXEC.BAT als „nur lesbar“ zu linken (Option
-r). Man kann die Datei X:\DOS\AUTOEXEC.BAT dann nur zum
Lesen öffnen, will man sie auch zum Schreiben öffnen, so
schlägt diese Dateioperation fehl, Fehlermeldung: „Die Datei
X:\DOS\AUTOEXEC.BAT existiert nicht“, was zunächst etwas abwegig
erscheint.
Mit den bislang erläuterten Möglichkeiten lassen sich die oben beschriebenen Probleme sofort lösen. Man kann nun mit einem einzigen Netzlaufwerk auskommen (das dann ein TVFS-Laufwerk ist) und alle benötigten Ressourcen die selbstverständlich auf diversen Fileservern verteilt sein können der Reihe nach hinzulinken. Ein Skript zum Aufruf eines Programmes mit beschränkter Lizenzzahl würde jetzt analog zu obigem so aussehen:
REM *** Aufruf von MAPLE ***
NET USE \\FILESRV\MAPLE
TVLINK X:\MAPLE \\FILESRV\MAPLE
X:
cd \MAPLE
maple.exe
TVULINK X:\MAPLE *
NET USE \\FILESRV\MAPLE /d
Das virtuelle Dateisystem besteht also ausschließlich aus
Referenzen und hat die Aufgabe, Dateioperationen an die referenzierten
Ressourcen zu vermitteln und zwar gemäß den durch
das Linken implizit definierten Regeln. Für die bislang
erläuterten Möglichkeiten sind diese Regeln trivial, aber
das TVFS kann noch mehr. Es ist möglich, einen Link mehrfach zu
verwenden, d. h. mehrere verschiedene Ressourcen unter demselben Namen
in die Verzeichnisstruktur einzuhängen. Betrachten wir das
Beispiel zweier Verzeichnisse C:\DATEN (lokale Ressource) und
\\FILESRV\DATEN (Netzressource), die beide unter dem Namen
X:\DATEN
gelinkt werden:
TVLINK X:\DATEN C:\DATEN -rw
TVLINK X:\DATEN \\FILESRV\DATEN -r
Das erste Verzeichnis wurde als les- und schreibbar gelinkt, das
zweite als nur lesbar. Angenommen im Verzeichnis C:\DATEN
befinden sich die beiden Dateien JUNI.DAT und
JULI.DAT, im Netzverzeichnis die Dateien MAI.DAT
und JUNI.DAT. Im virtuellen Verzeichnis
X:\DATEN sind dann die drei Dateien MAI.DAT,
JUNI.DAT und JULI.DAT zu finden. Die Datei
JUNI.DAT existiert aber zweimal. Hier bestimmt die
Link-Reihenfolge und die Art der Dateioperation, an welche Datei das
TVFS schließlich vermittelt: gemäß der
Link-Reihenfolge werden alle gelinkten Verzeichnisse nach der zu
öffnenden Datei durchsucht; der erste Link, der mit der
geforderten Operation „verträglich“ ist, erhält den
Zuschlag. In unserem Beispiel ist der Zugriff auf die Datei
JUNI.DAT klar, in jedem Fall wird die Datei
C:\DATEN\JUNI.DAT verwendet. Hätten wir in der
umgekehrten Reihenfolge gelinkt, so würde bei einem „nur
lesenden“ Zugriff auf die Datei im Netzverzeichnis zugegriffen, bei
schreibendem Zugriff auf die lokale Datei.
Falls für die Datei C:\DATEN\JUNI.DAT im lokalen
Filesystem nicht das „nur lesbar-Attribut“ gesetzt ist, kann man die
Datei X:\DATEN\JUNI.DAT löschen. Danach sind immer
noch die drei genannten Dateien im Verzeichnis X:\DATEN;
allerdings ist JUNI.DAT in diesem Falle die nur lesbare
Datei \\FILESRV\DATEN\JUNI.DAT.
Nun gibt es zwei Möglichkeiten, wie sich das TVFS verhalten
kann, wenn die Datei X:\DATEN\JUNI.DAT schreibend
geöffnet wird. In jedem Fall wird eine neue Datei
C:\DATEN\JUNI.DAT erzeugt; diese kann nun entweder leer
sein oder es wird der Inhalt der Datei
\\FILESRV\DATEN\JUNI.DAT übernommen je nach
TVFS-Einstellung. Mit diesem Feature kann man z. B. auf eine CD-ROM
schreiben virtuell versteht sich: man linkt ein (leeres)
Verzeichnis mit Schreibzugriff und unter demselben Namen das
CD-ROM-Laufwerk...
Das TVFS im praktischen Einsatz
In den vergangenen Semesterferien haben wir im CIP-Pool Soziologie
die skizzierte Umstellung gewagt und mit dem TVFS noch ein paar
weitergehende Probleme gelöst. Es gibt nun nicht mehr diverse
Netzlaufwerke, sondern nur noch das eine Laufwerk V:,
über das alle Dateiressourcen zu erreichen sind. Die Umstellung
machte zunächst natürlich viel Arbeit, einige Programme
mußten wegen ungültig gewordener Installationspfade neu
installiert werden.
Die meisten unserer Rechner haben eine Festplatte mit für die
Client-Installation (Betriebssystem, Fonts, ausgewählte
Anwendungen) hinreichender Kapazität. In einigen alten Rechnern
hingegen arbeiten jeweils zwei kleine Platten, auf die unsere
Client-Installation nicht mehr als Ganzes draufpaßt; die
Kapazität beider Platten zusammen reicht allerdings aus. Die
Lösung ist nun naheliegend: Teile der lokalen Installation werden
ebenfalls über das virtuelle Laufwerk angesprochen (das
Windows-Verzeichnis heißt jetzt z. B. V:\SYS\WINDOWS) und
können nun auf verschiedene Platten verteilt werden (oder gar auf
dem Fileserver liegen).
Es werden leider heute immer noch Programme entwickelt, welche für die zentrale Installation auf einem Fileserver nicht taugen, da sie Schreibzugriff im Installationslaufwerk erwarten (von alten Programmen aus DOS-Tagen gar nicht zu reden). Mit dem TVFS ist das Problem schnell gelöst: „über“ den Link auf das Installationsverzeichnis (auf dem Fileserver) wird einfach ein weiterer Link auf ein lokales Verzeichnis „gelegt“, in das geschrieben werden kann. Die Dateien in diesen Verzeichnissen werden wie temporäre behandelt und bei Beginn jeder Sitzung gelöscht. Damit kann dem Benutzer auch endlich erlaubt werden, die Konfiguration eines Programms zumindest für die Dauer einer Sitzung an seine Bedürfnisse anzupassen. Das Verzeichnis mit der Default-Konfiguration wird bei diesem Szenario nur lesbar gelinkt und bleibt vor Veränderung geschützt.
Das Problem der Default-Konfiguration stellte sich in unserem Pool
tatsächlich in einer etwas variierten Form. Ebenfalls in den
Semesterferien wurde ein weiterer Fileserver auf dem AIX-Rechner des
Fachbereiches installiert, der den Pool-Besuchern ihr
Unix-Home-Verzeichnis als SMB-Share zur Verfügung stellt (gelinkt
als V:\HOME). Das Home-Verzeichnis taugt nicht nur zur
Ablage persönlicher Daten, sondern natürlich auch als Depot
für Konfigurationsdateien (wie es unter Unix üblich
ist). D. h. für die im Pool installierte Software sollen die
Konfigurationsdateien im Home-Verzeichnis des Benutzers zu liegen
kommen, wo dies sinnvoll und technisch möglich ist. Allerdings
ist unzumutbar, die Benutzer diese Programme selbst konfigurieren zu
lassen; unter Unix hat man für diesen Zweck systemweit geltende
Konfigurationsdateien, die gelesen werden, falls der Benutzer keine
eigene Konfigurationsdatei in seinem Home-Verzeichnis hat. Für
Programme, die in Einzelbenutzer-Umgebungen laufen, ist sowas in der
Regel nicht vorgesehen.
Die erste Idee ist, einfach alle Default-Konfigurationsdateien bei
der ersten Sitzung in das Home-Verzeichnis zu kopieren. Das ist
allerdings nicht sehr schön, da auch Konfigurationsdateien
Plattenplatz beanspruchen und es ergäben sich Probleme, sobald
neue Software im Pool installiert wird, deren Konfigurationsdateien
ebenfalls ins Home-Verzeichnis sollen ... Viel eleganter geht es
natürlich mit dem TVFS. Ein Verzeichnis, das auf
dem Fileserver liegt (und somit eine zentral durchzuführende
Aktualisierung erlaubt) hält alle möglichen
Konfigurationsdateien vor. Es wird nach dem eigentlichen
Home-Verzeichnis als nur lesbar unter V:\HOME
gelinkt. Somit stehen sofort alle Konfigurationsdateien in
V:\HOME zur Verfügung, allerdings wurde keine
einzige kopiert kein unnötiger Plattenplatz wird
verbraucht. Wird eine Anwendung zum ersten Mal gestartet, so mit den
Default-Werten; eventuelle Änderungen werden schließlich
ins „wirkliche“ Home-Verzeichnis geschrieben. Bei jedem weiteren
Aufruf dieser Anwendung wird dann die modifizierte Konfigurationsdatei
verwendet, die Einstellungen des Benutzers bleiben dauerhaft erhalten.
Alles super?
Neben die mannigfaltigen Vorteile treten leider auch ein paar Nachteile. Die Funktionsweise des TVFS impliziert natürlich einen gewissen Overhead für jede Dateioperation, die vermittelt wird. Man muß also bei Datei-intensiven Applikationen mit Performance-Einbußen rechnen. Tatsächlich konnten wir das in der Praxis aber nur selten beobachten, bei Programmen nämlich, die regen Gebrauch von temporären Dateien machen, wie z. B. Web-Browser. Es empfiehlt sich daher nicht, das Verzeichnis für temporäre Dateien auf ein virtuelles Laufwerk zu legen.
Die meisten Probleme ergaben sich allerdings aus mangelndem
Verständnis der Arbeitsweise des TVFS im Detail, bzw. durch
nichtssagende Fehlermeldungen von Anwendungsprogrammen bei
fehlgeschlagenen Dateioperationen. Beispielsweise wurde die
Installation eines Windows-Programms auf dem virtuellen Laufwerk mit
dem lapidaren Hinweis abgebrochen, die Registry
(REG.DAT)
könne nicht aktualisiert werden. Glücklicherweise ließ
sich dem Problem durch genaue Analyse der Dateizugriffe auf die Spur
kommen (und schließlich lösen) das TVFS hat
nämlich auch einen Debug-Modus, in dem alle vermittelten
Dateioperationen protokolliert werden.
Da ein virtuelles Laufwerk keinen eigenen Datenträger repräsentiert, ist auch keine sinnvolle Angabe über den noch freien Speicherplatz möglich. Das TVFS erlaubt, hier einen (fixen) Wert vorzugeben, allerdings nur in gewissen Grenzen. Eine Installation kann deswegen auch schon mal mit der Meldung „Nicht genügend Speicherplatz auf Datenträger!“ fehlschlagen.
Als „Standardtrick“ bei Installationsproblemen auf dem virtuellen Laufwerk hat sich bei uns folgendes Verfahren bewährt. Für die Installation wird statt des virtuellen ein Netzlaufwerk verwendet. Das Programm wird unter dem Pfad auf das Netzlaufwerk installiert, über den es nachher auf dem virtuellen Laufwerk angesprochen werden soll. Zuletzt muß das Installationsverzeichnis auf dem Serverlaufwerk noch an die richtige Stelle verschoben werden.
Problematischer ist die geringe Fehlertoleranz des TVFS gegenüber Fehlfunktionen der Zieldatenträger. Der Zusammenbruch einer Netzwerkverbindung während einer Dateioperation auf dem Netzlaufwerk etwa führt zum Absturz des TVFS-Control-Dämons (wird beim Booten nach dem Dateisystemtreiber installiert). Infolgedessen ist dann das gesamte virtuelle Laufwerk nicht mehr verfügbar. (Allerdings sind solcherlei Ausfälle auch Ausnahmesituationen.) Ob andere Randbedingungen die Stabilität des TVFS negativ beeinflussen, müssen die Erfahrungen im Langzeitbetrieb zeigen.
Fazit
Das TVFS erweist sich als flexibles Werkzeug, mit dem sich viele administrative Probleme in einer LAN-Umgebung lösen lassen. Sicher mit dem TVFS umzugehen erfordert allerdings eine gewisse Eingewöhnung; die beschriebenen Nachteile relativieren sich mit zunehmender Erfahrung. Man muß natürlich keineswegs den oben skizzierten Weg gehen und gleich alles auf TVFS umstellen; es ist ebenso denkbar, ein virtuelles Laufwerk neben den bestehenden Netzlaufwerken zu benutzen und die Client-Installation schrittweise anzupassen.
Kontakt zum CIP-Pool Soziologie:
ifscip@uni-muenster.de
4/1997 Inhalt -
Vorheriger Artikel -
Nächster Artikel -
Impressum
Zentrum für Informationsverarbeitung (Universitätsrechenzentrum)
