From owner-freebsd-isp Sun Jan 4 19:14:08 1998 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA23313 for isp-outgoing; Sun, 4 Jan 1998 19:14:08 -0800 (PST) (envelope-from owner-freebsd-isp) Received: from True.Net (true.net [200.11.130.10]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA23305 for ; Sun, 4 Jan 1998 19:14:04 -0800 (PST) (envelope-from lem@cantv.net) Received: from fwa-1.true.net (fwa-2.true.net [200.11.130.1]) by True.Net (8.8.5/8.6.12) with ESMTP id XAA19951; Sun, 4 Jan 1998 23:13:58 -0400 (AST) Received: (daemon@localhost) by fwa-1.true.net (8.8.6/8.6.12) id XAA04359; Sun, 4 Jan 1998 23:13:57 -0400 (VET) Received: from unknown(161.196.105.69) by fwa-1.true.net via smap (V1.3) id smae04324; Sun Jan 4 23:13:27 1998 Message-Id: <3.0.5.32.19980104225625.007bb280@pop.cantv.net> X-Sender: lem@pop.cantv.net X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Sun, 04 Jan 1998 22:56:25 -0400 To: spork From: =?iso-8859-1?Q?=22Luis_E=2E_Mu=F1oz=22?= Subject: Re: [fbsd-isp] Designing for a very large ISP Cc: jbutt@mwci.net, freebsd-isp@FreeBSD.ORG In-Reply-To: References: <199801042025.OAA22797@subcellar.mwci.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-isp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk 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 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... 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