[Re: NFS -current

Ian Dowse wrote:
> In message <20030325210152.GA12565_at_argv.de>, Patric Mrawek writes:
> >On several clients (-DP1, -DP2, 4-stable) mounting a nfs-share
> >(mount_nfs -i -U -3 server:/nfs /mnt) and then copying data from that
> >share to the local disk (find -x -d /mnt | cpio -pdumv /local) results
> >in lost NFS-mount.
> >
> >client kernel: nfs server server:/nfs: not responding 10 > 9
> 
> I'm not sure what you mean by a "lost" mount. Do all further accesses
> to the filesystem hang?
> 
> It is normal enough to get the above 'not responding' errors
> occasionally on a busy fileserver, but only if they are almost
> immediately followed by 'is alive again' messages.

Particularly when using UDP with a "rsize" or "wsize" larger than
the MTU, which Linux people do all the time.

As you are using UDP...

"If you hear hoofbeats, look for horses first, not zebras".

This is arguably a bug in the FreeBSD UDP packet reassembly code
not throwing away packets through ageing.  There's a DOS attack
you can use against FreeBSD against UDP protocols with larger
than MTU packets, knowing this.

But I think it's more arguably a bug in people using UDP in a
wrong-headed way, in order to try and get a window size larger
that the MTU, without using a sliding window protocol like TCP
instead, which is designed to handle this much more gracefully.

-- Terry