RAID without superblock

RAID without superblock

[Piergiorgio Sartor]

Hi all,

what is the proper way to assemble a two disk,
RAID-1, without superblock.
That is, created with "-B" instead of "-C".

I noticed that re-using "-B", will start an
array sync/repair, but it is not clear to me
which disk is source and which is destination.

Using a bitmap file, seems to be safer option,
but I'm not sure if this is just a workaround
or it is the proper way.

Thanks a lot in advance,

bye,

-- 

piergiorgio

Re: RAID without superblock

[NeilBrown]

On Sun, April 19, 2009 9:47 pm, Piergiorgio Sartor wrote:
> Hi all,
>
> what is the proper way to assemble a two disk,
> RAID-1, without superblock.
> That is, created with "-B" instead of "-C".

Why would you want a RAID-1 without superblock. I generally
consider that a legacy configuration.

>
> I noticed that re-using "-B", will start an
> array sync/repair, but it is not clear to me
> which disk is source and which is destination.

As there is no superblock, md cannot tell if the array is "clean"
or not.  It assumes the worst.
If you know for a fact that the two mirrors are consistent,
then tell mdadm with "--assume-clean".


>
> Using a bitmap file, seems to be safer option,
> but I'm not sure if this is just a workaround
> or it is the proper way.

A bitmap (which has to be in a separate file) can be use
to record the clean/dirty status.  It provides some of the same
functionality as a superblock.  But it is not a complete replacement.

To quote from the man page:

        Because of this, the Build mode should only be used
        together with a complete understanding of what you are doing.

NeilBrown

Re: RAID without superblock

[Piergiorgio Sartor]

Hi,

thanks for the answer.

> Why would you want a RAID-1 without superblock. I generally
> consider that a legacy configuration.

Ah! I was thinking about it as a method to
build a RAID with an already existing disk
or partition, which cannot be modified.
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.
Of course, if there is another solution,
like having the superblock on a separate
file, it would be nice too.
BTW, have you ever consider that?

> As there is no superblock, md cannot tell if the array is "clean"
> or not.  It assumes the worst.
> If you know for a fact that the two mirrors are consistent,
> then tell mdadm with "--assume-clean".

Uhm, no, it is not clean, but one of the two
has the correct data, the other no.
Is the "-B" always copying from the first to
the second or else?
For example, I found consistent to create the
array with the correct disk and "missing",
then add the mirror.
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.

> A bitmap (which has to be in a separate file) can be use

Of course, it is a separate file... :-)

> to record the clean/dirty status.  It provides some of the same
> functionality as a superblock.  But it is not a complete replacement.

OK, this is clear.
 
> To quote from the man page:
> 
>         Because of this, the Build mode should only be used
>         together with a complete understanding of what you are doing.

Exactly, I ran into that sentence, that's why
I'm asking, I try to get the full understanding
in order to see if I can use this "feature"...

In any case, if this is "legacy", maybe better
to forget about it.

Thanks again,

bye,

-- 

piergiorgio

Re: RAID without superblock

[Andrew Burgess]

On Sun, 2009-04-19 at 23:04 +0200, Piergiorgio Sartor wrote:

> Ah! I was thinking about it as a method to
> build a RAID with an already existing disk
> or partition, which cannot be modified.
> 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.

Does the filesystem support shrinking? Maybe you can shrink it a tiny
bit and put the superblock at the end. Some sb formats do this. Ext2/3
can be shrunk, xfs not.

Re: RAID without superblock

[Piergiorgio Sartor]

Hi,

first of all thanks a lot for all the suggestions,
it is really nice to have this support!

While reading the answers, I realized that I did
not make the "requirements" really clear. My bad.

The "primary" disk is an external one, which 90%
of the time is connected to the same Linux PC.
But, it could happen it is removed and connected
somewhere else, where no "md" is available.

My idea was, in order to have some protection, to
use it in RAID-1 "superblockless" configuration
on the "default" PC, and use it as a normal disk
whenever (or wherever) necessary.
Of course, the bitmap resync will not work, when
updating the disk directly, without "md" layer.

On the other hand, if the full-resync is always
done from this disk to the local mirror, there
would be no problem, except time.

The reason to do this kind of backup is that this
disk is encrypted, so a "block device copy" will
keep the data encrypted, while a backup of the
mounted disk will not. Unless done to another
encrypted disk/partition, of course.

Clearly, any suggestion is still really appreciated!

Thanks again,

bye,

-- 

piergiorgio

Re: RAID without superblock

[Christopher Chen]

I don't think it's a problem anymore, but on Centos 5.2, use of
superblocks other than 0.90 and sparegroups with md monitor are not
compatible. I found this out the hard way after creating a few arrays
with 1.2 and putting them in the same sparegroup--when one array went
degraded, mdadm removed the spare from one, but failed when trying to
add it to the other, leaving me one spare less and with a degraded
array still.

Fun!

Cheers

cc

On Mon, Apr 20, 2009 at 11:10 AM, Piergiorgio Sartor
<piergiorgio.sartor@nexgo.de> wrote:
> Hi,
>
> first of all thanks a lot for all the suggestions,
> it is really nice to have this support!
>
> While reading the answers, I realized that I did
> not make the "requirements" really clear. My bad.
>
> The "primary" disk is an external one, which 90%
> of the time is connected to the same Linux PC.
> But, it could happen it is removed and connected
> somewhere else, where no "md" is available.
>
> My idea was, in order to have some protection, to
> use it in RAID-1 "superblockless" configuration
> on the "default" PC, and use it as a normal disk
> whenever (or wherever) necessary.
> Of course, the bitmap resync will not work, when
> updating the disk directly, without "md" layer.
>
> On the other hand, if the full-resync is always
> done from this disk to the local mirror, there
> would be no problem, except time.
>
> The reason to do this kind of backup is that this
> disk is encrypted, so a "block device copy" will
> keep the data encrypted, while a backup of the
> mounted disk will not. Unless done to another
> encrypted disk/partition, of course.
>
> Clearly, any suggestion is still really appreciated!
>
> Thanks again,
>
> bye,
>
> --
>
> piergiorgio
> --
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>



-- 
Chris Chen <muffaleta@gmail.com>
"I want the kind of six pack you can't drink."
-- Micah
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: RAID without superblock

[John Robinson]

On 19/04/2009 22:04, Piergiorgio Sartor wrote:
>> Why would you want a RAID-1 without superblock. I generally
>> consider that a legacy configuration.
> 
> 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, something somewhere is going to have to change; at the very least 
you're going to have to stop whatever's using the filesystem, unmount 
it, do whatever to create the new RAID-1 incorporating the original 
disc, and remount the filesystem now on the new md device.

So instead you could create a new RAID-1 md device with (a superblock 
and) one disc missing, create a filesystem on it, stop your original 
filesystem, copy its contents to the new md device, mount it, and add 
the original disc into the new md device.

If you've too much data to be able to afford the downtime copying, use 
rsync with the appropriate options while the filesystem's still in use, 
then again after it's been stopped; the second copy will complete far 
faster than the full copy.

Cheers,

John.

Re: RAID without superblock

[Tapani Tarvainen]

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