Re: Filesysysemsuche

Autor: Thimo Neubauer (thimo_at_debian.org)
Datum: 15. Mar 2004


On Sun, Mar 14, 2004 at 08:07:56PM +0100, Markus Hochholdinger wrote:
> ich dachte Coda ist darauf ausgelegt, offline arbeiten zu können.

Ja, ist es. Da kann man auch im "disconnected"-Zustand Dateien im
Cache schreiben. Leider packt er aber (um Aktionen richtig
zurückspielen zu können) Filesystem-Aktionen zusammen. Bei
umbenenn-und-lösch-Aktionen bekommt er dann manchmal das Gefühl, nicht
mehr mit dem Server synchron zu sein und schaltet automatisch in den
disconnected-mode und erwartet, dass man die Kollision per Hand
regelt. So etwas passiert aber reporduzierbar, wenn man ein grösseres
Projekt baut :-( Zudem hatte Coda eine lachhafte Schreibperformance,
wenn das Volume auf dem selben Rechner lag (~400k/sec)

> OpenAFS ist auf Ausfallsicherheit ausgelegt. Oder ist das mittlerweile
> anders?

Es läuft so viel wie möglich weiter, wenn Server ausfallen. Wenn der
Fileserver mit Deinem Volume drauf weg ist bist Du halt blockiert.

> > > Wie "kleinlich" ist OpenAFS bei einem Server-Disconnect? Steht dann das
> > > ganze Client-System oder kann man mit dem lokalen Dateisystem-Cache
> > > weiter arbeiten (vorausgesetzt, es ist nur ein kurzes Netzwerkproblem)?
> > Grundsätzlich ist das System synchron, d.h. bei einem disconnect kann
> > man nie schreiben. Allerdings verwendet er dann noch die Daten aus dem
> > lokalen Cache. Man kann bestimmte read-only-Volumes (z.B. das
> > root-Volume) aber auch auf viele Server replizieren, da schwenkt er
> > dann automatisch auf einen laufenden um.
> Ich meine hier jetzt Extremsituation wie z.B. ich mache eine Datei zum
> schreiben auf und dann zieh ich das Netzwerkkabel. Kann man diese Datei
> dann nie wieder schreiben? Erkennt der Server den Disconnect nach einer
> Weile? Wie synchronisiert sich der Server danach mit dem Client?

Das sind Detailfragen, die ich Dir nicht genau beantworten
kann. Nachdem OpenAFS aber schon länger im kommerziellen Einsatz ist,
wird es bestimmt nicht dauerhaft blockieren. Nachdem bei zwei
Schreibern immer derjenige den Inhalt bestimmt, der als letztes
fclose() macht, würde ich vermuten, dass die Datei gar nicht wirklich
synchron gelockt wird.

Für komische Situationen gibt es jede Menge Befehle, man kann
z.B. Volumes löschen ohne der zentralen Datenbank bescheid zu sagen,
aus den lokalen Datenbanken die globale basteln usw. Damit ist man im
Katastrophenfall ganz gut ausgerüstet und muss nicht selber in den
internen Daten herumbasteln.
 
> Ahja, also ein Schreiben in den lokalen Cache geht somit nicht? Sprich,
> die Anwendung muss beim Speichern warten, bis der Server sagt, es ist
> alles da?

Ja, denn sonst müssest Du ja mit dem Fall rechnen, dass die Verbindung
während des Schreibens verreckt und ein Synchronisationsprotokoll
haben (es könnte ja auf dem Server bis zum Reconnect etwas
passieren). Nachdem Synchronisation auch die Möglichkeit von
Kollisionen mit sich bringt, die man nur per Hand auflösen kann, ist
es mir so ganz recht.

Gruss
  Thimo




Dieses Archiv wurde generiert von hypermail 2.1.7 : 15. Mar 2004 CET