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 15:20:10 -0800	[thread overview]
Message-ID: <20091125232010.GA5968@us.ibm.com> (raw)
In-Reply-To: <4B0DB408.6020906@redhat.com>

Takahiro Yasui [tyasui@redhat.com] wrote:
> I think again the scenario which Mikulas pointed. It looks double failures
> (fails happened on two legs), and human intervention would be acceptable.
> However, how do we know if the second leg contains valid data?
> 
> There might be two cases.
> 
>   1) System crashed during write operations without any disk failures, and
>      the first leg fails at the next boot.
> 
>      We can use the secondary leg because data in the secondary leg is valid.
> 
>   2) System crashed after the secondary leg failed, and the first leg fails
>      and the secondary leg gets back online at the next boot.
> 
>      We can't use the secondary leg because data might be stale.
> 
> 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! I am not sure if the state is written to
log disk though. It may be possible to distinguish the above two cases
with this...

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!

> Another possibility I thought was error messages.
> If any error messages for the secondary leg are recorded, we can judge that
> the secondary leg contains stale data, but I suspect that it is not a secure
> way because syslog might not be written in disk before system crash.

We should be able to fix it in the LVM meta data!

  reply	other threads:[~2009-11-25 23:20 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 [this message]
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=20091125232010.GA5968@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.