Ian Dowse wrote: > In message <[EMAIL PROTECTED]>, 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 _______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
