Re: NFS-Server im Kernel.. warum?

On Thu, Jul 17, 2003 at 10:03:07AM +1000, Peter Ross wrote:
> On Wed, 16 Jul 2003, Bernd Walter wrote:
> > Jedes Komando kann auf der Strecke bleiben und darf wiederholt werden.
>
> Halb.. Wenn Du ein remove wiederholst, weil Du beim ersten Versuch keine
> Bestaetigung bekommst, schickt der Server Dir beim zweiten Versuch ein
> "File not found". Das kann Deine Anwendungslogik evt. schon mal
> durcheinander bringen.

Das kann dir ebenso passieren, wenn ein anderer Prozess das File
inzwischen löscht - auch lokal.
Eine Anwendung sollte damit umgehen können.

> > Echten Cache gab er ursprünglich nicht und ist erst mit nqnfs von BSD
> > dazu gekommen, womit man den verwalten konnte.
>
> 4.4BSD, Solaris, Linux, Nextstep benutz(t)en seit Jahren
> Caching-Mechanismen. Zumindest Linux ist da definitiv optimistisch;-) Und
> in einer heterogenen Umgebung, wofuer NFS ja nun mal da ist, wird das
> alles noch ein Stueck verwirrender..

Sag ich doch - nqnfs.
/usr/share/doc/papers/nqnfs.ascii.gz

> Zumindestens meinerseits ist es Optimismus, wenn ich in heterogener
> Umgebung aus Performancegruenden nicht alles Caching disable. Definitiv
> sicher bin ich mir nicht, dass es in 100% aller moeglichen Faelle
> funktioniert, nur konnte ich in den Arbeitsumgebungen bisher mit dem
> "Restrisiko" leben.
>
> Bis auf im Linux-Fall, das hat einfach nur genervt, aber wenn man mich
> zwingt..

War wohl keine nqnfs Implementierung :)
Über Linux und NFS schreibe ich besser nichts...
Kannst du aber auch nicht NFS als solches vorwerfen.

> > > Ich hoffe doch schon, dass ein File beim Rebooten seine inodes nicht
> > > wechselt..
> >
> > Normalerweise nicht.
> > Die Böse überraschung kommt immer dann, wenn ein Admin Daten eines
> > Filesystems auf die neu große Platte kopiert hat...
>
> Das beruehmte "Stale NFS handle".. Da hilft Dir auch Kernel-NFS nicht
> weiter. Das NFS-Handle wird aus Device Number und Inode generiert, wenn
> ich mich nicht irre?

Mag sein - das Verfahren ist nicht vorgeschrieben und dem Server
überlassen.
Kenel-NFS wird dir sicherlich nicht helfen.

> > Reboote mal einen SMB Server und beobachte das Verhalten der Windows
> > Clients...
>
> Die Netzwerkverbindungen bleiben bestehen. Was mit geoeffneten Files
> passiert, weiss ich nicht, kann es auch derzeit nicht ausprobieren. Was
> passiert?

Wenn du Pech hast, dann bekommst du auf dem Client mehr Dialogboxen von
Programmen, die das gar nicht verstehen, als dir lieb ist.

> Danke auch fuer die lockd/statd-Bemerkung. Bei Gelegenheit gucke ich da
> nochmal nach.
>
> Ich habe mal "die reine Lehre" gelernt, Sun-NFS, wo der lockd ja auch
> lokal arbeitet (oder vielleicht heute auch nicht mehr, es war einmal..?),
> so dass er dort viel logischer erscheint.

Der lockd muss auf beiden Seiten laufen.
Sowohl der Server, als auch der Client kennen die locks und wenn einer
restartet, dann wird syncronisiert.

> Das "Nachempfinden" in anderen Umgebungen sieht wohl immer wie ein Hack
> aus.

Das ist ein normiertes Protokoll - da gibt es nichts mit nachempfinden.
Aber leider jede Menge Bugs in den Implementierungen.

> Wie ueberhaupt NFS;-)

Remoteaktionen sind immer ein Kompromiss.
Du musst auch damit leben, daß Webseiten nicht funktionieren, wenn ganz
woanders etwas ausfällt.

-- 
B.Walter                   BWCT                http://www.bwct.de
ticso(at)bwct.de                                  info(at)bwct.de
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message