linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tapani Tarvainen <raid@tapanitarvainen.fi>
To: linux-raid@vger.kernel.org
Subject: Re: RAID without superblock
Date: Mon, 20 Apr 2009 08:13:50 +0300	[thread overview]
Message-ID: <20090420051350.GA13091@hamsu.tarvainen.info> (raw)
In-Reply-To: <20090419210200.GA6942@lazy.lzy>

On Sun, Apr 19, 2009 at 11:04:07PM +0200, Piergiorgio Sartor (piergiorgio.sartor@nexgo.de) wrote:

> > Why would you want a RAID-1 without superblock.

> Ah! I was thinking about it as a method to
> build a RAID with an already existing disk
> or partition, which cannot be modified.

Well, that it isn't. Although of course if you have
multiple partitions on the disk, you can build
RAID on them separately, possibly leaving some
out and it might be useful in some situaitions,
but that's apparently not what you had in mind.

> So, let's say I've already a disk with some
> data and I want/need to protect it with a
> RAID configuration, but I cannot re-create
> the RAID from scratch, because this will
> damage the content of the disk.

Well, you could create the RAID as degenerate on the
new disk(s) only, copy the data over and then add the
old disk to complete array.

> For example, I found consistent to create the
> array with the correct disk and "missing",
> then add the mirror.

I'm not sure what you mean, unless it's just what
I suggested above.

> Of course, if there is a known order for the
> resync, then it would be enough to build
> the array with this in mind.
> The issue could also be that the "primary"
> disk could be updated alone, sometimes.

What would "updating" the disk mean here?
If you want to have two disks of different
sizes so that the "extra" space in the bigger
one is usable, just not RAIDed, it's easy:
just build the RAID out of the entire smaller
disk and a similarly-sized partition in the
bigger one, and use the remainder of the latter
as a regular partition.
And upgrading the disks one at a time in such
a setup is perfectly possible, without any
backup/restore cycles, too.
(Although backups are still recommended, of course.)

-- 
Tapani Tarvainen

      parent reply	other threads:[~2009-04-20  5:13 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-19 11:47 RAID without superblock Piergiorgio Sartor
2009-04-19 20:44 ` NeilBrown
2009-04-19 21:04   ` Piergiorgio Sartor
2009-04-19 21:57     ` Andrew Burgess
2009-04-20 18:10       ` Piergiorgio Sartor
2009-04-20 18:17         ` Christopher Chen
2009-04-19 23:33     ` John Robinson
2009-04-20  5:13     ` Tapani Tarvainen [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=20090420051350.GA13091@hamsu.tarvainen.info \
    --to=raid@tapanitarvainen.fi \
    --cc=linux-raid@vger.kernel.org \
    /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;
as well as URLs for NNTP newsgroup(s).