[Drbd-dev] roadmap draft
lmb at suse.de
Thu Sep 9 12:05:52 CEST 2004
Philipp Reisner <philipp.reisner at linbit.com> said:
> DRBD 0.8 Roadmap
> 1 Drop support for linux-2.4.x.
> Do all size calculations on the base of sectors (512 Byte) as it
> is common in Linux-2.6.x.
> (Currently they are done on a 1k base, for 2.4.x compatibility)
For all I care, 2.4 can die die die any second... ;-)
> 4 Two new config options, to allow more fine grained definition of
> DRDBs behaviour after a split-brain situation:
> after-sb-2pri =
> disconnect No automatic resynchronisation gets performed. One
> node should drop its net-conf (preferable the
> node that would become sync-target)
> asf-older Auto sync from is the oder primary (curr.behaviour i.t.s.)
> asf-younger Auto sync from is the younger primary
> asf-furthest Auto sync from is the node that did more modifications
> asf-NODENAME Auto sync from is the named node
With the 'preferrably the node which would become sync-target'
constraint, you would need to allow to specify one of the other methods
too (how else would you determine which node would become sync-target?).
> pri-sees-sec-with-higher-gc =
> disconnect (current behaviour)
> asf-primary Auto sync from is the current primary
> panic The current primary panics. The node with the
> higher gc should take over.
> 1) The disconnect actions cause the sync-target or the secondary
> node to go into StandAlone state.
> 2) If two nodes in primary state try to connect one of them goes
> into StandAlone state (=curr. behaviour)
1+2 - I'd rather prefer a symmetric scenario where both nodes go to
> 3) As soon as the decision is takes the sync-target adopts the
> GC of the sync source.
> [ The whole algorithm would also work if both would reset their
> GCs to <0,0,0...> after the decision, but since we also
> use the GC to tag the bitmap it is better the current way ]
> 5 It is possible that a secondary node crashes a primary by
> returning invalid block_ids in ACK packets. [This might be
> either caused by faulty hardware, or by a hostile modification
> of DRBD on the secondary node]
> Proposed solution:
I'd just keep a map of outstanding ACKs and compare any ACK received
against that list. Wouldn't that solve this?
> 6 Support IO fencing; introduce the "Dead" peer state (o_state)
Dead peer state + Outdated flag seems good, but regarding the 'fence', I
defer this to the other thread ;-)
Lars Marowsky-Brée <lmb at suse.de>
High Availability & Clustering \\\ ///
SUSE Labs, Research and Development \honk/
SUSE LINUX AG - A Novell company \\//
More information about the drbd-dev