Linux RAID subsystem development
 help / color / mirror / Atom feed
From: Goswin von Brederlow <goswin-v-b@web.de>
To: Gabor Gombas <gombasg@sztaki.hu>
Cc: Asdo <asdo@shiftmail.org>,
	Goswin von Brederlow <goswin-v-b@web.de>,
	linux-raid <linux-raid@vger.kernel.org>,
	Neil Brown <neilb@suse.de>
Subject: Re: Swapping a disk without degrading an array
Date: Sun, 31 Jan 2010 18:32:22 +0100	[thread overview]
Message-ID: <87ockai3ix.fsf@frosties.localdomain> (raw)
In-Reply-To: <20100131163355.GA25622@twister.home> (Gabor Gombas's message of "Sun, 31 Jan 2010 17:33:55 +0100")

Gabor Gombas <gombasg@sztaki.hu> writes:

> On Sun, Jan 31, 2010 at 04:34:03PM +0100, Asdo wrote:
>
>> 1/ The live-spare gets filled of data without recording anything on
>> any superblocks. If there is a power failure and reboot, the new MD
>> will know nothing about this. The process has to be restarted.
>
> IMHO MD must know about the copy and it must know not to use the new
> device before the copying is completed. Otherwise after a reboot mdadm
> may either import the new half-written spare instead of the real one if
> the superblock is already copied, or other tools like LVM may start
> using the new half-written spare instead of the RAID if the MD
> superblock is still missing.
>
> Gabor

No that is exactly what he means to avoid.

His suggestion is that at the start the metadata area of the life-spare
is kept as is, being a simple unused spare. Only the in-memory data
records that it actualy is a live-spare and only the data part of the
device is mirrored.

Then at the end you remove the old disk, add the live-spare and record
the change in the metadata of all drives in an semi atomic way. If
anything interrupts the operation before this the live-spare will still
be recorgnised as normal spare when the raid is reassembled.

MfG
        Goswin

      reply	other threads:[~2010-01-31 17:32 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-25 12:11 Swapping a disk without degrading an array Michał Sawicz
2010-01-25 12:25 ` Majed B.
2010-01-25 12:53   ` Mikael Abrahamsson
2010-01-25 14:44 ` Michał Sawicz
2010-01-25 14:51 ` Asdo
2010-01-25 17:40 ` Goswin von Brederlow
2010-01-29 11:19 ` Neil Brown
2010-01-29 15:35   ` Goswin von Brederlow
2010-01-31 15:34     ` Asdo
2010-01-31 16:33       ` Gabor Gombas
2010-01-31 17:32         ` Goswin von Brederlow [this message]

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=87ockai3ix.fsf@frosties.localdomain \
    --to=goswin-v-b@web.de \
    --cc=asdo@shiftmail.org \
    --cc=gombasg@sztaki.hu \
    --cc=linux-raid@vger.kernel.org \
    --cc=neilb@suse.de \
    /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