Re: umount -f implementation
- From: Rick Macklem <rmacklem@xxxxxxxxxxx>
- Date: Mon, 29 Jun 2009 11:17:20 -0400 (EDT)
On Sun, 28 Jun 2009, Nathanael Hoyle wrote:
I think the answer is probably "it's a feature, not a bug", but that depends on your NFS mount options which you didn't give. I'd suggest you read up on NFS soft versus hard mounts. I think you're seeing the latter and expecting the former behavior.Well, part of the problem is that I'm working on a client that includes
NFSv4 and, at least for NFSv4, getting "intr" or "soft" mounts to work
correctly is nearly impossible. Since NFSv4 includes lock state operations
that must be strictly serialized and the state maintained in a consistent
way, you can't just "terminate" an RPC involving these Ops without breaking all state handling.
Also, I/O system calls generally aren't expected to fail with EINTR and
many (most??) apps. get broken by this happening.
Personally, I believe that "hard" mounts plus the use of "umount -f" to
get rid of mounts against unresponsive servers is the preferred way to go
and the first step in this direction would be getting "umount -f" to work
for the above case (plus agreement that the semantics of "umount -f"
include "loss of recently written data"). There was a thread on this a
few months ago, which I cant find, but there is pr129760 w.r.t. FreeBSD
locking up upon a "umount -f".
(Btw, I believe that Mac OS X has adopted this concept. It pops up a
"disconnect mount" window for unresponsive servers and does essentially
a "umount -f" if the user clicks "ok".)
The first hit I found Googling seems pretty decent, though taken from Linux docs should still apply:There was a time when SunOS/Solaris was considered the "gold standard"
Under section 4.3.1 "Soft vs. Hard Mounting" there's a basic description.
for NFS (but I suppose this is the Linux era;-). My recollection might be fuzzy, but I don't think SunOS had a "umount -f" in those days and I think "intr" was introduced after their first release, as an improvement over
"soft", since NFS servers got really slow when running on 1985 hardware.
Solaris10 does have a "umount -f" and the man page notes that data related
to open files can be lost when it is used. (This would basically be the
semantic "umount -f" on FreeBSD will have if the "sync"s aren't done.)
freebsd-current@xxxxxxxxxxx mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscribe@xxxxxxxxxxx"
- Prev by Date: Re: r194546 amd64: kernel panic in tcp_sack.c
- Next by Date: Re: Interface dependencies
- Previous by thread: Re: umount -f implementation
- Next by thread: Re: umount -f implementation