[Ocfs2-devel] lvb length issue [was Re: [ocfs2-tools-devel] question of ocfs2_controld (Jun 27)]

[Joel Becker]

On Thu, Jul 09, 2009 at 04:55:04PM -0500, David Teigland wrote:
> On Thu, Jul 09, 2009 at 01:55:28PM -0700, Joel Becker wrote:
> > On Thu, Jul 09, 2009 at 01:53:38PM -0500, David Teigland wrote:
> > > Here's a kernel patch that I've not yet tried.  The code using libdlm will
> > > need to add the flag 0x00000010 to dlm_new_lockspace().  (Until we've added
> > > the new LVB64 define to libdlm.h.)
> > > 
> > > >From 75e92c78bb0b0002f0253bfe10bef8585a0d52d6 Mon Sep 17 00:00:00 2001
> > > From: David Teigland <teigland at redhat.com>
> > > Date: Thu, 9 Jul 2009 13:11:02 -0500
> > > Subject: [PATCH] dlm: add DLM_LSFL_LVB64 for lockspace creation
> > > 
> > > Add a new flag DLM_LSFL_LVB64 to create lockspaces with 64 byte lvbs,
> > > overriding the lvb length parameter.  It is useful to override the
> > > fixed 32 byte lvb imposed by the user api when the lockspace is created
> > > from userspace but used from the kernel.  Locking through the user api
> > > can still only access 32 byte lvbs.
> > 
> > 	Hmm, you're tying a permanent flag to 64bytes, yet userspace
> > can't get at them?  Seems a bit too ocfs2-tools specific, and yet it
> > doesn't let ocfs2-tools eventually try to share the lvb.
> 
> Yes, I think the only other sane option is to do full variable-sized lvb
> support for userspace.  That would be nice, and I wouldn't mind doing it.  But
> it would take significant user/kernel api work, and take some time, of course.

	Well, my original idea of an IGNORE_LVB flag, with code in
libdlm to error if the LVB functoins are used, would not be tied to a
specific LVB size and would prevent miss-matched LVB ops.

Joel

-- 

"Reader, suppose you were and idiot.  And suppose you were a member of
 Congress.  But I repeat myself."
	- Mark Twain

Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker at oracle.com
Phone: (650) 506-8127