Hi!
On 11/16/2016 11:08 PM, David Teigland wrote:
....
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.
Thanks a lot! Yes, the ocfs2 developer had handled this situation by this patch:
"[Ocfs2-devel] [PATCH] ocfs2: Provide the ocfs2_dlm_lvb_valid() stack
API"
from
https://oss.oracle.com/pipermail/ocfs2-devel/2009-June/004752.html
Comments of this patch:
"""
The Lock Value Block (LVB) of a DLM lock can be lost when nodes die and
the DLM cannot reconstruct its state. Clients of the DLM need to know
this.
ocfs2's internal DLM, o2dlm, explicitly zeroes out the LVB when it loses
track of the state. This is not a standard behavior, but ocfs2 has
always relied on it. Thus, an o2dlm LVB is always "valid".
ocfs2 now supports both o2dlm and fs/dlm via the stack glue. When
fs/dlm loses track of an LVBs state, it sets a flag
(DLM_SBF_VALNOTVALID) on the Lock Status Block (LKSB). The contents of
the LVB may be garbage or merely stale.
ocfs2 doesn't want to try to guess at the validity of the stale LVB.
Instead, it should be checking the VALNOTVALID flag. As this is the
'standard' way of treating LVBs, we will promote this behavior.
We add a stack glue API ocfs2_dlm_lvb_valid(). It returns non-zero when
the LVB is valid. o2dlm will always return valid, while fs/dlm will
check VALNOTVALID.
Signed-off-by: Joel Becker <joel.becker at oracle.com
<http://oss.oracle.com/mailman/listinfo/ocfs2-devel>>
"""
Thanks!
Eric
Dave
