All of lore.kernel.org
 help / color / mirror / Atom feed
From: malahal@us.ibm.com
To: dm-devel@redhat.com
Subject: Re: [PATCH 7/7] Hold all write bios when errors are handled
Date: Wed, 25 Nov 2009 16:30:43 -0800	[thread overview]
Message-ID: <20091126003043.GA6840@us.ibm.com> (raw)
In-Reply-To: <4B0DC2C0.9020008@redhat.com>

Takahiro Yasui [tyasui@redhat.com] wrote:
> >> I haven't checked the contents of log disk, but I guess we can't
> >> differentiate these cases from log disks.
> > 
> > There were plans to add a new region state to make sure that all the
> > mirror legs have same data after a "crash". Currently your best bet is a
> > complete resync after a crash!
> 
> Please let me clarify this. There are two legs and system crash happens.
> Then, how can we resync? We have only one leg (secondary) after boot.
> When we use "mirror", we expect the last device to contain valid data,
> don't we?

I was actually referring to a problem that I mentioned in a DM/LVM
meeting.  Mikulas posted it here and there were some discussions.
http://thread.gmane.org/gmane.linux.kernel.device-mapper.devel/5392

If I remember, the proposed solution would add another state bit. If it
is implemented, then we can use that information to differentiate the
cases you mentioned. Essentially, if there are only 'dirty' regions, we
can safely use the secondary. On the other hand, if th log has some 'out
of sync' regions, then we can't use the secondary.

You can ignore my reference to "complete resynchronization". I was
referring to an existing problem with system crashes!
 
> > Or just have LVM meta data that records a device failure. Suspend writes
> > [for any kind of leg] and record device failure in the LVM meta data and
> > restart writes. This requires LVM meta data change though!
> 
> Do you mean that write I/Os need to be blocked when the secondary leg fails
> in order to update LVM meta data by lvm commands called by dmeventd?

Yes, that is correct. We need to stop write I/O for any leg failure if
we chose LVM meta data method.

Thanks, Malahal.

  reply	other threads:[~2009-11-26  0:30 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-18 12:09 [PATCH 0/7] patches: fix dm-raid1 race, bug 502927 Mikulas Patocka
2009-11-18 12:10 ` [PATCH 1/7] Explicitly initialize bio lists Mikulas Patocka
2009-11-18 12:11   ` [PATCH 2/7] A framework for holding bios until suspend Mikulas Patocka
2009-11-18 12:11     ` [PATCH 3/7] Use the hold framework in do_failures Mikulas Patocka
2009-11-18 12:12       ` [PATCH 4/7] Don't optimize for failure case Mikulas Patocka
2009-11-18 12:13         ` [PATCH 5/7] Move a logic to get a valid mirror leg to a function Mikulas Patocka
2009-11-18 12:18           ` [PATCH 6/7] Move bio completion from dm_rh_mark_nosync to its caller Mikulas Patocka
2009-11-18 12:19             ` [PATCH 7/7] Hold all write bios when errors are handled Mikulas Patocka
2009-11-23  5:58               ` malahal
2009-11-23 17:54                 ` Takahiro Yasui
2009-11-24 11:51                 ` Mikulas Patocka
2009-11-24 19:17                   ` malahal
2009-11-25 13:19                     ` Mikulas Patocka
2009-11-25 15:43                       ` Takahiro Yasui
2009-11-25 20:44                         ` malahal
2009-11-25 22:50                           ` Takahiro Yasui
2009-11-26 17:56                           ` Mikulas Patocka
2009-11-26 17:54                         ` [PATCH 8/7] Hold all write bios in nosync region Mikulas Patocka
2009-11-25 20:23                       ` [PATCH 7/7] Hold all write bios when errors are handled malahal
2009-11-25 22:47                         ` Takahiro Yasui
2009-11-25 23:20                           ` malahal
2009-11-25 23:50                             ` Takahiro Yasui
2009-11-26  0:30                               ` malahal [this message]
2009-11-26 17:58                         ` Mikulas Patocka
2009-11-26 22:22                           ` malahal
2009-11-28 18:02     ` [PATCH 2/7] A framework for holding bios until suspend Takahiro Yasui
2009-11-30  2:55       ` malahal
2009-11-30  9:41       ` Alasdair G Kergon
2009-11-30 16:46 ` [PATCH 0/7] patches: fix dm-raid1 race, bug 502927 Takahiro Yasui

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=20091126003043.GA6840@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.