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>