From: Philipp Reisner <philipp.reisner@linbit.com>
To: drbd-dev@lists.linbit.com
Subject: Re: [Drbd-dev] roadmap draft
Date: Fri, 10 Sep 2004 11:11:01 +0200 [thread overview]
Message-ID: <200409101111.01642.philipp.reisner@linbit.com> (raw)
In-Reply-To: <20040909100552.GQ20844@marowsky-bree.de>
[-- Attachment #1: Type: text/plain, Size: 1707 bytes --]
[...]
> > 4 Two new config options, to allow more fine grained definition of
> > DRDBs behaviour after a split-brain situation:
> >
> > after-sb-2pri =
> > disconnect No automatic resynchronisation gets performed. One
> > node should drop its net-conf (preferable the
> > node that would become sync-target)
> > DEFAULT.
> > asf-older Auto sync from is the oder primary (curr.behaviour
> > i.t.s.) asf-younger Auto sync from is the younger primary
> > asf-furthest Auto sync from is the node that did more modifications
> > asf-NODENAME Auto sync from is the named node
>
> With the 'preferrably the node which would become sync-target'
> constraint, you would need to allow to specify one of the other methods
> too (how else would you determine which node would become sync-target?).
>
Hmm, I just do not get it...
[...]
> > Notes:
> > 1) The disconnect actions cause the sync-target or the secondary
> > node to go into StandAlone state.
> >
> > 2) If two nodes in primary state try to connect one of them goes
> > into StandAlone state (=curr. behaviour)
>
> 1+2 - I'd rather prefer a symmetric scenario where both nodes go to
> StandAlone.
>
Ok. I have put it in.
[...]
> I'd just keep a map of outstanding ACKs and compare any ACK received
> against that list. Wouldn't that solve this?
>
Ok, thought about it again, had a look at the code, changed my mind.
-> Hash.
-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: roadmap.txt --]
[-- Type: text/plain, Size: 5156 bytes --]
DRBD 0.8 Roadmap
----------------
1 Drop support for linux-2.4.x.
Do all size calculations on the base of sectors (512 Byte) as it
is common in Linux-2.6.x.
(Currently they are done on a 1k base, for 2.4.x compatibility)
2 Drop the Drbd_Parameter_Packet.
Replace the Drbd_Parameter_Packet by a more general and
extensible mechanism.
3 Changes of state and cstate synchronized by mutex and only done by
the worker thread.
4 Two new config options, to allow more fine grained definition of
DRDBs behaviour after a split-brain situation:
after-sb-2pri =
disconnect No automatic resynchronisation gets performed. One
node should drop its net-conf (preferable the
node that would become sync-target)
DEFAULT.
asf-older Auto sync from is the oder primary (curr.behaviour i.t.s.)
asf-younger Auto sync from is the younger primary
asf-furthest Auto sync from is the node that did more modifications
asf-NODENAME Auto sync from is the named node
pri-sees-sec-with-higher-gc =
disconnect (current behaviour)
asf-primary Auto sync from is the current primary
panic The current primary panics. The node with the
higher gc should take over.
Notes:
1) The disconnect actions cause the sync-target or the secondary
(better both) node to go into StandAlone state.
2) If two nodes in primary state try to connect one (better both)
of them goes into StandAlone state (=curr. behaviour)
3) As soon as the decision is takes the sync-target adopts the
GC of the sync source.
[ The whole algorithm would also work if both would reset their
GCs to <0,0,0...> after the decision, but since we also
use the GC to tag the bitmap it is better the current way ]
5 It is possible that a secondary node crashes a primary by
returning invalid block_ids in ACK packets. [This might be
either caused by faulty hardware, or by a hostile modification
of DRBD on the secondary node]
Proposed solution:
Have a hash table (hlist_head style), add the collision
member (hlist_node) to drbd_request.
Use the pointer to the drbd_request as key to the hash, each
drbd_request is also put into this hash table. We still use the
pointer as block_id.
When we get an ACK packet, we lookup the hash table with the
block_id, and may find the drbd_request there. Otherwise it
was a forged ACK.
6 Support IO fencing; introduce the "Dead" peer state (o_state)
New commands:
drbdadm peer-dead r0
drbdadm [ considered-dead | die | fence | outdate ] r0
( What do you like best ? Suggestions ? )
remove option value: on-disconnect=freeze_io
introduce:
peer-state-unknown=freeze_io
peer-state-unknown=continue_io
New meta-data flag: "Outdated"
Let us assume that we have two boxes (N1 and N2) and that these
two boxes are connected by two networks (net and cnet [ clinets'-net ]).
Net is used by DRBD, while heartbeat uses both, net and cnet
I know that you are talking about fencing by STONITH, but DRBD is
not limited to that. Here comes my understanding of how fencing
(other than STONITH) should work with DRBD-0.8 :
N1 net N2
P/S --- S/P everything up and running.
P/? - - S/? network breaks ; N1 freezes IO
P/? - - S/? N1 fences N2:
In the STONITH case: turn off N2.
In the "smart" case:
N1 asks N2 to fence itself from the storage via cnet.
HB calls "drbdadm fence r0" on N2.
N2 replies to N1 that fencing is done via cnet.
N1 calls "drbdadm peer-dead r0".
P/D - - S/? N1 thaws IO
N2 got the the "Outdated" flag set in its meta-data, by the "fence"
command. I am not sure if it should be called "fence", other ideas:
"considered-dead","die","fence","outdate". What do you think ?
7 New command drbdmeta
We move the read_gc.pl/write_gc.pl to the user directory.
Make them to one C program: drbdmeta
-> in the future the module never creates the meta data
block. One can use drbdmeta to create, read and
modify the drbdmeta block. drbdmeta refuses to write
to it as long as the module is loaded (configured).
drbdsetup gets the ability to read the gc values while DRBD
is set up via an ioctl() call. -- drbdmeta refuses to run
if DRBD is configured.
drbdadm is the nice frontend. It alsways uses the right
backend (drbdmeta or drbdsetup)...
drbdadm md-set-gc 1:2:3:4:5:6 r0
drbdadm md-get-gc r0
drbdadm md-get/set-{la-size|consistent|etc...} resources....
drbdadm md-create r0
plus-banches:
----------------------
* Implement the checksum based resync.
* 3 node support. Do and test a 3 node setup (2nd DRBD stacked over
a DRBD pair). Enhance the user level tools to support the 3 node
setup.
* Change the bitmap code to work with unmapped highmem pages, instead
of using vmalloc()ed memory. This allows users of 32bit platforms
to use drbd on big devices (in the ~3TB range)
prev parent reply other threads:[~2004-09-10 9:11 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-07 13:49 [Drbd-dev] roadmap draft Philipp Reisner
2004-09-09 10:05 ` Lars Marowsky-Bree
2004-09-10 9:11 ` 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=200409101111.01642.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.