[Cluster-devel] inconsistent dlm_new_lockspace LVB_LEN size from ocfs2 user-space tool and ocfs2 kernel module

[David Teigland <teigland@redhat.com>]

On Fri, May 13, 2016 at 02:36:25AM -0600, Gang He wrote:

> Here is a inconsistent LVB_LEN size problem when create a new lockspace
> from user-space tool (e.g. fsck.ocfs2) and kernel module (e.g.
> ocfs2/stack_user.c).
> From the userspace tool, the LVB size is DLM_USER_LVB_LEN (32 bytes,
> defined in /include/linux/dlm_device.h) From the kernel module, the LVB
> size is DLM_LVB_LEN (64 bytes).

Yes

> Why did we design like this? Look at GFS2 kernel module code, it uses 32
> bytes as LVB_LEN size, it is the same size with  DLM_USER_LVB_LEN macro
> definition. 

The lvb length was originally a constant 32 bytes, and was made variable
after the dlm user interface existed.  The variable length lvb could not
be added to the existing user interface.  (The dlm user interface is
terrible and a new version has been needed for many years, but it's not
used much, so it's not been worth the effort.)

> Now, We encountered a customer issue, the user did a fsck
> on a ocfs2 file system from one node, but aborted without release this
> lockspace (32bytes), then the user mounted this file system.  The kernel
> module would use the existing same lockspace, without creating the new
> lockspace with 64 bytes LVB_LEN.  Next, the bad result was that the user
> could not mount this file system from the other nodes no longer.

> The error messages likes,
> config mismatch: 64,0 nodeid 177127961: 32,0

> Of course, the urgent fix is easy, we can reboot all the nodes, then
> mount the file system again.  But, I want to if there were some reasons
> about this design, otherwise, I want to see if we can use the same size
> between user space and kernel module.

Sorry, I think the only way around this is to ensure that lockspaces are
created from the kernel.

Dave