[PLUG] How to umount NFS hung mouts
Felix Lee
felix.1 at canids.net
Thu Aug 14 04:31:02 UTC 2003
"Steven A. Adams" <stevea at nwtechops.com>:
> > If your network is as well-designed as you say, then mounting
> > hard instead of soft should not cause any problems, therefore you
> > should mount hard so that programs don't silently fail.
> I'm really not too sure why you would question this but you can rest
> assure that when I say networks I do mean network(S) - there have been
> many.
But if the networks are reliable, what's your rationale for
mounting soft? There's no performance gain for mounting soft
instead of hard.
> > Programs silently fail because NFS changes some of the basic
> > assumptions about Unix file I/O, and most programmers don't spend
> > much time writing code that checks for conditions they think are
> > impossible.
> Interesting assertion, now qualify it with fact.
The historical example is that close() over NFS can return errors
that used to be returned by write(), such as "sorry, disk is
full", and several programs (like emacs) had to be changed to
notice that.
That's not the same as the soft vs hard issue, but I've never
looked at the potential differences between writes on soft mounts
versus hard mounts, because nobody I know mounts writable
filesystems soft, and everyone recommends against it, so it never
seemed like something worth analyzing. It's not just write() and
close(). I'd also want to look at how programs use unlink() and
rename() and so forth. The "soft" decision happens at the SunRPC
level, it affects every NFS operation and adds the possibility
that any operation can fail with an EIO error.
> > Well, NFS has been around for a couple years now, maybe
> > everyone's learned new programming habits and fixed all the old
> > programs already. Someone should check.
> A couple of years? Take a look at RFC 1904 dated March of 1989.
Yes, I know, I'm a dinosaur. Emacs is careful now to check the
return value from close() when writing files. I don't have much
confidence that everyone else does too, and I don't have any
confidence that people have thought much about the problem of
doing reliable changes on soft-mounted filesystems.
Now that I think about it, soft-mounted filesystems may have
security implications too. One thing that comes to mind is
xauth. I just checked, xauth ignores the return value from
close() or unlink(), though this doesn't seem like it's
exploitable for anything other than boring DoS.
--
More information about the PLUG
mailing list