linux-stable.git/drivers/block/drbd/drbd_req.c, branch linux-3.8.y

drbd: fix potential protocol error and resulting disconnect/reconnect

2013-01-21T21:58:36+00:00

When we notice a disk failure on the receiving side,
we stop sending it new incoming writes.

Depending on exact timing of various events, the same transfer log epoch
could end up containing both replicated (before we noticed the failure)
and local-only requests (after we noticed the failure).

The sanity checks in tl_release(), called when receiving a
P_BARRIER_ACK, check that the ack'ed transfer log epoch matches
the expected epoch, and the number of contained writes matches
the number of ack'ed writes.

In this case, they counted both replicated and local-only writes,
but the peer only acknowledges those it has seen.  We get a mismatch,
resulting in a protocol error and disconnect/reconnect cycle.

Messages logged are
  "BAD! BarrierAck #%u received with n_writes=%u, expected n_writes=%u!\n"

A similar issue can also be triggered when starting a resync while
having a healthy replication link, by invalidating one side, forcing a
full sync, or attaching to a diskless node.

Fix this by closing the current epoch if the state changes in a way
that would cause the replication intent of the next write.

Epochs now contain either only non-replicated,
or only replicated writes.

Signed-off-by: Philipp Reisner 
Signed-off-by: Lars Ellenberg

Merge branch 'drbd-8.4_ed6' into for-3.8-drivers-drbd-8.4_ed6

2012-11-09T13:20:23+00:00

drbd: log request sector offset and size for IO errors

2012-11-09T13:11:41+00:00

Signed-off-by: Philipp Reisner 
Signed-off-by: Lars Ellenberg

drbd: always write bitmap on detach

2012-11-09T13:11:41+00:00

If we detach due to local read-error (which sets a bit in the bitmap),
stay Primary, and then re-attach (which re-reads the bitmap from disk),
we potentially lost the "out-of-sync" (or, "bad block") information in
the bitmap.

Always (try to) write out the changed bitmap pages before going diskless.

That way, we don't lose the bit for the bad block,
the next resync will fetch it from the peer, and rewrite
it locally, which may result in block reallocation in some
lower layer (or the hardware), and thereby "heal" the bad blocks.

If the bitmap writeout errors out as well, we will (again: try to)
mark the "we need a full sync" bit in our super block,
if it was a READ error; writes are covered by the activity log already.

If that superblock does not make it to disk either, we are sorry.

Maybe we just lost an entire disk or controller (or iSCSI connection),
and there actually are no bad blocks at all, so we don't need to
re-fetch from the peer, there is no "auto-healing" necessary.

Signed-off-by: Philipp Reisner 
Signed-off-by: Lars Ellenberg

drbd: differentiate early and later "postponing" of requests

2012-11-09T13:11:37+00:00

We use the RQ_POSTPONED flag to mark a request for several reasons.

It may be a conflicting request in a dual-primary setup,
where conflict detection and resolution on the peer decided that
this request needs to be re-submitted, it needs to re-enter
drbd_make_request() to fix the data divergence caused by these
conflicting, partially overlapping, quasi-simultaneous requests.

In this case we need to mark the corresponding area as out-of-sync,
before we call drbd_al_complete_io().

We also use the RQ_POSTPONED flag to just "push back" a request,
before even processing it, if IO is suspended for some reason.
In this case, as this request was neither submitted nor sent yet,
we must not touch the bitmap.

Signed-off-by: Philipp Reisner 
Signed-off-by: Lars Ellenberg

drbd: Fix postponed requests

2012-11-09T13:11:37+00:00

A postponed request might has RQ_IN_ACT_LOG already set, but
is POSTPONED before it gets something in the RQ_LOCAL_MASK
set. Up to now this caused a left-over active extent.

Fix that by only testing for the RQ_IN_ACT_LOG bit in drbd_req_destroy()

Signed-off-by: Philipp Reisner 
Signed-off-by: Lars Ellenberg

drbd: Fix postponed requests

2012-11-09T13:08:24+00:00

* Postponed requests should not set or clear out-of-sync marks
* When a request gets postponed we need to drop its reference
  mdev->local_cnt (put_ldev()).

Signed-off-by: Philipp Reisner 
Signed-off-by: Lars Ellenberg

drbd: Fix completion of requests while the device is suspended

2012-11-09T13:05:50+00:00

In various places (E.g. CONNECTION_LOST_WHILE_PENDING) the
RQ_COMPLETION_SUSP mask is passed in the clear set to mod_rq_state().

The issue was that it tried to clear the RQ_COMPLETION_SUSP bit
out of the state mask first, and eventuelly set it afterwards,
in the drbd_req_put_completion_ref() function.

Fixed that by moving the reference getting out of
drbd_req_put_completion_ref() into the mod_rq_state(), before the place
where the extra reference might be put.

Signed-off-by: Philipp Reisner 
Signed-off-by: Lars Ellenberg

drbd: disambiguation, s/P_DISCARD_WRITE/P_SUPERSEDED/

2012-11-09T13:05:49+00:00

To avoid confusion with REQ_DISCARD aka TRIM, rename our
"discard concurrent write acks" from P_DISCARD_WRITE to P_SUPERSEDED.

At the same time, rename the drbd request event DISCARD_WRITE
to CONFLICT_RESOLVED. It already triggers both successful completion
or restart of the request, depending on our RQ_POSTPONED flag.

Signed-off-by: Philipp Reisner 
Signed-off-by: Lars Ellenberg

drbd: NEG_ACK does not imply a barrier-ack

2012-11-09T13:05:48+00:00

Don't drop a request from the transfer log just because it was NEG_ACKED.
We need it around to be able to verify P_BARRIER_ACKs against the
transver log.

Signed-off-by: Philipp Reisner 
Signed-off-by: Lars Ellenberg