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 --]
prev parent 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