All of lore.kernel.org
 help / color / mirror / Atom feed
From: malahal@us.ibm.com
To: dm-devel@redhat.com
Subject: Re: DM-RAID1 data corruption
Date: Tue, 23 Jun 2009 11:22:29 -0700	[thread overview]
Message-ID: <20090623182229.GD30667@us.ibm.com> (raw)
In-Reply-To: <4A41065D.10804@redhat.com>

Takahiro Yasui [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.
> 
> According to Mikulas's comment, superblocks are located on each legs
> and contains a counter. Do you have an idea to separate a superblock
> device like the log device? Or do you mean to add a parameter to
> enable superblock like "--superblock"? It might be helpful if you
> could describe some command line examples.

I was thinking something like adding {metadata-size #metadata-areas <dev offset>
...

echo 0 1000 mirror core 1 64 2 /dev/sda 0 /dev/sdb 0 512 2 /dev/sda 2000
/dev/sdb 2000

The above one will create a mirror with sda and sdb and mirror metadata
on the same disks at offset 2000 with 512 size. The kernel target can
use that 512 bytes whatever the way it wants.

  reply	other threads:[~2009-06-23 18:22 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 [this message]
2009-06-24  3:03               ` Neil Brown
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=20090623182229.GD30667@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.