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, 29 Sep 2004 14:58:47 +0200 [thread overview]
Message-ID: <200409291458.47753.philipp.reisner@linbit.com> (raw)
In-Reply-To: <200409271652.10284.philipp.reisner@linbit.com>
[-- Attachment #1: Type: text/plain, Size: 806 bytes --]
> [...]
> > 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).
-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: new_st.c --]
[-- Type: text/x-csrc, Size: 2996 bytes --]
typedef struct {
unsigned role : 2 ; // 3 primary/secondary/unknown
unsigned peer : 2 ; // 3 primary/secondary/unknown
unsigned conn : 5 ; // 17 cstates
unsigned disk : 3 ; // 5 from Diskless to UpToDate
unsigned multi_p : 1 ; // 2 multiple primaries alloes.
} drbd_state_t;
typedef enum {
Unconfigured,
StandAlone,
Unconnected,
Timeout,
BrokenPipe,
NetworkFailure,
WFConnection,
WFReportParams, // we have a socket
Connected, // we have introduced each other
SkippedSyncS, // we should have synced, but user said no
SkippedSyncT,
WFBitMapS,
WFBitMapT,
SyncSource, // The distance between original state and pause
SyncTarget, // state must be the same for source and target. (+2)
PausedSyncS, // see _drbd_rs_resume() and _drbd_rs_pause()
PausedSyncT, // is sync target, but higher priority groups first
} drbd_conns_t;
typedef enum {
Diskless,
Failed, // Moves on to Diskless as soon as we reported it ot the peer
Inconsistent,
Outdated,
Consistent, // Might be outdated, might be UpTpDate ...
UpToDate,
} drbd_disks_t;
typedef enum {
Unknown=0,
Primary=1, // role
Secondary=2, // role
} drbd_role_t;
drbd_state_t st; // here for mdev->state;
void lock(){}
void unlock(){}
static int state_change(drbd_state_t ns, int hard)
{
int rv;
lock();
if( ns.role == st.role &&
ns.peer == st.peer &&
ns.conn == st.conn &&
ns.disk == st.disk &&
ns.multi_p == st.multi_p ) {
rv = 1;
goto out;
}
if(!hard) {
// pre-state-change checks
if(!ns.multi_p &&
ns.role == Primary &&
ns.peer == Primary) {
rv = 0;
goto out;
}
// ...
}
// State sanitising
if ( ns.conn < Connected ) ns.peer = Unknown;
st = ns;
// post-state-change actions...
if( ns.conn < Connected &&
ns.disk <= Inconsistent &&
ns.role == Primary ) {
panic(); // Just for illustration
}
// ...
// Probabely it also makes sense to run a dynamic list of
// post-state-change-callbacks sitting on a post-state-change-hook.
//
// Could use this to implement the sync groupes more sanely.
// Could also replace the cstate_wait
rv = 1;
out:
unlock();
return rv;
}
int set_cstate(drbd_conns_t new, int hard)
{
drbd_state_t ns = st;
ns.conn = new;
return state_change(ns,hard);
}
int set_dstate(drbd_disks_t new, int hard)
{
drbd_state_t ns = st;
ns.disk = new;
return state_change(ns,hard);
}
int set_rstate(drbd_role_t new, int hard)
{
drbd_state_t ns = st;
ns.role = new;
return state_change(ns,hard);
}
int set_pstate(drbd_role_t new, int hard)
{
drbd_state_t ns = st;
ns.peer = new;
return state_change(ns,hard);
}
panic()
{
printf("PANIC\n");
}
main()
{
st = (drbd_state_t){ Secondary,Unknown,Unconfigured,UpToDate,1 };
set_cstate(Connected,0);
set_pstate(Primary,0);
set_rstate(Primary,0); // This one fails...
set_cstate(WFConnection,0);
set_rstate(Primary,0);
set_dstate(Diskless,1); // causes panic...
}
next prev parent reply other threads:[~2004-09-29 12:58 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 [this message]
2004-09-29 17:07 ` Lars Ellenberg
2004-10-06 11:55 ` Philipp Reisner
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=200409291458.47753.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