Distributed Replicated Block Device (DRBD) development
 help / color / mirror / Atom feed
From: Philipp Reisner <philipp.reisner@linbit.com>
To: drbd-dev@lists.linbit.com
Subject: Re: [Drbd-dev] [RFC] (CRM and) DRBD (0.8) states and transistions, recovery strategies
Date: Wed, 6 Oct 2004 13:55:40 +0200	[thread overview]
Message-ID: <200410061355.40551.philipp.reisner@linbit.com> (raw)
In-Reply-To: <gp+4keo9JvnjO0Q6qwMw9f0=lge@web.de>

[-- Attachment #1: Type: text/plain, Size: 2125 bytes --]

On Wednesday 29 September 2004 19:07, Lars Ellenberg wrote:
> / 2004-09-29 14:58:47 +0200
>
> \ Philipp Reisner:
> > > [...]
> > >
> > > >     Currently this covers only the states, and outlines the
> > > > transitions. It should help to define the actions to be taken on
> > > > every possible "input" to the DRBD internal "state machine".
> > >
> > > While reading through this giant e-mail I lost my confidence that it
> > > could be a good idea to have a "central" state switching function in
> > > DRBD, but of course I will see what this discussions gives...
> >
> > Thought about this a bit more... and came to the conclusion that it
> > would be a good idea. What do you think of this skeleton -
> > pseude code (it compiles actually).
>
> I think it probably should come out more like a real state machine,
> with a defined set of possible INPUTS,
> a defined set of states (which should not have the same detail depth as
> the actual drbd internal state set with all its different attributes),
> a set of actions, and a defined state[INPUT] => action => newstate
> matrix.
>
> maybe that is overkill.

Currently I want to go the way that was outlined with the new_st.c
skeleton.

Regarding: only worker should do state changes.
  We have quite a lot of inputs that are asynchronous by their nature.
  E.g. Disk fails. It does not make any sense to synchronize an advance
  in the disk-state state-machine with anything.

While it makes a lot of sense to synchronize changes to the node
state machine. 

At first I drew a directed graph of the cstates we have in 
drbd-0.7 (see cstates-7.ps)

You will immediately realize that the differentiation between
Unconfigured and StandAllone is a leftover from drbd-0.6

Then I drew directed graphs of the "state machines" as I see
them for drbd-0.8

conn-states-8.ps, disk-states-8.ps, node-states-8.ps (has 2 pages)

PS: The program is graphviz

-Philipp
-- 
: Dipl-Ing Philipp Reisner                      Tel +43-1-8178292-50 :
: LINBIT Information Technologies GmbH          Fax +43-1-8178292-82 :
: Schönbrunnerstr 244, 1120 Vienna, Austria    http://www.linbit.com :

[-- Attachment #2: conn-states-8.dot --]
[-- Type: text/plain, Size: 833 bytes --]

digraph conn_states {
	StandAllone  -> WFConnection   [ label = "ioctl_set_net()" ]
	WFConnection -> Unconnected    [ label = "unable to bind()" ]
	WFConnection -> WFReportParams [ label = "in connect() after accept" ]
	WFReportParams -> StandAllone  [ label = "checks in receive_param()" ]
	WFReportParams -> Connected    [ label = "in receive_param()" ]
	WFReportParams -> WFBitMapS    [ label = "sync_handshake()" ]
	WFReportParams -> WFBitMapT    [ label = "sync_handshake()" ]
	WFBitMapS -> SyncSource        [ label = "receive_bitmap()" ]
	WFBitMapT -> SyncTarget        [ label = "receive_bitmap()" ]
	SyncSource -> Connected
	SyncTarget -> Connected
	SyncSource -> PausedSyncS
	SyncTarget -> PausedSyncT
	PausedSyncS -> SyncSource
	PausedSyncT -> SyncTarget
	Connected   -> WFConnection    [ label = "* on network error" ]
}

[-- Attachment #3: disk-states-8.dot --]
[-- Type: text/plain, Size: 913 bytes --]

digraph disk_states {
	Diskless -> Inconsistent       [ label = "ioctl_set_disk()" ]
	Diskless -> Consistent         [ label = "ioctl_set_disk()" ]
	Diskless -> Outdated           [ label = "ioctl_set_disk()" ]
	Consistent -> Outdated         [ label = "receive_param()" ]
	Consistent -> UpToDate         [ label = "receive_param()" ]
	Consistent -> Inconsistent     [ label = "start resync" ]
	Outdated   -> Inconsistent     [ label = "start resync" ]
	UpToDate   -> Inconsistent     [ label = "ioctl_replicate" ]
	Inconsistent -> UpToDate       [ label = "resync completed" ]
	Consistent -> Failed           [ label = "io completion error" ]
	Outdated   -> Failed           [ label = "io completion error" ]
	UpToDate   -> Failed           [ label = "io completion error" ]
	Inconsistent -> Failed         [ label = "io completion error" ]
	Failed -> Diskless             [ label = "sending notify to peer" ]
}

[-- Attachment #4: disk-states-8.ps --]
[-- Type: application/postscript, Size: 12540 bytes --]

[-- Attachment #5: node-states-8.dot --]
[-- Type: text/plain, Size: 540 bytes --]

digraph node_states {
	Secondary -> Primary           [ label = "ioctl_set_state()" ]
	Primary   -> Secondary 	       [ label = "ioctl_set_state()" ]
}

digraph peer_states {
	Secondary -> Primary           [ label = "recv state packet" ]
	Primary   -> Secondary 	       [ label = "recv state packet" ]
	Primary   -> Unknown 	       [ label = "connection lost" ]
	Secondary  -> Unknown  	       [ label = "connection lost" ]
	Unknown   -> Primary           [ label = "connected" ]
	Unknown   -> Secondary         [ label = "connected" ]
}


[-- Attachment #6: node-states-8.ps --]
[-- Type: application/postscript, Size: 9774 bytes --]

[-- Attachment #7: cstates-7.dot --]
[-- Type: text/plain, Size: 1318 bytes --]

digraph cstate {
	Unconfigured -> StandAllone    [ label = "ioctl_set_disk()" ]
	StandAllone  -> Unconnected    [ label = "ioctl_set_net()" ]
	Unconfigured -> Unconnected    [ label = "ioctl_set_net()" ]
	Unconnected  -> WFConnection   [ label = "connect()[1]" ]
	WFConnection -> Unconnected    [ label = "unable to bind()" ]
	WFConnection -> WFReportParams [ label = "in connect() after accept" ]
	WFReportParams -> StandAllone  [ label = "checks in receive_param()" ]
	WFReportParams -> Connected    [ label = "in receive_param()" ]
	WFReportParams -> WFBitMapS    [ label = "sync_handshake()" ]
	WFReportParams -> WFBitMapT    [ label = "sync_handshake()" ]
	WFBitMapS -> SyncSource        [ label = "receive_bitmap()" ]
	WFBitMapT -> SyncTarget        [ label = "receive_bitmap()" ]
	SyncSource -> Connected
	SyncTarget -> Connected
	SyncSource -> PausedSyncS
	SyncTarget -> PausedSyncT
	PausedSyncS -> SyncSource
	PausedSyncT -> SyncTarget
	Connected   -> BrokenPipe       [ label = "* recv error" ]
	BrokenPipe  -> WFConnection     [ label = "connect()[1]" ]
	Connected   -> NetworkFailure   [ label = "* set by asender()" ]
	NetworkFailure -> WFConnection  [ label = "connect()[1]" ]
	Connected   -> Timeout          [ label = "* set drbd_send()" ]
	Timeout     -> WFConnection     [ label = "connect()[1]" ]
}

[-- Attachment #8: conn-states-8.ps --]
[-- Type: application/postscript, Size: 13380 bytes --]

[-- Attachment #9: cstates-7.ps --]
[-- Type: application/postscript, Size: 17743 bytes --]

      reply	other threads:[~2004-10-06 11:54 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-09-24 14:29 [Drbd-dev] [RFC] (CRM and) DRBD (0.8) states and transistions, recovery strategies Lars Ellenberg
2004-09-24 21:11 ` [Drbd-dev] Re: [Linux-ha-dev] " Lars Marowsky-Bree
2004-09-24 23:04   ` Lars Ellenberg
2004-09-25  8:54     ` Lars Marowsky-Bree
2004-09-25  9:50       ` Lars Ellenberg
2004-09-25  9:59         ` Lars Marowsky-Bree
2004-09-26 18:40   ` Andrew Beekhof
2004-09-27 12:19     ` Lars Ellenberg
2004-09-27 12:38       ` Andrew Beekhof
2004-09-27 14:52 ` [Drbd-dev] " Philipp Reisner
2004-09-29 12:58   ` Philipp Reisner
2004-09-29 17:07     ` Lars Ellenberg
2004-10-06 11:55       ` Philipp Reisner [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200410061355.40551.philipp.reisner@linbit.com \
    --to=philipp.reisner@linbit.com \
    --cc=drbd-dev@lists.linbit.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox