Fix DRBD8 diskless assembling
authorIustin Pop <iustin@google.com>
Thu, 8 May 2008 08:20:00 +0000 (08:20 +0000)
committerIustin Pop <iustin@google.com>
Thu, 8 May 2008 08:20:00 +0000 (08:20 +0000)
The algorithm for attaching to existing DRBD devices is not trivial. It
has four alternatives, and there is a bug in the last one when we have
diskless devices.

The last case (local disk info matches but remote/network configuration
doesn't match) we disconnect from the network and reattach with the
correct info. We do this because correct local device has higher
priority than remote device.

However, the test we use (self._MatchesLocal) can succeed in two cases:
  - we have a disk and it's the same as the one attached
  - we don't have a disk and the drbd is in diskless mode

But this creates problems for the fourth case as when we already have
one diskless DRBD, activating then next one will do:
  - _MatchesLocal? yes, because both config data and system have no
    disks (with the effect that all diskless devices are identical)
  - _MatchesRemote? no, because this disk is configured to its current
    remote peer, not to our new one

The fix is trivial, although the algorithm not: we only allow overriding
the network configuration when the disk information matches and we are
not diskless, by adding the <"local_dev" in info'> test.

Reviewed-by: ultrotter

lib/bdev.py

index c7d2a83..7bb6696 100644 (file)
@@ -2140,7 +2140,13 @@ class DRBD8(BaseDRBD):
       # even though we were passed some children at init time
       if match_r and "local_dev" not in info:
         break
-      if match_l and not match_r and "local_addr" in info:
+
+      # this case must be considered only if we actually have local
+      # storage, i.e. not in diskless mode, because all diskless
+      # devices are equal from the point of view of local
+      # configuration
+      if (match_l and "local_dev" in info and
+          not match_r and "local_addr" in info):
         # strange case - the device network part points to somewhere
         # else, even though its local storage is ours; as we own the
         # drbd space, we try to disconnect from the remote peer and