NLM - lock failover
Get series with b4
b4 am [email protected]Versions newest first
- v1 Latest0 of 4 patches 0 repliesNew
Patches in v1 No applies recorded yet
None of the 4 patches the cover letter announces are in this archive.
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [Cluster-devel] [PATCH 0/4 Revised] NLM - lock failover
Quoted 7 lines · Neil Brown
One thing that has been bothering me is that sometimes the "filesystem" (in the guise of an fsid) is used to talk to the kernel about failover issues (when flushing locks or restarting the grace period) and sometimes the local network address is used (when talking with statd).
This is a perception issue - it depends on how the design is described. More on this later.
Quoted 5 lines
I would rather use a single identifier. In my previous email I was leaning towards using the filesystem as the single identifier. Today I'm leaning the other way - to using the local network address.
Guess you're juggling with too many things so forget why we came down to this route ? We started the discussion using network interface (to drop the locks) but found it wouldn't work well on local filesytems such as ext3. There is really no control on which local (sever side) interface NFS clients will use (shouldn't be hard to implement one though). When the fail-over server starts to remove the locks, it needs a way to find *all* of the locks associated with the will-be-moved partition. This is to allow umount to succeed. The server ip address alone can't guarantee that. That was the reason we switched to fsid. Also remember this is NFS v2/v3 - clients have no knowledge of server migration.
Now, let's move back to first paragraph. An active-active failover can be described as a 5-steps process:
Step 1. Quiesce the floating network address.
Step 2. Move the exported filesystem directories from Server A to Server B. Step 3. Re-enable the network interface.
Step 4. Inform clients about the changes via NSM (Network Status Monitor) Protocol.
Step 5. Grace period.
I was told last week that, independent of lockd, some cluster filesystems do have their own implementation of grace period. It is on the wish list that this feature is taken into consideration. IMHO, the overall process should be viewed as a collaboration between filesystem, network interface, and NFS protocol itself. Mixing the filesystem and network operations are unavoidable.
On the other hand, the current proposed interface is expandable .. say, prefix a non-numerical string "DEV" or "UUID" to ask for dropping locks as in:
shell> echo "DEV12390 > /proc/fs/nfsd/nlm_unlock;
or allow individual grace period of 10 seconds as:
shell> echo "1234@10" > nlm_set_grace_for_fsid
With above said, some of the following flow confuses me ... comment inlined as below ..
Quoted 8 lines
It works like this:
We have a module parameter for lockd something like "
virtual_server".
If that is set to 0, none of the following changes are effective. If it is set to 1:
ok with me ...
Quoted 4 lines
The destination address for any lockd request becomes part of the key to find the
nsm_handle.
As explained above, the address along can't guarantee the associated locks get cleaned up for one particular filesystem.
Quoted 4 lines
The
my_namefield inSM_MONrequests andSM_UNMONrequests is set to a textual representation of that destination address.
That's what the current patch does.
Quoted 9 lines
The reply to
SM_MON(currently completely ignored by all versions of Linux) has an extra value which indicates how many more seconds of grace period there is to go. This can be stuffed intores_statmaybe.
Places where we currently check 'nlmsvc_grace_period', get moved to *after* thenlmsvc_retrieve_argscall, and thegrace_periodvalue is extracted fromhost->nsm.
ok with me but I don't see the advantages though ?
Quoted 11 lines
This is the full extent of the kernel changes.
To remove old locks, we arrange for the callbacks registered with statd for the relevant clients to be called.
To set the grace period, we make sure statd knows about it and it will return the relevant information to lockd.
To notify clients of the need to reclaim locks, we simple use the information stored by statd, which contains the local network address.
I'm lost here... help ?
Quoted 7 lines
The only aspect of this that gives me any cause for concern is overloading the return value for
SM_MON. Possibly it might be cleaner to define anSM_MON2with different args or whatever.
As this interface is entirely local to the one machine, and as it can quite easily be kept back-compatible, I think the concept is fine.
Agree !
Quoted 6 lines
Statd would need to pass the
my_namefield to the ha callout rather than replacing it with "127.0.0.1", but other than that I don't think any changes are needed to statd (though I haven't thought through that fully yet).
That's the current patch does.
Quoted 5 lines
Comments?
I feel we're in the loop again... If there is any way I can shorten this discussion, please do let me know.
-- Wendy
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs