Date: Mon, 5 Jan 1998 00:00:37 -0500 From: Norman C Rice <nrice@emu.sourcee.com> To: =?iso-8859-1?Q?=22Luis_E=2E_Mu=F1oz=22?= <lem@cantv.net> Cc: spork <spork@super-g.com>, jbutt@mwci.net, freebsd-isp@FreeBSD.ORG Subject: Re: [fbsd-isp] Designing for a very large ISP Message-ID: <19980105000037.49046@emu.sourcee.com> In-Reply-To: =?iso-8859-1?Q?=3C3=2E0=2E5=2E32=2E19980104225625=2E007bb280=40pop=2Ecan?= =?iso-8859-1?Q?tv=2Enet=3E=3B_from_=22Luis_E=2E_Mu=F1oz=22_on_Sun=2C_Jan?= =?iso-8859-1?Q?_04=2C_1998_at_10=3A56=3A25PM_-0400?= References: <199801042025.OAA22797@subcellar.mwci.net> <Pine.BSF.3.96.980104164317.17626C-100000@super-g.inch.com> <3.0.5.32.19980104225625.007bb280@pop.cantv.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Jan 04, 1998 at 10:56:25PM -0400, "Luis E. Muņoz" wrote: > At 04:50 PM 04/01/1998 -0500, spork wrote: > [snip] > >At this point we see different behaviour. The client sometimes panics > >(haven't been at the console to see why), or the command hangs and is > >un-killable. The only way to get rid of the phantom mount seems to be a > >reboot of the client.... > > A panic is definitely not correct, however a command waiting forever > is normal. These are the semantics of a 'hard' mount on NFS. If you > want the processes to timeout, you need a 'soft' mount. This should <rant> I have used soft, interruptible NFS mounts under FreeBSD 2.1.5, 2.16, 2.2.2, 2.2.5 (RELEASE and STABLE) and have never experienced a panic, but the "freezing" *does* occur. I have found no way to interrupt it and it doesn't time out (at least within a 48 hour period). :-( Whenever the NFS server goes down a `df' will faithfully reproduce the problem. An `ls' of a directory below the mount point will also reproduce the "freeze." I have to resort to the reset button, power switch, or power cord to recover (Ctrl+Alt+Del doesn't work). I cannot get any response from rlogin, telnet, or serial terminal sessions after the system freezes. Strobe reports that many services are running, but for all I can tell, they're not. Under identical circumstances, Linux 2.x.x boxes do not exhibit the problem; df works, and ls shows a either a cached directory listing or nothing. FWIW, my advice is don't use NFS mounts under FreeBSD unless you want the reliability of a Win95 system. ;-) </rant> > only be done if you really know for sure that you want that. Picture > a mail server trying to deliver mail to a failed NFS mailbox. The > actual timeout might be in the close() call. If this fails, probably > will go undetected and the mail will be lost in the bit bucket. > This is why the default mount stile is 'hard'. > > You also cannot unmount a FS while there are operations queued for > the NFS server. You need the server to be back up before you can > unmount. If this doesn't happen, then we have another abnormal > situation... IMHO, this sounds like a good way to take an entire network down from a single point of failure. > > As a rule of thumb, I assume that the clients will be down of the > NFS server dies for some reason. Sometimes you may think that > the client may continue with other tasks unrelated to the > unresponsive filesystems, but eventually there are going to be > enough blocked processes so as to stop the client. > > We've only sporadically used NFS mounts to export CDs and other stuff > in our lab from FreeBSD 2.2.5 servers, with excellent behavior. > > >Seems to work well except for this behaviour, but I wouldn't want to put > >it in production. > > Nor do I. I tend to dislike NFS on an ISP core :) > > [snip] > > -lem -- Regards, Norman C. Rice, Jr.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19980105000037.49046>