Re: NFS

Patric Mrawek wrote:

Ich hab das Problem versucht noch etwas weiter einzukreisen.

> Es gibt einen NFS-Server mit entsprechenden Exports und verschiedene
> NFS-Clients. Der Server ist ein -current von vor ein paar Tagen, die
> Clients -DP1 und -DP2.

Auch mit einem 4-stable Client kann ich dieses Verhalten sehen.

> Ich mounte nun ein Share und kopiere Daten von diesem Share auf die
> lokale Platte auf dem Client.
>
> # find -x -d /nfs-mnt | cpio -pdumv .
>
> (Dabei bin ich vom NFS-Server aus auf dem Client per ssh eingeloggt.)
>
> Nun passiert es, dass der Kopiervorgang immer an der gleichen Stelle
> abbricht bzw. blockiert. Im Log findet sich:
>
> bowmore kernel: nfs server talisker:/usr/src: not responding 10 > 9
>
> Da ich intr,soft gemoutet habe kann ich das Kopieren abbrechen. Starte
> ich den Kopiervorgang sofort neu passiert nichts. Warte ich aber ca.
> 30 Sekunden kann ich wieder bis zum dem Punkt kopieren, an dem es
> vorher auch blockiert hat.

Das Phaenomen tritt _nur_ mit UDP-NFS-Mounts auf. Sobald ich ueber TCP
mounte funktioniert alles perfekt (deutlich langsamer aber der
NFS-Mount ist stabil). Irgendwas frisst hier also UDP-Pakete. ;-)

Mit tcpdump sehe ich, dass das bei jedem Kopiervorgang bis exakt zum
gleichen File kopiert wird und danach Stille auf dem Draht herrscht.

der erste Zugriff auf das NFS-Share:

03/25/2003 13:33:02.099638 client.1666645131 > server.nfs: 124 access fh 994,342430/1389568 003f (ttl 64, id 3842, len 152)
03/25/2003 13:33:02.099730 server.nfs > client.1666645131: reply ok 120 access attr: DIR 755 ids 0/0 sz 0x000000200 nlink 20 rdev 176/5505272 fsid 0xb0005400f8 nodeid 0x5400f800000000 a/m/ctime 1048598760.000000 1047458071.000000 1047458132.000000 c 0023 (ttl 64, id 43959, len 148)

[...]

03/25/2003 13:33:02.100392 client.1666645133 > server.nfs: 120 fsstat fh 994,342430/1389568 (ttl 64, id 15665, len 148)
03/25/2003 13:33:02.100417 server.nfs > client.1666645133: reply ok 168 fsstat POST: DIR 755 ids 0/0 sz 0x000000200 nlink 20 rdev 176/5505272 fsid 0xb0005400f8 nodeid 0x5400f800000000 a/m/ctime 1048598760.000000 1047458071.000000 1047458132.000000 tbytes 0x357e25800 fbytes 0x20f435000 abytes 0x1cacad000 tfiles 0x0001b4ffe ffiles 0x00016e93f afiles 0x00016e93f invar 0 (ttl 64, id 49828, len 196)

[...]

03/25/2003 13:33:02.609686 client.1666646568 > server.nfs: 132 read fh 994,342430/1390063 8192 bytes @ 0x000002000 (ttl 64, id 35174, len 160)
03/25/2003 13:33:02.609747 server.nfs > client.1666646568: reply ok 1472 read REG 644 ids 0/0 sz 0x000002be7 nlink 1 rdev 182/5505176 fsid 0xb600540098 nodeid 0x54009800000000 a/m/ctime 1048599182.000000 999451146.000000 1045753464.000000 3047 bytes EOF (frag 62167:1480(at)0+) (ttl 64, len 1500)
03/25/2003 13:33:02.609751 server > client: udp (frag 62167:1480(at)1480+) (ttl 64, len 1500)
03/25/2003 13:33:02.609756 server > client: udp (frag 62167:224(at)2960) (ttl 64, len 244)
03/25/2003 13:33:02.678199 client.1666646568 > server.nfs: 132 read fh 994,342430/1390063 8192 bytes @ 0x000002000 (ttl 64, id 63590, len 160)
03/25/2003 13:33:02.678239 server.nfs > client.1666646568: reply ok 1472 read REG 644 ids 0/0 sz 0x000002be7 nlink 1 rdev 182/5505176 fsid 0xb600540098 nodeid 0x54009800000000 a/m/ctime 1048599182.000000 999451146.000000 1045753464.000000 3047 bytes EOF (frag 50930:1480(at)0+) (ttl 64, len 1500)
03/25/2003 13:33:02.678244 server > client: udp (frag 50930:1480(at)1480+) (ttl 64, len 1500)
03/25/2003 13:33:02.678249 server > client: udp (frag 50930:224(at)2960) (ttl 64, len 244)

[...]

Das hier ist der letzte NFS-read den ich sehen kann. Durch das Dumpen
des kompletten UDP-Paketes konnte ich sehen, dass das letzte File noch
komplett uebertragen wird. Nach diesem letzten Paket passiert nichts
mehr.

03/25/2003 13:34:53.723523 client.1666646569 > server.nfs: 132 read fh 994,342430/1390063 3047 bytes @ 0x000002000 (ttl 64, id 50769, len 160)
03/25/2003 13:34:53.723657 server.nfs > client.1666646569: reply ok 1472 read REG 644 ids 0/0 sz 0x000002be7 nlink 1 rdev 182/5505176 fsid 0xb600540098 nodeid 0x54009800000000 a/m/ctime 1048599293.000000 999451146.000000 1045753464.000000 3047 bytes (frag 54648:1480(at)0+) (ttl 64, len 1500)
03/25/2003 13:34:53.723668 server > client: udp (frag 54648:1480(at)1480+) (ttl 64, len 1500)
03/25/2003 13:34:53.723672 server > client: udp (frag 54648:224(at)2960) (ttl 64, len 244)

Patric

-- 
The problem with troubleshooting is that trouble shoots back.
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message