Wikipedia · einfach zusammengefasst · Stand
Coda (Dateisystem)
Coda ist ein in einem Netzwerk verteiltes Dateisystem für stationäre und mobile Rechner. Mehrere Rechner können gleichzeitig mit dem Dateisystem arbeiten, …
Inhalt4 Abschnitte
Überblick und Funktionsweise
Coda ist ein über ein Netzwerk verteiltes Dateisystem für stationäre und mobile Rechner. Mehrere Rechner können gleichzeitig darauf zugreifen. Die Inhalte liegen normalerweise auf mehreren Servern, die ihre Daten automatisch untereinander abgleichen. Diese Verteilung soll die Verfügbarkeit erhöhen.
Jeder Client, also jeder zugreifende Rechner, speichert häufig benötigte Dateien in einem lokalen Cache auf seiner Festplatte. Wird die Netzwerkverbindung unterbrochen, kann der Client mit den dort vorhandenen Daten weiterarbeiten. Sobald wieder eine Verbindung zu einem Server besteht, gleicht Coda die Daten automatisch ab. Nur wenn dabei Konflikte auftreten, ist ein manueller Eingriff erforderlich. Da mobile Geräte oft nur begrenzten Speicher besitzen, kann ihr Cache möglicherweise nur einen kleinen Teil des gesamten Dateisystems enthalten.
Coda entstand aus einem 1987 an der Carnegie Mellon University in Pittsburgh gestarteten Forschungsprojekt. Die Entwickler bezeichnen das System weiterhin als experimentell und empfehlen es nicht für einen Produktivbetrieb mit zahlreichen unerfahrenen Nutzern. Im Vergleich zum Andrew File System ist Coda jedoch erheblich einfacher zu installieren: Die Komponenten für Verschlüsselung und Authentifikation sind vollständig in den Installationspaketen enthalten und werden weitgehend automatisch eingerichtet. Dadurch ist Coda beispielsweise für mobile Geräte wie Laptops interessant.
Umgang mit gleichzeitigen Änderungen
Wenn mehrere Clients auf dieselben Ressourcen zugreifen, können Inkonsistenzen entstehen, etwa wenn sie dieselbe Datei unterschiedlich verändern. Andere Systeme verhindern dies häufig, indem sie eine Ressource jeweils für nur einen Client freigeben. Bei mobilen Teilnehmern kann dieses Sperrverfahren jedoch zu einem Deadlock führen: Eine Ressource bleibt gesperrt, weil die Verbindung des Clients zusammenbricht und dieser die Sperre nicht mehr aufheben kann.
Coda verzichtet deshalb auf solche Ausschlussverfahren und erlaubt allen Clients den Zugriff. Für jede Änderung wird ein Replay-Log angelegt, also eine Aufzeichnung, anhand derer sich die Änderung nachvollziehen beziehungsweise erneut ausführen lässt. Entstehen widersprüchliche Änderungen, löst Coda den Konflikt nicht selbstständig; die Benutzer müssen ihn manuell bearbeiten.
Zentrale Bestandteile und Fachbegriffe
• SCM (System Control Master): Ein besonderer Rechner im Netzwerk, auf dem die Originale der Coda-Konfigurationsdateien gespeichert sind.
• Volume: Eine bei der Konfiguration festgelegte logische Gruppe von Dateien. Volumes erscheinen für die Benutzer als Unterverzeichnisse eines speziellen Verzeichnisses namens coda. Ihre Namen sind für alle Benutzer im Netzwerk identisch.
• RPC2 (Remote Procedure Call 2): Eine spezielle Softwarebibliothek, mit deren Hilfe Coda über sogenannte UDP-Sockets mit anderen Prozessen im Netzwerk kommuniziert.
• RVM (Recoverable Virtual Memory): Ein spezieller Speicherbereich auf einem Coda-Server.
• Venus: Ein Programm beziehungsweise Prozess auf den Clients. Venus übernimmt die Kommunikation mit den Coda-Servern und verwaltet den lokalen Cache.
Technische Grenzen
Coda erreicht noch nicht das Ideal eines Dateisystems, in dem benötigte Dateien überall verfügbar, vor Verlust geschützt und gleichzeitig vollständig synchronisiert sind. Besonders wichtig sind drei Einschränkungen:
• Niedrige Schreibgeschwindigkeit: Schreibvorgänge sind sehr viel langsamer als in einem rein lokalen Dateisystem. Das Löschen ist um den Faktor 60 langsamer, das Erzeugen einer Datei um den Faktor 20.
• Sehr große Dateien: Wenn ein Client auf eine Datei zugreift, muss sie vollständig lokal vorliegen. Für eine große Datei wie ein DVD-Abbild muss der Cache deshalb beispielsweise mindestens 5 GB groß sein. Das ist vor allem auf mobilen Geräten mit knappem Speicher problematisch.
• Ständig geöffnete Dateien: Eine Datei wird erst beim Schließen persistent, also dauerhaft gespeichert. Dies geschieht nicht bereits vorher, etwa durch das Kommando flush. Wird ein Client nicht ordnungsgemäß heruntergefahren, zum Beispiel wegen eines Stromausfalls oder eines leeren Akkus, können deshalb Änderungen an einer Datenbank oder Einträge in einer Logdatei verloren gehen. Dieses Verhalten widerspricht der üblichen UNIX-artigen Semantik, nach der geschriebene Daten früher oder später ohne weiteres Eingreifen der Anwendung auf den persistenten Speicher gelangen.