Losing LVB contents due to "false positive"

Hi all,

I've been looking into how OpenGFS uses Lock Value Blocks (LVBs), as
part of the effort towards getting lock/journal recovery working
properly with OpenDLM lock module.

IIRC, the OpenDLM lock recovery can zero-out LVB contents if it thinks
that the LVB's associated lock *might have been* held in an EX or PW
mode by a node that died.  That is, if another (live) node does not own
an EX or PW lock that would have prevented the dead node from owning EX
or PW, OpenDLM takes the conservative approach and zeroes out the LVB,
under the assumption that the dead node might have altered the LVB.

First of all, do I understand this correctly??

If so, this has the potential to destroy LVB data that might still be
valid (but OpenDLM can't prove that it is) ... a "false positive"
detection of corrupt LVB data.

OpenGFS uses LVB data for 2 purposes:

1) quick exchange of block usage statistics for stat calls
2) inter-node POSIX locks

In the first purpose, the data is duplicated on-disk, so it's easy to
replace if OpenGFS notices that the LVB is all-zeroes.

In the second, however, there is no persistent storage of the POSIX
locks outside of the LVBs, so the data is impossible to replace.  This
seems like a problem.

Does anyone out there have any insight??  Is this a real problem (do
other folks rely on LVBs as the only persistent inter-node shared
storage of critical information)??  If so, any thoughts as to how to
solve it??

Thanks ... have a great weekend!

-- Ben --

Opinions are mine, not Intel's


-------------------------------------------------------
This SF.Net email is sponsored by the new InstallShield X.
From Windows to Linux, servers to mobile, InstallShield X is the one
installation-authoring solution that does it all. Learn more and
evaluate today! http://www.installshield.com/Dev2Dev/0504