[Ocfs2-devel] lvb length issue [was Re: [ocfs2-tools-devel] question of ocfs2_controld (Jun 27)]
David Teigland
teigland at redhat.com
Thu Jul 9 14:55:04 PDT 2009
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.
Dave
More information about the Ocfs2-devel
mailing list