[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

[Cluster-devel] Re: [NFS] [PATCH 0/3] NLM lock failover

Neil Brown wrote

This patch makes an assumption that any given filehandle will only arrive at
one particular interface - never more.  This is implicit in the fact
that f_iaddr is stored in 'struct nlm_file' which is indexed by

In the case where you are intending to support active-active failover
this is should be the case, but obviously configuration errors are

I think what I would like is that if requests arrive at two (or more)
different interfaces for the one file, then f_iaddr is cleared and some
flag is set.
When an IP is written to nlm_unlock, if the flag is set, then a
warning message is printer Note: some files access via multiple interfaces will not be

Have given this issue a long thought during the weekend. The suggested changes will work but so is "fsid" approach. I prefer "fsid" because it is simpler to implement and very effective. The problem with this approach is that it is a little bit awkward to explain - I don't believe it is well-understand (or even aware of ) by most of the system admin(s). We may need a good write-up for the procedures. It, however, effectively handles the issues associated with an export entry getting accessed by multiple virtual ip interfaces.

The test runs (with fsid) today have been encouraging. Will push the revised patches for review as soon as they pass some sanity checks and testings. However, the following is the main changes made by this new implementation:

First, it is required to export the filesystem using "fsid"; e.g. "export *:/mnt/tank1 (fsid=9468,rw) ". Patch 1: Drop the locks based on fsid; e.g. "echo 9468 > /proc/fs/nfsd/nlm_unlock" Patch 2: Set individual grace period based on fsid "echo 9468 > /proc/fs/nfsd/nlm_set_igrace" Patch 3: Utility functions to allow cluster suite (or system admin) to implement its own client reclaim notifications.

Unfortunately, it is too cumbersome to switch Patch 3 using fsid. So the old trick stays (we still use server ip to facilitate the client reclaim notification process).

In the mean time, the following is how I yank the fsid out of file handle. Send it here for preview purpose. If anyone spots anything wrong, please do let me know. This will be the "guts" of this whole thing:

-- Wendy

+ * Get fsid from nfs_fh:
+ * return 0 if *fsid contains a valid value.
+ */
+nlm_fo_get_fsid(struct nfs_fh *fh, int *fsid)
+	struct nfs_fhbase_new *fh_base = (struct nfs_fhbase_new *) fh->data;
+	int data_left = fh->size/4;
+	nlm_debug_print_fh("nlm_fo_find_fsid", fh);
+	/* From fb_version to fb_auth - at least two u32 */
+	if (data_left < 2)		
+		return -1;
+	/* For various types, check out 
+	 * inlcude/linux/nfsd/nfsfsh.h
+	 */
+	if ((fh_base->fb_version != 1) ||  
+		(fh_base->fb_auth_type != 0) ||
+		(fh_base->fb_fsid_type != 1))
+		return -1;
+	/* The fb_auth is 0 bytes long - imply fb_auth[0] has
+	 * fsid value.
+	 */
+	*fsid = (int) fh_base->fb_auth[0];
+	return 0;

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]