umount -f implementation

[Rick C. Petty]

On Sun, Jun 28, 2009 at 08:32:12PM -0400, Nathanael Hoyle wrote:
> Rick Macklem wrote:
> >
> >Does that sound correct? (In other words, an I seeing a bug or a 
> >feature?)
> >
> 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'm pretty sure the person working on NFSv4 for fbsd knows this
difference.

> I think you're seeing the 
> latter and expecting the former behavior.

Not necessarily true.  I've experienced similar behavior and I only use
soft mounts (actually: "rw,soft,intr,bg,rdirplus").  In fact this bit me
last week when I wanted to move the NFS export on a server.  I did the
move/rename, updated /etc/exports, and did a "killall -HUP mountd" on the
server and I attempted variations of "mount -u" and "umount -f" on the
clients.  Subsequently, I had to restart most of the client machines,
since:

- "mount -u" returned ESTALE
- "umount" returned EBUSY
- "umount -f" failed, I believe with ENXIO

In any case, "umount -f" absolutely has to work.  What other option does
an admin have?  Yes, expect potential data loss and expect the umount may
not return immediately (plain "umount" can take awhile too).  Instead, I
saw a bunch of these messages, when another process continued to write to
a geli-mounted md'd file on that stale filesystem:

kernel: GEOM_ELI: g_eli_read_done() failed md0.eli[READ(offset=1790541824, length=65536)]

-- Rick C. Petty