Date: Tue, 02 Jun 1998 03:08:23 +0800 From: Peter Wemm <peter@netplex.com.au> To: Kevin Day <toasty@home.dragondata.com> Cc: mi@video-collage.com (Mikhail Teterin), current@FreeBSD.ORG Subject: Re: NFS discovery Message-ID: <199806011908.DAA10546@spinner.netplex.com.au> In-Reply-To: Your message of "Mon, 01 Jun 1998 13:29:24 EST." <199806011829.NAA20244@home.dragondata.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <peter@netplex.com.au> Netplex Consulting
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199806011908.DAA10546>