J. Bruce Fields wrote:
On Thu, Jan 24, 2008 at 02:45:37PM -0500, Wendy Cheng wrote:
J. Bruce Fields wrote:
In practice, it seems that both the unlock_ip and unlock_pathname
methods that revoke locks are going to be called together. The two
separate calls therefore seem a little redundant. The reason we *need*
both is that it's possible that a misconfigured client could grab locks
for a (server ip, export) combination that it isn't supposed to.
That is not a correct assumption. The two commands (unlock_ip and
unlock_pathname) are not necessarily called together. It is ok for local
filesystem (ext3) but not for cluster filesystem where the very same
filesystem (or subtree) can be exported from multiple servers using
different subtrees.
Ouch. Are people really doing that, and why? What happens if the
subtrees share files (because of hard links) that are locked from both
nodes?
It is *more* common than you would expect - say server1 exports
"/mnt/gfs/maildir/namea-j" and server2 exports "/mnt/gfs/maildir/namek-z".
Also as we discussed before, it is
"unlock_filesystem", *not* "unlock_pathname" (this implies sub-tree
exports) due to implementation difficulties (see the "Implementation
Notes" from http://people.redhat.com/wcheng/Patches/NFS/NLM/004.txt).
Unless I misread the latest patch, it's actually matching on the
vfsmount, right?
Yes.
I guess that means we *could* handle the above situation by doing a
mount --bind /path/to/export/point /path/to/export/point
on each export, at which point there will be a separate vfsmount for
each export point?
Cluster configuration itself has been cumbersome and error-prone.
Requirement like this will not be well received. On the other hand,
force-unlock a mount point is a *last* resort - since NFS clients using
another ip interface would lose the contact with the server. We should
*not* consider "unlock_filesystem" a frequent event.
But I don't think that's what we really want. The goal is to ensure
that the nfs server holds no locks on a disk filesystem so we can
unmount it completely from this machine and mount it elsewhere. So we
should really be removing all locks for the superblock, not just for a
particular mount of that superblock. Otherwise we'll have odd problems
if someone happens to do the unlock_filesystem downcall from a different
namespace or something.
Oh ... sorry .. didn't read this far... so we agree the "--bind" is not
a good idea :) ..
-- Wendy
