Re: NFS-Server im Kernel.. warum?

On Wed, 16 Jul 2003, Bernd Walter wrote:

> > Naja, ein Shellskript wuerde ls -i machen und haette dann einen passenden
> > Dateinamen - das laesst sich sicher auch in C realisieren.
>
> Leider falsch - du müsstest *alle* Verzeichnisse listen um das zu
> ereichen.

Autsch.. stimmt.

> 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.

> 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..

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..

> > 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?

Lustig ist es schon, wenn man bei Linux (2.4.18) lokal einen Hardlink auf
eine Datei hinzufuegt und dann ein NFS handle darauf nicht mehr gueltig
ist. Wenn ich da Linux richtig verstehe, ist der Linkcounter irgendwie in
die Berechnung des NFS-Handles eingegangen. Der Blick in die Sourcen war
da nur halb erfolgreich, Marke "irgendwie so geht das". Ich habe es aus
Zeitmangel aufgegeben, den Code wirklich zu verstehen, fand ihn nicht
besonders handlich.

> Als Anwender solltest du das dann wiederum wissen, weil das Statefull die
> Probleme nämlich auf den Admin abwälzt.

In einer nicht windowszentrierten Umgebung war das Teil nur maessig
wichtig und es gab da z.B. ziemlich wahrscheinlich nur einen Client, der
gleichzeitig auf einer Datei schrieb.

> 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?

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.

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

Wie ueberhaupt NFS;-)

Gruss
Peter

To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Thu 17 Jul 2003 - 02:04:44 CEST