ubik: Record the last write tid in writeTidCounter
authorAndrew Deason <adeason@sinenomine.net>
Wed, 1 Sep 2010 20:10:56 +0000 (15:10 -0500)
committerDerrick Brashear <shadow@dementia.org>
Mon, 15 Nov 2010 17:47:05 +0000 (09:47 -0800)
commita0cc81c0894193db11860d8fe40380c7198741a9
tree8f2ff0f18cf1cff4050305a528bae7f893b99289
parentbdbc4494602cf142e2dc046a234dd4ba8610cd51
ubik: Record the last write tid in writeTidCounter

ubik is currently tracking writeTidCounter for write transactions
separately from regular transactions (assigned from tidCounter).
Specifically, tidCounter is incremented twice for each transaction,
but writeTidCounter is incremented twice only for write transactions.
As a result, writeTidCounter and tidCounter tend to drift far apart.

This is a problem, since the tid for DISK_* calls uses the transaction
id of the current transaction (based on tidCounter), and VOTE_Beacon
uses writeTidCounter for its transaction id. So, in effect, the tid in
VOTE_Beacon is completely bogus and unrelated to the transaction id of
the actual current write transaction. This can cause valid write
transactions to become invalidated when tidCounter becomes negative,
since VOTE_Beacon will send a positive tid, and if there is a current
in-flight write transaction with a negative tid, SVOTE_Beacon will
deem the transactions inequal and will abort the write transaction.

So instead, record the transaction id counter for the last write
transaction in writeTidCounter. This way, when we call VOTE_Beacon, we
will use the correct transaction id counter for the current write
transaction, and SVOTE_Beacon on the remote site will not invalidate
the transaction.

Change-Id: I66f290d21fefdfcf9bd9deb704eefff987fe6970
Reviewed-on: http://gerrit.openafs.org/2647
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Derrick Brashear <shadow@dementia.org>
src/ubik/ubik.c