Re: NFS-Server im Kernel.. warum?

Dankeschoen fuer die Antworten.

On Wed, 16 Jul 2003, Bernd Walter wrote:

> Eine Anwendung hat eine andere Sicht auf Files und kann nur per
> Filenamen zugreifen - ein NFS CLient liefert aber letzlich Inodes

Naja, ein Shellskript wuerde ls -i machen und haette dann einen passenden
Dateinamen - das laesst sich sicher auch in C realisieren.

> da NFS stateless ist mag zwischen öffnen und schreiben vom File ein
> kompletter Reboot des Servers liegen.

Ich gestehe, das ich den Fall auch immer schon reichlich faszinierend
fand.. Bei aller Vorsicht im NFS-Konzept, wo ja jede Menge Gedanken in
Richtung "Welches Kommando darf ich zweimal schicken? Was darf ich cachen?
Wann ist der Cache dirty?" gemavht wurden, ist doch wohl immer noch ein
Quentchen Optimismus "Wird schon nicht schiefgehen" dabei. Das
Weiterschreiben auf ein geoeffnetes File nach dem Reboot ist wohl schon
dabei oder ueberlebt z.B. sogar ein Lock auf ein File das Rebooten? (Ich
wuesste derzeit nicht wie..)

> In dem Fall kann der Server den Filenamen nicht kennen.

Ich hoffe doch schon, dass ein File beim Rebooten seine inodes nicht
wechselt..

> Unter 5.x ist der nfsd

Hier machst Du es aber spannend;-)

> smb ist ein Statefull Protokoll und hat somit einige Probleme weniger
> zu bewältigen.

Ich habe von smb jenseits der Anwendung und Konfiguration nicht viel
Ahnung.. war nur ein Beispiel. Keine Sorge, ich werde keinen Kernel-smbd
schreiben!

> Es mag aber aus Performance Sicht immer noch Sinnvoll erscheinen das im
> Kernel zu realisieren - bei NFS wars allerdings nicht der aleinige Grund.
> In letzter Zeit hat man aber auch einen riesigen Satz von Mõglichkeiten
> dazubekommen auch im Userland entsprechende Vorteile des Kernels nutzen
> zu können - man denke z.B. an sendfile(2) und kqueue(2), was zur Zeit
> der NFS Implementierung noch nicht gab.

Dankeschoen nochmal
Peter

To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Wed 16 Jul 2003 - 13:08:09 CEST