Distributed Replicated Block Device (DRBD) development
 help / color / mirror / Atom feed
From: Lars Ellenberg <lars.ellenberg@linbit.com>
To: drbd-dev@lists.linbit.com
Subject: Re: [Drbd-dev] Primary/Diskless node cannot reconnect
Date: Tue, 3 Nov 2009 12:13:55 +0100	[thread overview]
Message-ID: <20091103111355.GA12242@barkeeper1-xen.linbit> (raw)
In-Reply-To: <BC2F8964429F14468EA0E6D6CF00E8C9390DA7@EXHQ.corp.stratus.com>

On Mon, Nov 02, 2009 at 10:47:54PM -0500, Graham, Simon wrote:
> > 8.2 is dead.
> 
> Hmmm... it hasn't stopped moving yet... are you saying you won't make
> any more fixes to it? 

Yes.

If we change something on the 8.0 branch, we sometimes still
merge it through the 8.2 branch first, as that helps in merging
it into the 8.3 one, because of all the whitespace changes and
constant renames ...

But if we fix something on 8.3, which would be relevant for 8.2,
we don't much care to merge it back.

"8.2.8" was officially 8.3.0, and no more 8.2 will happen.

> > has been fixed differently in 8.3 already,
> > where the corresponding code looks like
> > 
> >  if (mdev->state.conn < C_CONNECTED &&
> >             mdev->state.disk < D_INCONSISTENT &&
> >             mdev->state.role == R_PRIMARY &&
> >             (mdev->ed_uuid & ~((u64)1)) != (p_uuid[UI_CURRENT] &
> > ~((u64)1))) {
> > 
> 
> I must admit I haven't looked at 8.3 in any detail yet but that code you
> quote looks suspiciously like the 8.2 code to me -- D_DISKLESS is still
> a value less than D_INCONSISTENT...
> 
> Shouldn't this be:
> 
>   if (mdev->state.conn < C_CONNECTED &&
>              mdev->state.disk > D_DISKLESS &&
>              mdev->state.disk < D_INCONSISTENT &&
>              mdev->state.role == R_PRIMARY &&
>              (mdev->ed_uuid & ~((u64)1)) != (p_uuid[UI_CURRENT] &
> ~((u64)1))) {
> 
> To fix this same issue???

No.
The correct fix for your problem probably is not only this,
but some addition to the "exposed data uuid" stuff as well.

Because it is Primary, there may be cached pages,
file system and applications usually have a rough idea
what data they expect to live where.

What this is supposed to do is avoid a timewarp into stale data,
if you lose network first, hum along for hours,
and then lose the disk as well.

Or vice versa.

You are then only allowed to attach or connect to the
data you had last access to, not to the other set,
as the other set would mean a time warp into stale data.

-- 
: Lars Ellenberg
: LINBIT | Your Way to High Availability
: DRBD/HA support and consulting http://www.linbit.com

DRBD® and LINBIT® are registered trademarks of LINBIT, Austria.

  reply	other threads:[~2009-11-03 11:13 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-01 22:25 [Drbd-dev] Primary/Diskless node cannot reconnect Graham, Simon
2009-11-02 22:42 ` Lars Ellenberg
2009-11-03  3:47 ` Graham, Simon
2009-11-03 11:13   ` Lars Ellenberg [this message]
     [not found] ` <BC2F8964429F14468EA0E6D6CF00E8C9390DA7@EXHQ.corp.strat us.com>
2009-11-03 12:40   ` Graham, Simon
2009-11-03 14:09     ` 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=20091103111355.GA12242@barkeeper1-xen.linbit \
    --to=lars.ellenberg@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