From owner-freebsd-current Mon Jun 1 12:09:04 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA05931 for freebsd-current-outgoing; Mon, 1 Jun 1998 12:09:04 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from spinner.netplex.com.au (spinner.netplex.com.au [202.12.86.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA05876 for ; Mon, 1 Jun 1998 12:08:52 -0700 (PDT) (envelope-from peter@netplex.com.au) Received: from spinner.netplex.com.au (localhost [127.0.0.1]) by spinner.netplex.com.au (8.8.8/8.8.8/Spinner) with ESMTP id DAA10546; Tue, 2 Jun 1998 03:08:24 +0800 (WST) (envelope-from peter@spinner.netplex.com.au) Message-Id: <199806011908.DAA10546@spinner.netplex.com.au> X-Mailer: exmh version 2.0.2 2/24/98 To: Kevin Day cc: mi@video-collage.com (Mikhail Teterin), current@FreeBSD.ORG Subject: Re: NFS discovery In-reply-to: Your message of "Mon, 01 Jun 1998 13:29:24 EST." <199806011829.NAA20244@home.dragondata.com> Date: Tue, 02 Jun 1998 03:08:23 +0800 From: Peter Wemm Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Kevin Day wrote: > > Kevin Day once stated: > > > > =However entering this on the client machine > > = > > =mount -u -o async /home > > = > > =*while* the client's nfs is hosed will make it recover within 5 > > =seconds. It even appears that all the writes that were queued are > > =executed, and no data is lost. > > > > That's a great thing to know. Those hungups are damn annoying. > > The reason is, probably, a side effect of how `-u'/`async' are > > implemented. AFAIK, the fs is unmounted and then remounted with > > async. Which is just what you wanted. > > That's my thought too, but: > > umount /home > > will freeze, so it's not exactly unmounting things. :) That's because umount (in it's infinite wisdom) tries to stat() the argument to see what file type (/dev node) or directory it is (and resolve symlinks and other wierd things). This causes the NFS hang. I was debating whether to remove it so that it worked solely from the vfs mount list. Incidently, umount -f -t nfs server:/home usually works, as long as the VFS layer isn't deadlocked on the mountlist or a busy filesystem. This is because stat("server:/home") fails with an ENOENT rather than doing a nfs operation. Definately a ``feature'' if I ever saw one. > > =Is there any way of making whatever it was that did this happen > > =automatically every once in a while? :) > > > > NFS hung ups are a strange topic, in my experience. People agree > > that they are "bad", but one is not supposed to complain about > > them... > > Don't read my post as a complaint, rather as a 'hey, why does it do this?" > :) Is it consistant BTW? Or are you not willing to do blow away your server again? :-) > Kevin > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > Cheers, -Peter -- Peter Wemm Netplex Consulting To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message