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
