NFS: Linux vs. FreeBSD, I/O error bei tcp

25/06/2008 - 16:22 von Gerrit Kuehn | Report spam
Hallo Leute,

ich habe hier einen aktuellen FreeBSD-Server (7-stable), auf den ich gerne
per NFS mit verschiedenen Linux-Clients zugreifen würde. Dabei hatte ich
verschiedene Probleme mit den Pinguinen, die ich im wesentlicchen durch
die Optionen nfsvers=3 und nolock in den Griff bekommen ließen.
Nun habe ich aber einen Fedora6-Client, der sich beharrlich weigert, auf
nur ein NFS-Verzeichnis zu mounten. Jeder Versuch wird mit einem

[root@psl-fe2 ~]# mount.nfs mclane:/tank /mnt -v -o nolock,nfsvers=3
mount: trying 10.117.15.2 prog 100003 vers 3 prot tcp port 2049
mount: trying 10.117.15.2 prog 100005 vers 3 prot udp port 933
mount.nfs: Input/output error

quittiert, was für mich nicht sonderlich aussagekràftig ist. Auf dem
Server kommen überhaupt keine Meldungen zustande. Die Linux-Seite sieht
folgendes:

[root@psl-fe2 ~]# rpcinfo -p mclane
program vers proto port
100000 4 tcp 111 portmapper
100000 3 tcp 111 portmapper
100000 2 tcp 111 portmapper
100000 4 udp 111 portmapper
100000 3 udp 111 portmapper
100000 2 udp 111 portmapper
100000 4 7 111 portmapper
100000 3 7 111 portmapper
100000 2 7 111 portmapper
100005 1 udp 933 mountd
100005 3 udp 933 mountd
100005 1 tcp 933 mountd
100005 3 tcp 933 mountd
100003 2 udp 2049 nfs
100003 3 udp 2049 nfs
100003 2 tcp 2049 nfs
100003 3 tcp 2049 nfs

[root@psl-fe2 ~]# showmount -e mclane
Export list for mclane:
/tank 10.117.15.0
/tank/home 10.117.15.0
/tank/home/cvsghf 10.117.15.0
/tank/home/cvspsl 10.117.15.0
/tank/home/cvspt 10.117.15.0
/tank/home/ghf 10.117.15.0
/tank/home/psl 10.117.15.0
/tank/home/pt 10.117.15.0
/tank/opt 10.117.15.0
/tank/test 10.117.15.0


Das weitere Absenken der Protokollversion auf 2 bringt nichts, wohl aber
die Umstellung von tcp auf udp:

[root@psl-fe2 ~]# mount.nfs mclane:/tank /mnt -v -o nolock,nfsvers=2
mount: trying 10.117.15.2 prog 100003 vers 2 prot tcp port 2049
mount: trying 10.117.15.2 prog 100005 vers 1 prot udp port 933
mount.nfs: Input/output error

[root@psl-fe2 ~]# mount.nfs mclane:/tank /mnt -o nolock,nfsvers=3,proto=udp
[root@psl-fe2 ~]#

Das làuft einwandfrei. Nun ist udp heutzutage ja aber nicht mehr das
empfohlene Mittel der Wahl. Hat jemand eine Idee, warum die Mounts via tcp
nicht funktionieren? Zwischen Client und Server sitzt noch ein NAT-Router,
der aber alle Verbindungen vom Client stateful weitergibt. Andere Clients
tun wie erwàhnt auch (zwar vielleicht nicht immer ganz einwandfrei, aber
zumindest ohne diese Probleme).


cu
Gerrit
 

Lesen sie die antworten

#1 Christoph Weber-Fahr
09/07/2008 - 21:20 | Warnen spam
Hallo,

Gerrit Kuehn wrote:
Das weitere Absenken der Protokollversion auf 2 bringt nichts, wohl aber
die Umstellung von tcp auf udp:

[ ~]# mount.nfs mclane:/tank /mnt -v -o nolock,nfsvers=2
mount: trying 10.117.15.2 prog 100003 vers 2 prot tcp port 2049
mount: trying 10.117.15.2 prog 100005 vers 1 prot udp port 933
mount.nfs: Input/output error

[ ~]# mount.nfs mclane:/tank /mnt -o nolock,nfsvers=3,proto=udp
[ ~]#



Naja IIRC kann nfsv2 über tcp kaum jemand anderes als FreeBSD.

Das làuft einwandfrei. Nun ist udp heutzutage ja aber nicht mehr das
empfohlene Mittel der Wahl.



Warum? Wozu den overhead in lokalen LANs wo udp auch geht?

Hat jemand eine Idee, warum die Mounts via
tcp nicht funktionieren? Zwischen Client und Server sitzt noch ein
NAT-Router,



NAT Ist Böse(tm)

der aber alle Verbindungen vom Client stateful weitergibt.



Hm ... stateful?? Und laß mich raten - eigentlich macht er nicht
NAT sondern PAT. Das ist noch viel mehr Böse(tm).

Und "stateful" timed irgendwann aus.

Andere Clients tun wie erwàhnt auch (zwar vielleicht nicht immer ganz
einwandfrei, aber zumindest ohne diese Probleme).



Bau ein ordentliches Netz. "Vielleicht nicht immer ganz einwandfrei"
und Filesysteme gehören nicht in den selben Satz.

Gruß

Christoph Weber-Fahr

Ähnliche fragen