Waldemar Brodkorb schrieb:

Am Mit, 19 Apr 2000 schrieb Frank Mohr:

...

hallo

ich hatte gerade einen merkwuerdigen effekt auf einem von einer sun von einem linux-rechner per nfs gemounteten filesystem

symbolic links (source und target im gleichen nfs-mount) werden von der sun zwar gesetzt, auf der sun sind die links aber nicht sichtbar, die datei wird beim lesen als leer angesehen. auf linux sind die links ok.

Hat jemand ne idee woran das liegen koennte? (weitere params beim export? bekannte unvertraeglichkeiten sun/linux nfs?)

frank

noch kurz die config:

Linux:

Suse 6.3, Kernel 2.2.13

/etc/exports: /home/fmohr/prj colad(rw,no_root_squash,insecure)

Sun: SunOS 5.6 mount obelix:/home/fmohr/prj /mnt

link:

prj/x # ln -s ../y/datei1 datei2

Welche Version von NFS verwendest du denn ? Kernelspace oder Userspace?

Ja, das ist wichtig!!

AFAIK hat hier in der Liste auch jemand von Problemen mit Sun und Linux NFS-Netzen berichtet, aber ich weiß nicht welche.

Ja, das war ich.

Ich bin mal so frei und poste die Adresse, ich hoffe Peter Kuechler nimmt es mir nicht Übel.

Nein, warum sollte ich? Immerhin sind wir genau deswegen ja alle hier, oder? Was das Problem selbst angeht: Mit links hatte ich in der Form noch keine Probleme, ich werde aber versuchen das noch zu testen wenn ich wieder im Büro bin. Bei mir sehen die Probleme so aus: Der Solaris-Client erzeugt in eine gemounteten Linuxverzeichnis per Script div. Verzeichnisse und Dateien, wobei da Teilwiese auch Dateien der Grösse 0 Byte erzeugt werden (das ist auch soweit ok). Dann kann der erzeuger aber plötzlich nicht mehr auf die diese Dateien und Verzeichnisse zugreifen, weil er angeblich keine Zugriffrechte hat. Diese sind aber OK. Manchmal erledigt sich dieses Problem nach einer gewissen Zeit von selbst. Da ich aber solange nicht immer warten kann, habe ich es mir eine restart des NFS-Servers verucht, was auch funktioniert. Danach kann der client auf alles wieder zugreifen. Es sieht also so aus, als wären die tatsächlichen Daten und die Verwaltungsinformationen nicht immer syncron (irgendwelche Caches oder Puffer), ich sage das jetzt einfach mal so. Das ganze war Anfangs noch schlimmer. Ich habe dann immer zwischen Kernel-NFS und dem normalen NFS gewechselt, je nach dem was gerade besser gelaufen ist. Im Moment verwende ich gerade das normale NFS, weil es sich wärend dem Betrieb anhalten und wieder starten lässt, ohne das die Solaris-Clients neu gestartet werden müssen. Die merken das nichtmal, ausser das es event. kurz mal hängt:-) Beim Kernel-NFS geht es zumindest bei der Version, die bei Suse6.3 dabei ist nicht. Allerdings ist das etwas schneller (ist ja bekannt). Warum ich jetzt wieder zu dem normalen NFS zurück bin hatte den Grund, das es sich scheinbar immer wieder mit dem netatalk Paket gebissen hat. Es gab dann Kernel Oops, und es lies sich NFS nicht mehr beenden und neu starten. Leider konnte dadurch auch der Rechner nicht mehr sauber runtergefahren werden was dazu führte, das jedes mal ein fsck über 3 x 35GB RAID mit ext2 gefahren wurde. Das dauerte dann immer etwa 1 bis 1,5 Stunden. Kein gutes Bild für einen Fileserver:-( Das ist jetzt mit dem normalen NFS behoben, dafür treten ab und zu noch die oben erwänten Probleme auf. Ich werde aber jetzt netatalk rauschmeissen, dann werde ich den nächsten Versuch mit Kernel-NFS machen, zusätzlich mit einem Patch für NFS3. Mal sehen, wie weit ich damit komme. Ich hoffe, ihr könnt mit den Infos was anfangen, ansonsten einfach melden. Leidensgenossen sind immer willkommen;-) mfg Peter Küchler Registrierter Linux-User #127408 --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com