[Drbd-dev] Re: [Linux-ha-dev] [RFC] (CRM and) DRBD (0.8) states and
transistions, recovery strategies
lists at beekhof.net
Mon Sep 27 14:38:30 CEST 2004
On Sep 27, 2004, at 2:19 PM, Lars Ellenberg wrote:
> / 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)
>>> 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
>>>> redundantly in *four* letters, to make it more obvious to human
>>>> _ 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
>>>> (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
>>>> 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,
>>> our assumption about the other node (up, down, fenced), Backing Store
>>> states (available, outdated, inconsistent, unavailable), the
>>> (up or down) and the relationship between the GCs (higher, lower,
>>> (Whether we are syncing and in what direction seems to be a function
>>> 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.
> I'll try again, and maybe create a dot file while I'm at it :)
I think you'll find that a helps a lot (I know it helped me with the
> even though my "states" are not actually "derived".
> but maybe only "obvious" to the "insider" (me).
I think it depends on the POV you take and how you break it up...
I would say "syncing" is a state, but the direction is derived and who
we and the other side are (master/slave/...) are also inputs.
Otherwise you need states for every combination and (at least in the
CRM) I didn't find that gave me much (except for a really huge .dot
> so, for the time being, could you please have a look at
> and maybe comment it.
> Linux-HA-Dev: Linux-HA-Dev at lists.linux-ha.org
> Home Page: http://linux-ha.org/
"Ooo Ahhh, Glenn McRath" - TISM
More information about the drbd-dev