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 12:44:58 -0800 [thread overview]
Message-ID: <20091125204458.GC1673@us.ibm.com> (raw)
In-Reply-To: <4B0D509E.9090001@redhat.com>
Takahiro Yasui [tyasui@redhat.com] wrote:
> > The requirements are:
> > * if one of legs fail or log fails, you must automatically continue
> > without human intervention
> > * if both legs fail, you must shut it down and not pretend that something
> > was written when it wasn't (this would break durability requirement of
> > transactions).
>
> I agree with this point. lvm mirror could be used on filesystems such as
> ext3 and each filesystem and application needs to take care those situation
> to prevent data corruption. I don't think that it is realistic, and the
> underlying layer should prevent data corruption. I now understand primary
> and secondary disks need to be blocked.
If you think that I/O needs to be blocked for first or second leg
failures, then I am afraid that there is no way to keep the failed
mirror in the system for re-integrating failed devices.
I would like to keep the mirror as mirror when one of the legs fails as
opposed to making it linear now by dmeventd. This is to re-integrate a
failed leg into the mirror to handle transient device failures. Here is
what I am planning to do, let me know if you find any issues:
1. Secondary leg failure. dmeventd will NOT change the meta data at all.
It will call "lvchange --refresh" that will start resynchronization.
This will be done a few times. If the device still fails to
re-integrate, it is left the way it is and no further re-integrations
attempts are done. The number of attempts can be done at configurable
intervals.
2. First leg failure (aka Primary leg failure): The kernel would stop
handling any further I/O. The dmeventd will change mirror meta data
[it will re-order the legs ] so that the secondary now becomes the
primary. I will try to re-integrate the failed device few times before
giving up just as in the case "1" above.
The kernel module will never progress with a first leg failure as you
see above.
Thanks, Malahal.
next prev parent reply other threads:[~2009-11-25 20:44 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 [this message]
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
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=20091125204458.GC1673@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.