[Cluster-devel] Question on LVB when the node that held EX lock crash

[David Teigland <teigland@redhat.com>]

On Wed, Nov 16, 2016 at 04:42:09PM +0800, Eric Ren wrote:
> On 11/16/2016 04:29 PM, Eric Ren wrote:
> > Hi David and all,
> > 
> > I am debugging an issue of ocfs2 that relates to LVB value. I will try
> > to make it a pure DLM question:
> > 
> > Two nodes (N1, N2) try to truncate the same file(R1) concurrently.
> > 
> > N1                                         N2
> > lock(R1, EX)
> > changing LVB: x
> >                                               lock(R1, EX)
> > convert(R1, NULL)
> > flush LVB
> >                                               changing LVB: x -> y
> >                                               crash
> 
> Hmm, here should be a long story of DLM recovery;-)
> 
> Eric
> > convert(R1, EX)
> > get LVB
> > Qustion: what is the LVB then? x or y?
> > ======
> > 
> > Is this a valid question? or am I missing something?

It's a good question, and it's been enough years that the details are now
hazy.  I think the current behavior emulates the original VMS dlm model
fairly well, so any documentation you can find on that may help.

If you look at the recover_lvb() comment, you'll see a little information
about this.  The LVB can be lost in a crash in some fairly common cases,
and in those cases, the dlm should set the VALNOTVALID flag to tell the
application that the LVB may be lost/stale.  So, an application cannot
rely entirely on the LVB, and must be able to go without it, or
reconstruct the value, i.e. the LVB data is usually used as part of an
optimization (e.g. caching).

The two cases mentioned in that comment are:

1. if N1 was R1 master when N2 crashed: N1 would purge the EX lock from
N2, and set VALNOTVALID on R1, because the latest LVB from N2 was never
seen by N1.

2. if N2 was R1 master when N2 crashed: N1 would become the new R1 master
(if it kept a NL lock on it), and would set VALNOTVALID because it doesn't
know if N2 had any EX locks from other nodes that might have also crashed,
or an LVB that had been updated since N1 last saw it.

Dave