Bug 188023

Created attachment 127353 [details]
proposed patch for svclib_filesystem

This patch is contingent on the kernel interface for it (BZ 180524) going in
(though using this script on a kernel without it shouldn't hurt, it just won't
do anything).

This adds a new function to the script to echo the device into the /proc file,
and calls it if $force_umount is set.

This is not tested as of yet, and will need to be before we can hand off to the
customer.

Since the kernel interface is officially NAK'ed, I suppose we can use the
original patch I sent up to fix this as a starting point:

https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=124399

Some design questions:

1) do we want to do like this patch does, and only send a SIGKILL to lockd as a
last resort (only if all prior umount attempts fail), or do we want to have it
send on the first attempt?

I the former is probably better, in that it won't be as likely to cause locking
issues, but the latter might be better from a predictability standpoint (users
can expect that all locks will get dropped whenever the service fails over).

2) Do we want this to be a global, per-service, or per-mount option?

Per-service is difficult to document in a user-friendly way.

I would only drop locks when *absolutely* necessary.

Note that this would mean that -

* It's a global option of whether to try killing lockd on unmount, and that
* per-device "force unmount" would need to be enabled in order for lockd to be
killed

So, it's coarse "load the bazooka" at the global level, and "fire the bazooka if
this device doesn't unmount" at the device level.

Created attachment 127796 [details]
new patch that checks cludb setting

New patch based on Lon's last comments. This one checks for a global cludb
setting (clusvcmgrd%nlm_drop_locks) if $force_umount is set. Then on the last
pass on attempting to unmount the filesystem, we'll send the SIGKILL to lockd.

I've not tested this patch, but I think it will work, though you may want to
add some more indirection and such.

hah! That looks good

FYI, as it turns out, more than this is going into U8, at the last minute.  We
should have lock reclaims on relocation, but it will not work on failover
because there's no HA-callout in RHEL3 nfs-utils.

I also hit a point where a lock being held somehow seemed to prevent the device
from being unmounted - even if I stopped NFS (including lockd) entirely.  I
don't understand this one, but it's beyond the scope of this bugzilla.

Created attachment 128570 [details]
NFS drop / reclaim / etc. patch

Big patch which issues reclaims after killing lockd.

Jeff, would you prefer putting both in or just the big-one?

I didn't go over the whole thing, but your patch looks like a superset of mine,
so I think yours would be sufficient here. Unless I'm missing something here?

From RHCS perspective, this is done.

However, there's nothing I can do about 167636 from userspace; it seems that if
you kill lockd after taking a lock from an NFS client, there's a good chance
that the lock will not correctly get dropped, and calling umount will return EBUSY.

See bugzilla 167636 for more details.

So, until the kernel side is fixed, this bug will remain open.

167636 is closed -> wontfix

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2006-0505.html