Date: Sat, 07 Feb 1998 10:13:37 -0600 From: David Kelly <dkelly@hiwaay.net> To: hackers@FreeBSD.ORG Subject: Re: More NFS Problems Message-ID: <199802071613.KAA20198@nospam.hiwaay.net> In-Reply-To: Message from "Evan Champion" <evanc@synapse.net> of "Fri, 06 Feb 1998 21:29:30 EST." <02b601bd3370$386d8fe0$2844c00a@cello.synapse.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Evan Champion writes:
>
> I am always able to recover the system without rebooting by killing the
> offending processes and restarting them. However, each of my systems does
> not run a large number of different tasks, so it is relatively easy to guess
> what to kill on each system. On a larger system, it might be just a lot
> easier to restart.
>
> Irrespective, I don't think it should be doing that :-)
Me too. I don't have this problem with Solaris or Irix NFS. Even if
the filesystem is busy, "umount -k /filesystem" will close it in Irix,
even if the remote system is not responding. But I don't think its just
offending processes keeping the system blocked in FreeBSD. I used to put
NFS mounts in /etc/fstab without the noauto option until I got tired of
"df" blocking forever if the server was not responding. Have never been
able to umount a non-responding NFS fs on FreeBSD short of a reboot.
Currently I use amd to mount NFS filesystems. Replace what used to be
the mount point with a symbolic link to /host/{hostname}/{filesystem}
and it works as it always has.
--
David Kelly N4HHE, dkelly@nospam.hiwaay.net
=====================================================================
The human mind ordinarily operates at only ten percent of its
capacity -- the rest is overhead for the operating system.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199802071613.KAA20198>