15 messages in org.freebsd.freebsd-fsRe: umount -f implementation| From | Sent On | Attachments |
|---|---|---|
| Rick Macklem | Jun 28, 2009 4:59 pm | |
| Nathanael Hoyle | Jun 28, 2009 5:31 pm | |
| David G Lawrence | Jun 28, 2009 9:52 pm | |
| Attilio Rao | Jun 29, 2009 2:55 am | |
| Rick Macklem | Jun 29, 2009 7:38 am | |
| Rick Macklem | Jun 29, 2009 8:16 am | |
| Bruce Evans | Jun 29, 2009 10:52 am | |
| Rick C. Petty | Jun 29, 2009 4:26 pm | |
| Rick Macklem | Jun 30, 2009 9:00 am | |
| Attilio Rao | Jun 30, 2009 9:07 am | |
| Kostik Belousov | Jun 30, 2009 12:32 pm | |
| Rick Macklem | Jun 30, 2009 1:03 pm | |
| Kirk McKusick | Jun 30, 2009 2:58 pm | |
| Julian H. Stacey | Jun 30, 2009 5:48 pm | |
| Rick Macklem | Jul 1, 2009 10:26 am |
| Subject: | Re: umount -f implementation | |
|---|---|---|
| From: | Rick Macklem (rmac...@uoguelph.ca) | |
| Date: | Jun 30, 2009 1:03:11 pm | |
| List: | org.freebsd.freebsd-fs | |
On Tue, 30 Jun 2009, Kostik Belousov wrote:
I think I can fix this in the experimental nfsv4 client, since it has a kernel thread that can check for MNTK_UNMOUNTF being set and then kill off the RPCs in progress, but that won't help the regular client.
This solution sounds good, but see below.
It may be argued by some people, me included, that umount -f shall not override any ownership of kernel resources. In particular, you must not ignore the lockref. Instead, the threads that own misc filesystem resources, like mount reference counter, locked vnodes etc shall be weed out of the syscalls. E.g., finishing stalled rpc calls with some error code that is propagated to return code from vops is good solution.
I think that the thread "fix" above would work this way. Right now, nfs_umount() terminates RPCs in progress for the "-f" case and they return RPC_CANTRECV, which just becomes EACCES at the moment. The problem is that, often, the "umount -f" thread never gets as far as nfs_umount(). All I was thinking of doing, above, is having the kernel thread check for MNTK_UNMOUNTF and then do the same thing. (ie. The NFS VOPs would end up returning EACCES, or whatever Exxx might be preferred.)
Another problem with forced unmounts is that VFS does not block new threads from arriving into VOPs. When finishing the inflight rpcs, you may either leave some new rpcs behind or loop infinitely chasing rpcs that arrive while you finishing old rpcs.
The NFS clients already handle this by returning ESTALE at the beginning of nfs_request() without attempting the RPC, if MNTK_UNMOUNTF is set. (Why ESTALE?? Who knows, although I suspect that just about any Exxx will get the job done?)
Umount -f is needed in two different situations, one is normally worked filesystem that shall be unmounted by administrative request, detaching any resources opened by application. Second is the last-resort action when backing storage (server in NFS case, disk for UFS) is misbehaving. I think we must not break first case for the second.
I think this is what Bruce Evans was referring to. He suggested that there be two flags, like -f and -F, if I understood his post.
rick
_______________________________________________ free...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-fs To unsubscribe, send any mail to "free...@freebsd.org"