[linux-l] lokales Netz - NFS oder Samba?

Peter Ross Peter.Ross at alumni.tu-berlin.de
So Apr 15 12:41:10 CEST 2007


Hallo Frank (und andere Interessierte),

vielleicht magst Du mal

http://docs.freebsd.org/44doc/papers/nqnfs.ps.gz

lesen? Es diskutiert einige Probleme, die NFS hat, und einen Loesungsweg,
den 44BSD mit NQNFS (not quite NFS;-) gegangen ist.

Ich habe gehoert, das Konzept der Leases ist in NFSv4 eingeflossen, aber
das bitte selbst ueberpruefen.

Ansonsen rate ich mal, zu einem Buch ueber NFS zu greifen. Ich hatte vor 
Urzeiten mal eines auf deutsch von Santifaller
(http://www.amazon.de/s?ie=UTF8&index=books-de&field-keywords=NFS&page=1)

Anyway, zusammen mit aufmerksamen Lesen der Mountoptionen fuer NFS sollte
einige Ideen bringen, was man erreichen kann, um Konsistenz zu erreichen.

On Sat, 14 Apr 2007, Frank Reker wrote:

> Am Fri 13. Apr 2007 19:59 +0200 schrieb olafBuddenhagen at gmx.net:
> 
> >Mangels Transkationen im Dateisystem-API
> 
> wieso? ein open startet eine transaktion und ein close beendet
> eine transaktion. man hat keine transaktion ueber mehrere dateien
> hinweg, das ist richtig, aber auf datei ebene sehr wohl.

Das entspricht einem exkluviven Schreiblock auf eine geoeffnete Datei. 
Kann Deine Applikation machen, Wird von NFS unterstuetzt.

Anyway, unter Transaktionen bei Filesystemen versteht man normalerweise 
etwas anderes, atomare Schreiboperationen z.B.

> problematisch sind hierbei zwei dinge:
> 1) muss der server sicher sein, dass er auch alle write-instruktionen
> erhalten hat. das ist bei nfs nicht gegeben.

Doch. NFS quittiert den Empfang eines Paketes.

> 2) koennen auch veraenderungen lokal durchgefuehrt werden ohne ueber
> die netzwerk schicht zu gehen. dadurch wird ein journaling auf
> netz-fs-ebene umgangen.

Siehe oben genanntes Dokument.
> 
> nein - der klient bekommt (zumindest in der udp-variante) nicht mit,
> wenn durch temporaere netzwerkfehler daten nicht oder nicht vollstaendig
> geschrieben wurden. die anwendung muesste also nach dem schreiben
> die datei erst nochmal wieder einlesen und ueberpruefen ob's 
> vollstaendig ist.

Nein, das stimmt nicht. ein Schreiben der Datei wird quittiert.

> aber auch nur wenn tcp verwendet wird. unter udp ist soetwas 
> prinzipbedingt nicht moeglich (es sei denn man baut sich ne 
> transaktionskontrolle auf anwenderebene nach).

Das passiert schon auf NFS-Protokollebene (siehe oben), muss Deine 
Anwendung nicht.

> da man als looser-user ohne groesseren aufwand nicht unbedingt wissen 
> kann wie der nfs-server/client konfiguriert ist, muss man immer von
> der schlechtmoeglichsten variante ausgehen, und entsprechende 
> massnahmen ergreifen.

Das Problem, was Du schilderst, existiert so nicht, da NFS durchaus 
zurueckmeldet.

Einer fehlerhaften Implementation oder eher performance-, weniger 
sicherheitsorientierten Konfiguration ist ein Programm auch ohne NFS 
ausgeliefert.

Ein Programm weiss nichts ueber darunterliegende Filesysteme (moechte ich 
auch nicht - wie soll das aussehen? vi-Start: if (fs != mein_wunsch) 
magic?;-), Journaling, Caching (im Filesystem, durch die Festplatte etc..)

Gruss
Peter



Mehr Informationen über die Mailingliste linux-l