[Drbd-dev] ordering problem between StateChangeRequest and send_state

Graham, Simon Simon.Graham at stratus.com
Sat Feb 2 04:21:59 CET 2008


I have seen a problem where if resync is paused and resumed and then completed quickly, the sync target node correctly transitions to UptoDate but the other ends up Inconsistent. I believe this is a reordering issue caused by an interaction between drbd_send_state_req and drbd_send_state as follows (with the resync starting off in the paused state):

1. We resumed syncing and set aftr_isp->0 -- this schedules a work item to report the change
   to the peer.

2. Syncing completes on an other thread, drbd_send_state_req is called inline to send the
   new state to the peer with a StateChgRequest, BUT the mdev state is not updated yet. 
   This code then waits for a response from the peer... when the peer gets this, it updates
   it's state immediately (to Consistent) and sends the response.

3. Now the after state change starts running and does a send-state call which grabs
   the current state from the device (which is still inconsistent) and sends this. When
   the peer gets this, it will change from UpToDate->Inconsistent.

4. Finally, we get the response to the StateChgRequest and change the state to UpToDate on
   the sync target - no further state change is sent because transition to UpToDate doesn't
   generate one.

My suggested fix is to use the existing drbd_state_lock - this is already used in drbd_send_state_req, my suggestion is to also grab it in drbd_send_state so that we don't attempt to send ReportState if a state change rq is already in progress.

I've attached a proposed patch that implements this suggestion BUT this is based on an earlier patch of ours that splits drbd_send_state into two routines and acquires the send mutex - the one titled "Ensure that state updated cannot be done out of order whilst running receive_state (914435c)".

Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Make-sure-we-dont-send-state-if-a-cluster-wide-state.patch
Type: application/octet-stream
Size: 832 bytes
Desc: 0001-Make-sure-we-dont-send-state-if-a-cluster-wide-state.patch
Url : http://lists.linbit.com/pipermail/drbd-dev/attachments/20080201/e518fe23/0001-Make-sure-we-dont-send-state-if-a-cluster-wide-state.obj


More information about the drbd-dev mailing list