Date: Mon, 1 Jun 1998 14:47:00 -0500 (CDT) From: Kevin Day <toasty@home.dragondata.com> To: peter@netplex.com.au (Peter Wemm) Cc: mi@video-collage.com, current@FreeBSD.ORG Subject: Re: NFS discovery Message-ID: <199806011947.OAA21359@home.dragondata.com> In-Reply-To: <199806011908.DAA10546@spinner.netplex.com.au> from Peter Wemm at "Jun 2, 98 03:08:23 am"
next in thread | previous in thread | raw e-mail | index | archive | help
> >
> > 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.
How about an option to control it? :)
>
> 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.
I tried that too, and umount would freeze. (I could at least ^C out of it
though)
> >
> > 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? :-)
I discovered it a few days ago, during massive power problems. (the servre
kept rebooting randomly) and it worked every time. I'm about to reboot the
server again, and can test whatever is needed.
Kevin
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?199806011947.OAA21359>