All of lore.kernel.org
 help / color / mirror / Atom feed
From: malahal@us.ibm.com
To: dm-devel@redhat.com
Subject: Re: Re: [RFC] [PATCH] lvm2: mirroredlog support
Date: Tue, 20 Jan 2009 09:38:17 -0800	[thread overview]
Message-ID: <20090120173817.GA9601@us.ibm.com> (raw)
In-Reply-To: <497579AB.4060503@linux.vnet.ibm.com>

Stefan Raspl [raspl@linux.vnet.ibm.com] wrote:
> If I understand Takahiro correctly, the main issue is that the whole
> log device becomes unusable in case one leg is broken...? Of course,
> we still have the other leg with the most recent data available and
> can read from that one. However, this would require that we can
> start a mirror in rw-mode (so we can keep the still-recent half up
> to date) even if one half has failed - a functionality which was
> recently added to LVM, as we discussed in our last call...?

Stefan, Takahiro is using the latest LVM that brings LVs in rw-mode.
That is not the problem. Actually, everything works if a slave leg of a
"log mirror" is broken. But if the master leg of the "log mirror" is
broken, entire log device becomes unusable. The reason is when we
activate the "log mirror", it always synchronizes the data from the
master leg to slave leg since it has no log device (as the "log mirror"
uses "corelog"). In other words, the "log mirror" always starts in "not
in sync" state and synchronizes.

If the master leg is broken for the "log mirror", it starts in "not in
sync" state and tries to copy data from the "broken leg" to the active
leg! This appears as the master leg failure while doing synchronization
which makes the whole device unusable.

> I'm not sure if I understand his statements about the
> synchronization correctly. Why would any synchronization within the
> data mirror occur at all? It's only the log which is broken, not the
> actual data in vg00-lv00_mimage_0/1. If any synchronization in the
> _data_ mirror occurs just because one leg in the _log_ mirror has a
> problem, I'd consider that a bug.

Since the entire log device is unusable with its "master device
broken", the "data mirror" goes for synchronization.

  reply	other threads:[~2009-01-20 17:38 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-12-30  0:10 [RFC] [PATCH] lvm2: mirroredlog support malahal
2008-12-30  0:10 ` malahal
2009-01-19 22:56 ` Takahiro Yasui
2009-01-20  1:54   ` malahal
2009-01-20  7:13     ` Stefan Raspl
2009-01-20 17:38       ` malahal [this message]
2009-01-20 19:52         ` Takahiro Yasui
2009-01-20 22:12     ` Takahiro Yasui
2009-01-20 21:29 ` Takahiro Yasui
2009-01-20 22:14   ` malahal
2009-01-23 19:14 ` Jonathan Brassow
2009-01-23 21:07   ` malahal

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=20090120173817.GA9601@us.ibm.com \
    --to=malahal@us.ibm.com \
    --cc=dm-devel@redhat.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.