Description of problem:

There are a couple cases where a host will zero its dblock values on disk: when releasing a lease, and when changing the shared flag in the mode block.  This zeroing was added by commit d6bef45b9716c581d99466280a52a01c9ebe3bf7 without understanding the effect it would have on a concurrent running of a paxos ballot.  This usually happens under fast, repeated attempts by multiple hosts to acquire a lease in both shared and exclusive modes at once.

If a host zeros its own dblock values while other hosts are running a paxos ballot, it can interfere with the paxos algorithm, and cause other hosts to acquire the same version of the lease (lver) that was already acquired.  As far as I can tell, this only happens when releasing the lease from one host, so the effect should not be that multiple hosts are actually using the lease at once, even though technically, hosts holding the same lease version indicates that they are.  So, while the effect may not be severe, this is a severe violation of the algorithm as designed, i.e. that the lease version increments each time it's acquired so that only one host will own a given lease version.


Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info: