From owner-freebsd-hackers Sun Mar 21 10:46:26 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from home.dragondata.com (home.dragondata.com [204.137.237.2]) by hub.freebsd.org (Postfix) with ESMTP id 7B9CB14D8D for ; Sun, 21 Mar 1999 10:46:25 -0800 (PST) (envelope-from toasty@home.dragondata.com) Received: (from toasty@localhost) by home.dragondata.com (8.9.2/8.9.2) id MAA07901; Sun, 21 Mar 1999 12:45:56 -0600 (CST) From: Kevin Day Message-Id: <199903211845.MAA07901@home.dragondata.com> Subject: Re: NFS - Will it ever be fixed? In-Reply-To: <199903211836.LAA14073@usr06.primenet.com> from Terry Lambert at "Mar 21, 1999 6:36:12 pm" To: tlambert@primenet.com (Terry Lambert) Date: Sun, 21 Mar 1999 12:45:55 -0600 (CST) Cc: des@flood.ping.uio.no, dennis@etinc.com, hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > NFS continues, after many many years, to virtually lock up systems > > > when the server goes away and anything on it is in the path. If you > > > try to dismount it locks up also. > > > > That's a feature, and it can easily be turned off. > > > > "Users continue, after many years, to refuse to read documentation, > > and blame their incompetence on the OS and its developers...." > > Making the thing fail with ESTALE on a server reboot is probably not > as interesting to him as making the client recover from a server > reboot. > There's also the cases where setting features like 'soft' and 'intr' can wedge the system completely. (For those that don't believe me, get 200-300 processes randomly reading/writing the nfs mount, all with 4-5 open files across it. Log in to the system on the console. Unplug the ethernet. If the system isn't completely locked up now, do a: cp /dev/zero /mnt/nfs/blah, then press ^C. You're really wedged now) The only thing that has worked for me, where in a client configuration like that that *will* recover from an nfs server reboot is setting '-d'. (Dumb Timer). It will essentially disable the timeout code, which is where half of FreeBSD's nfs problems are, i believe. Add to this the countless programs that don't see ESTALE as a fatal error, and you'll probably beat the nfs server to death when it comes back, making the problem worse. (Perhaps making the client cache that somehow, instead of doing a getattr across nfs every time, to just keep returning ESTALE?) Kevin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message