All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lars Marowsky-Bree <lmb@suse.de>
To: Philipp Reisner <philipp.reisner@linbit.com>, drbd-dev@lists.linbit.com
Subject: Re: [Drbd-dev] Summary (3rd try)
Date: Thu, 26 Aug 2004 10:27:50 +0200	[thread overview]
Message-ID: <20040826082750.GA3125@marowsky-bree.de> (raw)
In-Reply-To: <200408251713.45325.philipp.reisner@linbit.com>

On 2004-08-25T17:13:45,
   Philipp Reisner <philipp.reisner@linbit.com> said:

> Hi,
> 
> I tried to incooperate the comments of LMB and LGE. Please review:
> 
> after-pri-pri-now-sec-sec = 

I wish I had a better name here ;-)

>  disconnect     No automatic resynchronisation gets performed. One
>                 node should drop its net-conf (preferable the
>                 node that would become sync-target)
>                 DEFAULT.

Hmmm. Should they drop the netconf, or should instead the first node to
be elected primary become the SyncSource implicitly?

>  ass-older      Auto sync source is the oder primary (curr.behaviour i.t.s.)
>  ass-younger    Auto sync source is the younger primary

I'm a bit concerned about the older vs younger distinction. "before" and
"after" may be slightly better at conveying what you mean.

>  ass-furthest   Auto sync source is the node that did more modifications
>  ass-NODENAME   Auto sync source is the named node 

> pri-sees-sec-with-higher-gc =
>  disconnect	(current behaviour)
>  ass-primary	Auto sync source is the current primary
>  panic		The current primary panics. The node with the
> 		higher gc should take over.

Seems ok.

> Notes:
> 1) The disconnect actions cause the sync-target or the secondary
>    node to go into StandAllone state.
> 2) If two nodes in primary state try to connect one of them goes
>    into StandAllone state (=curr. behaviour)

This is not quite symmetric, which means special cases ;-) Shouldn't
they either refuse to connect, or both drop to StandAlone?

> 3) As soon as the decission is takes the sync-target addopts the
>    GC of the sync source. 
>    [ The whole algorith would also work if both would reset their 
>      GCs to <0,0,0...> after the decission, but since we also
>      use the GC to tag the bitmap it is better the current way ]

Ok.

> Is this better than try2 ?
> Should we improve the naming ? "ass" might not be the best choice.

auto-sync-from-

> Do you think that the naming is constent ?
> Is it still ambiguous ?

I hope it's not, but the other Lars is better at spotting
inconsistencies than I am ;-)


Sincerely,
    Lars Marowsky-Brée <lmb@suse.de>

-- 
High Availability & Clustering	   \\\  /// 
SUSE Labs, Research and Development \honk/ 
SUSE LINUX AG - A Novell company     \\// 


      reply	other threads:[~2004-08-26  8:27 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-08-25 15:13 [Drbd-dev] Summary (3rd try) Philipp Reisner
2004-08-26  8:27 ` Lars Marowsky-Bree [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=20040826082750.GA3125@marowsky-bree.de \
    --to=lmb@suse.de \
    --cc=drbd-dev@lists.linbit.com \
    --cc=philipp.reisner@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.