Date: Tue, 25 Mar 2003 18:52:59 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Ian Dowse <iedowse@maths.tcd.ie> Cc: current@freebsd.org Subject: [Re: NFS -current Message-ID: <3E81160B.E5406C60@mindspring.com> References: <200303260034.aa92057@salmon.maths.tcd.ie>
next in thread | previous in thread | raw e-mail | index | archive | help
Ian Dowse wrote: > In message <20030325210152.GA12565@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3E81160B.E5406C60>