[Drbd-dev] Re: [Linux-ha-dev] [RFC] (CRM and) DRBD (0.8) states and transistions, recovery strategies

[Lars Ellenberg]

/ 2004-09-26 20:40:36 +0200
\ Andrew Beekhof:
> 
> On Sep 24, 2004, at 11:11 PM, Lars Marowsky-Bree wrote:
> 
> >On 2004-09-24T16:29:25,
> >   Lars Ellenberg <Lars.Ellenberg at linbit.com> said:
> >
> >>some of this applies to replicated resources in general,
> >>so Andrew may have some ideas to generalize it...
> >
> >I think the modelling we have so far (with the recent addendum) 
> >captures
> >this quite nicely for the time being. But of course, it'll help us to
> >verify this.
> 
> right.  i also be thinking more about this in the coming days when I 
> start on the incarnations.
> 
> >
> >>    Some of the attributes depend on others, and the information 
> >>about the
> >>    node status could be easily encoded in one single letter.
> >>
> >>    But since HA is all about redundancy, we will encode the node 
> >>status
> >>    redundantly in *four* letters, to make it more obvious to human 
> >>readers.
> >>
> >>     _        down,
> >>     S        up, standby (non-active, but ready to become active)
> >>     s        up, not-active, but target of sync
> >>     i        up, not-active, unconnected, inconsistent
> >>     o        up, not-active, unconnected, outdated
> >>     d        up, not-active, diskless
> >>     A        up, active
> >>     a        up, active, but target of sync
> >>     b        up, blocking, because unconnected active and 
> >>inconsistent
> >>                            (no valid data available)
> >>     B        up, blocking, because unconnected active and diskless
> >>                            (no valid data available)
> >>     D        up, active, but diskless (implies connection to good 
> >>data)
> >>      M       meta-data storage available
> >>      _       meta-data storage unavailable
> >>       *      backing storage available
> >>       o      backing storage consistent but outdated
> >>              (refuses to become active)
> >>       i      backing storage inconsistent (unfinished sync)
> >>       _      diskless
> >>        :     unconnected, stand alone
> >>        ?     unconnected, looking for peer
> >>        -     connected
> >>>    connected, sync source
> >>        <     connected, sync target
> >
> >I'd structure this somewhat differently into the node states (Up, 
> >Down),
> >our assumption about the other node (up, down, fenced), Backing Store
> >states (available, outdated, inconsistent, unavailable), the connection
> >(up or down) and the relationship between the GCs (higher, lower,
> >equal).
> >
> >(Whether we are syncing and in what direction seems to be a function of
> >that, same whether or not we are blocking or not.)
> >
> >It's essentially the same as your list, but it seems to be more
> >accessible to me. But, it's late ;-)
> 
> I agree here... restricting the attributes to true inputs (rather than 
> derived values) helps stop my brain going into meltdown trying to 
> absorb the matrix :)  I could also imagine that it makes your life 
> easier if you decide to change how you decide something like syncing 
> direction later on.

ok.
I'll try again, and maybe create a dot file while I'm at it :)

even though my "states" are not actually "derived".
but maybe only "obvious" to the "insider" (me).

so, for the time being, could you please have a look at
 http://wiki.trick.ca/linux-ha/DRBD/StateMachine

and maybe comment it.

	lge