From: Philipp Reisner <philipp.reisner@linbit.com>
To: drbd-dev@lists.linbit.com
Subject: [Drbd-dev] GFS support in DRBD-0.8
Date: Tue, 21 Sep 2004 16:16:59 +0200 [thread overview]
Message-ID: <200409211616.59305.philipp.reisner@linbit.com> (raw)
Hi Lars,
I have thought about it and wrote this item for the roadmpa.txt
document :
--snip--
8 Support shared disk semantics ( for GFS, OCFS etc... )
All the thoughts in this area, imply that the cluster deals
with split brain situations as discussed in item 6.
In order to offer a shared disk mode for GFS, we introduce a
new state "shared" (in addition to primary and secondary).
In a cluster of two nodes in shared state we determine a
coordinator node (e.g. by selecting the node with the
numeric higher IP address)
read after write dependencies
The shared state is available to clusters using protocol C
and B. It is not usable with protocol A.
To support the shared state with protocol B, upon a read
request the node has to check if a new version of the block
is in the progress of getting written. (== search for it on
active_ee and done_ee, must make sure that it is on active_ee
before the RecvAck is sent. [is already the case.] )
global write order
As far as I understand the toppic up to now we have two options
to establish a global write order.
Proposed Solution 1, using the order of a coordinator node:
Writes from the coordinator node are carried out, as they are
carried out on the primary node in conventional DRBD. ( Write
to disk and send to peer simultaniously. )
Writes from the other node are sent to the coordinator first,
then the coordinator inserts a small "write now" packet into
its stram of write packets.
The node commits the write to its local IO subsystem as soon
as it gets the "write-now" packet from the coordinator.
Note: With protocol C it does not matter which node is the
coordinator from the performance viewpoint.
Proposed Solution 2, use ALs as distributed locks:
Only one node might mark an extent as active at a time. New
packets are introduced to request the locking of an extent.
--snap--
PS: I think that we do not need to use the AL extents as
distributed locks.
PS2: Comments about the wording ("coordinator") are also welcome.
-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 :
next reply other threads:[~2004-09-21 14:16 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-21 14:16 Philipp Reisner [this message]
[not found] ` <3+B6NrvPixc+6shooEioqTc=lge@web.de>
2004-09-22 13:18 ` [Drbd-dev] GFS support in DRBD-0.8 Philipp Reisner
2004-09-22 14:53 ` Lars Ellenberg
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=200409211616.59305.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.