Re: nfs tranfers hang in state getblck or nfsread

Pawel Worach wrote:
[ ... subject ... ]

> This only seem to happen for nfs over tcp.

That's strange; most of the problems I've ever seen are from
using UDP, large read/write sizes, and then droping one packet
out of a bunch of frags caused by the MTU being much smaller
than the read/write size (misguided attempt to emulate a fixed
window size and get more packets in flight, without using TCP
to do it).


> fstab on the client (/conf/default/etc/fstab) looks like:
> server:/export/root   /               nfs     ro              0       0
> procfs                  /proc           procfs  rw              0       0
> server:/usr           /usr            nfs     ro,nfsv3,tcp    0       0
> server:/usr/home      /home           nfs     rw,nfsv3,tcp    0       0
> /export         nfs     ro,nfsv3,tcp    0       0
> server:/export/data/swap      /swap   nfs     rw,nfsv3,tcp    0       0
> /dev/acd0               /cdrom          cd9660  ro,noauto       0       0
> 
> /etc/exports on the server looks like:
> /export -alldirs -maproot=root -network 192.168.1.0 -mask 255.255.255.0
> /export/root -ro -maproot=0 client
> /export/data/swap -mapall=nobody -network 192.168.1.0 -mask 255.255.255.0
> /usr/home client
> /usr -ro -network 192.168.1.0 -mask 255.255.255.0
> 
> filesystems on the server:
> /    magic   11954 (UFS1)    time    Wed Aug 27 17:34:13 2003
> /usr magic   19540119 (UFS2) time    Wed Aug 27 17:33:38 2003
> /export magic   11954 (UFS1)    time    Sat Aug 23 23:51:20 2003
> /export/data magic   19540119 (UFS2) time    Tue Aug 26 07:48:01 2003

What's "magic"?  Make it go away; the word usually means "it's
so complicated, I can't explain it to you, and I implemented
the thing, so you should have szero faith in it, because if the
person who implemented it can't explain it, then it's going to
be impossible to verify correct operation".

-- Terry