Linux Device Mapper development
 help / color / mirror / Atom feed
From: Neil Brown <neilb@suse.de>
To: device-mapper development <dm-devel@redhat.com>
Cc: mpatocka@redhat.com
Subject: Re: DM-RAID1 data corruption
Date: Wed, 24 Jun 2009 13:03:26 +1000	[thread overview]
Message-ID: <19009.38782.225681.85214@notabene.brown> (raw)
In-Reply-To: message from Takahiro Yasui on Tuesday June 23

On Tuesday June 23, tyasui@redhat.com wrote:
> >> MD-RAID1 solves this problem by having counters in superblocks on both 
> >> legs. If some leg dies, the counter on the other devices is increased. If 
> >> the dead disk comes online again, it is found that it has old counter and 
> >> cannot be trusted.
> >>
> >> Would it be possible to extend a logical volume when converting it to a 
> >> raid1 and use the last area of the volume as a superblock?
> >>
> >> Mikulas
> > 
> > This is an old thread, I am just trying to revitalize it! :-) How about
> > dm-raid1 taking superblock storage as arguments in the command line,
> > just like the log device? The superblock storage is entirely managed by
> > the kernel, LVM just allocates it. Error handling can be instant this
> > way. LVM can auto convert the exiting mirrors to this kind of mirrors if
> > space is available.
> 
> Interesting idea. The superblock storage managed by kernel is really
> important to handle an error quickly inside the kernel.

I don't think that it is important to handle errors quickly - they
really shouldn't happen often enough that speed is an issue.  All you
need to do is handle errors correctly.

I would suggest that you simply get raid1 to block any write requests
until all drive failures have been acknowledged by userspace.
So you would need to differentiate between an acknowledged drive
failure and an unacknowledged failure.  Writes block when ever there
are unacknowledged failures.
Then you need a message that can be sent to the raid1 to acknowledge
the failure of a particular device.
'suspend' would need to fail if there are any unacknowledged failures
as otherwise it would block.

NeilBrown

  parent reply	other threads:[~2009-06-24  3:03 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-14 20:46 DM-RAID1 data corruption Mikulas Patocka
2009-04-14 21:07 ` Takahiro Yasui
2009-04-15  3:12 ` malahal
2009-04-15 20:38   ` Takahiro Yasui
2009-04-16  2:49     ` malahal
2009-04-16 22:24       ` Takahiro Yasui
2009-04-20  9:56         ` Mikulas Patocka
2009-04-20 17:08           ` Takahiro Yasui
2009-05-27  1:33           ` malahal
2009-06-23  1:09           ` malahal
2009-06-23 16:44             ` Takahiro Yasui
2009-06-23 18:22               ` malahal
2009-06-24  3:03               ` Neil Brown [this message]
2009-06-24 16:09                 ` Takahiro Yasui
2009-06-25 14:47                   ` Mikulas Patocka
2009-06-25 16:16                     ` 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=19009.38782.225681.85214@notabene.brown \
    --to=neilb@suse.de \
    --cc=dm-devel@redhat.com \
    --cc=mpatocka@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox