# 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, wobei die Inhalte in der Regel auch auf mehrere Server verteilt werden, um die Verfügbarkeit des Systems zu erhöhen. Die Server gleichen die Inhalte automatisch untereinander ab.
Jeder Client besitzt auf seiner lokalen Festplatte einen Cache mit häufig benutzten Dateien. Bei einer Verbindungsunterbrechung benutzt er die Daten aus seinem Cache. Sobald wieder eine Verbindung zu einem Server aufgebaut werden kann, werden die Daten automatisch abgeglichen. Nur bei Konflikten muss manuell eingegriffen werden.
Aufgrund von Ressourcenknappheit mobiler Systeme kann im Cache gegebenenfalls nur ein kleiner Ausschnitt des gesamten Dateisystems aufbewahrt werden.
Coda ist in einem bereits 1987 an der Carnegie Mellon University in Pittsburgh, USA gestarteten Forschungsprojekt entstanden. Coda wird von den Entwicklern noch als experimentell bezeichnet und noch nicht für einen Produktivbetrieb mit zahlreichen unerfahrenen Nutzern empfohlen. Im Vergleich zum Andrew File System, das von großen Organisationen genutzt wird, ist es jedoch erheblich einfacher zu installieren, weil die Komponenten zur Verschlüsselung und Authentifikation vollständig in den Installationspaketen vorhanden sind und weitgehend automatisch konfiguriert werden. Dies macht es z. B. für einen Einsatz mit mobilen Geräten wie Laptops interessant.

## Datenkonsistenz

Bei Zugriff mehrerer Klienten auf dieselben Ressourcen kann es zu Inkonsistenzen kommen. Deswegen wird bei anderen Systemen oft der Zugriff jeweils nur an einen Klienten übertragen. Durch die Mobilität der Teilnehmer kann es aber zu Deadlocks kommen, das heißt Sperren auf eine Ressource durch einen Teilnehmer werden nicht aufgehoben, weil dessen Verbindung zusammenbricht.
Coda verzichtet deswegen auf Ausschlussverfahren und erteilt allen Klienten Zugriff. Bei einer Änderung wird ein Log (Replay-Log) über die Änderung geschrieben. Danach ist es dem Benutzer selbst überlassen, aufgetretene Konflikte aufzulösen.

## Begriffe
### SCM

    System Control Master. Ein spezieller Rechner in Netzwerk, auf dem die Originale der Coda-Konfigurationsdateien gespeichert sind.

### Volume

    Bei der Konfiguration von Coda werden logische Gruppierungen von Dateien festgelegt, die dem Anwender als Unterverzeichnisse eines speziellen Verzeichnisses namens coda erscheinen. Die Namen sind für alle Anwender im Netzwerk identisch.

### RPC2

    Remote Procedure Call 2 ist eine spezielle Software-Bibliothek, 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 bzw. Prozess auf den Klienten, das für die Kommunikation mit den Coda-Servern und für die Verwaltung des lokalen Cache zuständig ist.

## Grenzen

Coda ist von einem idealen Dateisystem, bei dem die gerade benötigten Dateien überall verfügbar und gleichzeitig vor Verlust geschützt und miteinander synchronisiert sind, noch weit entfernt (auch wenn es, verglichen mit anderen Dateisystemen, dem wahrscheinlich am nächsten kommt). Gründe dafür sind unter anderem:
* Schreib-Geschwindigkeit: Die Schreib-Geschwindigkeit auf Coda-Dateisystemen ist sehr viel langsamer als auf lediglich lokalen Dateisystemen. (Um den Faktor 60 langsamer beim Löschen, um den Faktor 20 langsamer beim Datei-erzeugen.)
* mangelnde Unterstützung für sehr große Dateien: Greift ein Coda-Client auf eine Datei zu, dann muss diese vollständig vorliegen. Bei großen Dateien (z. B. DVD-Abbilder) heißt dies: Der lokale Cache des Clients muss z. B. mindestens 5 GB groß sein.
* mangelnde Unterstützung für ständig offene Dateien: Dateien werden erst "persistent", wenn sie wieder geschlossen wurden, nicht schon vorher z. B. mittels des Kommandos flush. Das bedeutet, dass Änderungen auf einer Datenbank oder Logdatei-Einträge nicht erhalten bleiben, sollte der Coda-Client einmal nicht ordnungsgemäß heruntergefahren werden (z. B. Strom-Ausfall bzw. leerer Akku). Dies widerspricht den üblichen UNIX-artigen Semantiken, dass geschriebene Daten früher oder später ohne weiteres Zutun der Applikation den persistenten Speicher (die Festplatte) erreichen.