All of lore.kernel.org
 help / color / mirror / Atom feed
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 :

             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.