RAID1 - what happens if your motherboard RAID controller dies?

In comp.sys.ibm.pc.hardware.storage kony wrote:
On Mon, 26 May 2008 11:01:04 -0700 (PDT), Frank
wrote:

Good discussion, learned a lot of it, since I've got the same thoughts
like starter clangers_....
Question: To me it seems like ICH9R from Intel is popular at the
moment for constructing RAIDs. Might be true or not. But, given the
ICH9R, where does it put these metadata? Does anybody know? Any
experiences anybody about pulling off one RAID1-drive from an ICH9R to
whatever SATA-connector? Does this single special thing out of the big
variety of RAID-Levels and controllers work?

Reagrds,
Frank

Some who have mentioned metadata at the start of a drive are
muddying the waters, like saying it's possible there are
pink elephants even though they are rare. Odd things
happened years ago but today there's one thing to say about
metadata on the start of a drive - don't use a controller
that does this if you can ever find one.

Practically every modern raid controller puts the metadata
on the rear end of the drive.

Good to know that this design mistake is now typically
fixed. People may still have older hardware or get older
hardware from eBay, for example. In that case they need
to be aware of the potential problem.

You can test this easily
enough, if you can take a drive with data on it, define it
as a source or primary in the raid configurator for a raid1.
and still retain all data.

Huh? This does not seem to make any sense.

Here is what you can do (linux):
1) Attach dribe to a non-RAID interface or configure it
as pass-trough/raw. Blank the start of a drive with zeros
head -c 10240 /dev/zero drive
Overwrites the firsth 20 secotrs with zeros. Should
be enough
2) Create a RAID on this disk with your controller.
3) Re-attach it in the form in 1) and look at the
first 20 sectors, e.g. by doing
head -c 10240 drive | hex

I anything was changed, be wary. This controller may put
the metadata at the satrt or mess with the MBR. Both not
good.

Arno

kony wrote in
On Sat, 24 May 2008 00:09:54 +0100, "Squeeze" wrote:
SteveH wrote in
Squeeze wrote:

Some context restored:
This does not mean however that it will work this way every time, you just
have to suck it and see sometimes


to try removing a disk and reading it non-raided in a different computer.

If that works, it should also work in the future ;-)

Or not.
Babblebot's way of saying he didn't understand at all what previous
poster was saying


I was gonna say, that's what I said,

Why would the babblebot repeat what you said?

more or less.

It's obviously gonna work in that particular computer that he would
have checked it in but that doesn't mean it will work in any new
computer he might buy when/if the actual incident is going to happen.

Well, "that doesn't mean it will" is true, but irrelevant -

If the drive is rejected then that's very relevant.

the variable is not whether that worked, only whether the original
system uses a standard config which can take a drive with data
already on it and add that as a source member of a RAID1 array.

*If* it can do that, [then] there is no reason to believe it will make any
changes to the drive

Why not. There must still be information stored /somewhere/ that sig-
nals whether the drives are in sync or that the mirror needs to be rebuilt.
Such information won't be on a standard non-raided drive.

that would prevent use in any other system

Well, that's up to the people who designed/wrote the particular RAID
bios of that other system. I can't speak for them and neither can you.

[snip]

Arno Wagner wrote in
In comp.sys.ibm.pc.hardware.storage kony wrote:
On Fri, 23 May 2008 11:06:50 -0400, kony wrote:
On Thu, 22 May 2008 13:25:45 -0700 (PDT), wrote:

I have a motherboard with a hardware RAID controller built in and I
intend to set up two identical drives in RAID 1 configuration. My
worry is how I would go about recovering the data from either drive if
my motherboard goes down. I assume that you can't just plug one of the
drives in to another motherboard and expect it to be read by a normal
SATA2 (in my case) connection. So how would I recover the data in this
worst case condition?

Unlike other RAID levels, a RAID1 does not need metadata to work and
in fact can be made on any normal controller by taking a drive that was
not a member of any raid array, hooking it up to the controller, then tel-
ling the controller to dupe that onto a second drive.

I should elaborate on what I wrote above. A RAID1 does need
the metadata to exist and be understood by the controller (which
must have the RAID1 funcitonality) in order to continue functioning
as a two drive mirror of a single logical volume but that is not
necessary to read the data off either member alone.

True. There are RAID 1 controllers, however, that put the metadata
at the beginning od the disk and translate everything after. I don't
know how common that is today, but it used to be a problem. If you
can take a disk out of a RAID1 and access it without any special
measures (LVM translation, e.g.) on a non-RAID controller,

then the metadata is very likely at the end

Or at the 'beginning'.
"Beginning" is a relatively imprecise description, Babblebot.
Where does it say that "beginning" has to be sector 0, eh?

or not on disk at all.

There should at least be some extra information to control the validity
and status of the configuration.


Reasons for putting the metadata at the beginning are the usual:
Lazyness, stupidity or a desire to bind you to a specific product.

Or just because there is enough unused space near the start of the drive
that can be used for it's own purposes without interfering with standard
partitioning and/or formatting, Babblebot.


Arno

I'd feel much better about motherboard RAID1 solutions, if I
knew the controller firmware or software, was auditing how
identical the disks were, during idle moments. I'm not aware
of any of these solutions, auditing their own performance.

I prefer RAID 5 for this very reason - it's most unlikey to unRAID itself
without you knowing anything about it. Also, there is less faffing around if a
disk does dir - just plug in the replacement and rebuild. Of course that
doesn't get round the different controller problem but there you go.

--
Boo

On Tue, 27 May 2008 22:19:43 +0100, "Squeeze"
wrote:


the variable is not whether that worked, only whether the original
system uses a standard config which can take a drive with data
already on it and add that as a source member of a RAID1 array.

*If* it can do that, [then] there is no reason to believe it will make any
changes to the drive

Why not.

Because as I wrote, the data was already on it and it worked
meaning the array does not depend on having relocated data
from areas necessary for a standard non-raid controller to
access it.

There must still be information stored /somewhere/ that sig-
nals whether the drives are in sync or that the mirror needs to be rebuilt.
Such information won't be on a standard non-raided drive.

Yes, information that the standard controller in the *new*
system will ignore because the new system isn't trying to
run these two drives as a raid array, unless it happened to
be a raid controller and the user then decided to define an
array... but with either single drive all the data is
accessible, except as you mentioned there is the issue of
one drive being damaged in some way or not logically in sync
with the other, so if there is a question of which is intact
then both need to be checked for data freshness.


that would prevent use in any other system

Well, that's up to the people who designed/wrote the particular RAID
bios of that other system. I can't speak for them and neither can you.

It's not up to them, you keep missing the crucial piece of
the puzzle which was the precondition that if the data was
already written to a single drive and the raid controller
can incorporate it into a RAID1 array without having to copy
the data to it again, it is showing that it has left the
data intact regardless of metadata later written.

On Wed, 28 May 2008 01:07:21 +0100, Boo
wrote:

I'd feel much better about motherboard RAID1 solutions, if I
knew the controller firmware or software, was auditing how
identical the disks were, during idle moments. I'm not aware
of any of these solutions, auditing their own performance.

I prefer RAID 5 for this very reason - it's most unlikey to unRAID itself
without you knowing anything about it.

?? Any modern raid controller bios and the software
management util should notify of this regardless of which
raid level it were.


Also, there is less faffing around if a
disk does dir - just plug in the replacement and rebuild.

.... same as RAID1, so you're essentially just trading more
capacity for less compatibility, which is a fine, yet
subjective choice if one has 3 or more drives to devote to
that.

On Tue, 27 May 2008 23:11:09 +0100, "Squeeze"
wrote:

Arno Wagner wrote in
In comp.sys.ibm.pc.hardware.storage kony wrote:
On Fri, 23 May 2008 11:06:50 -0400, kony wrote:
On Thu, 22 May 2008 13:25:45 -0700 (PDT), wrote:

I have a motherboard with a hardware RAID controller built in and I
intend to set up two identical drives in RAID 1 configuration. My
worry is how I would go about recovering the data from either drive if
my motherboard goes down. I assume that you can't just plug one of the
drives in to another motherboard and expect it to be read by a normal
SATA2 (in my case) connection. So how would I recover the data in this
worst case condition?

Unlike other RAID levels, a RAID1 does not need metadata to work and
in fact can be made on any normal controller by taking a drive that was
not a member of any raid array, hooking it up to the controller, then tel-
ling the controller to dupe that onto a second drive.

I should elaborate on what I wrote above. A RAID1 does need
the metadata to exist and be understood by the controller (which
must have the RAID1 funcitonality) in order to continue functioning
as a two drive mirror of a single logical volume but that is not
necessary to read the data off either member alone.

True. There are RAID 1 controllers, however, that put the metadata
at the beginning od the disk and translate everything after. I don't
know how common that is today, but it used to be a problem. If you
can take a disk out of a RAID1 and access it without any special
measures (LVM translation, e.g.) on a non-RAID controller,

then the metadata is very likely at the end

Or at the 'beginning'.
"Beginning" is a relatively imprecise description, Babblebot.
Where does it say that "beginning" has to be sector 0, eh?

What it writes, can't be overwriting existing data (incl.
partitioning, MBR) when we see it's still there after adding
it as primary member upon which the mirrored volume is
built. It's not a matter of it adding metadata, it's a
matter of us not caring about metadata because the standard
controller upon which the data salvage operation question
was asked about, does not need metadata.

Or just because there is enough unused space near the start of the drive
that can be used for it's own purposes without interfering with standard
partitioning and/or formatting, Babblebot.

Except there's the potential for contention with other
utilities that might put code there, so long ago they
learned to leave the beginning alone.

I'm starting to get the impression you're arguing about
something you have never tried, or at least not in several
years.

kony wrote in
On Tue, 27 May 2008 22:19:43 +0100, "Squeeze" wrote:

the variable is not whether that worked, only whether the original
system uses a standard config which can take a drive with data
already on it and add that as a source member of a RAID1 array.

*If* it can do that, [then] there is no reason to believe it will make any
changes to the drive

Why not.

Because as I wrote, the data was already on it and it worked
meaning the array does not depend on having relocated data from
areas necessary for a standard non-raid controller to access it.

You didn't say anything about relocating data, you said "making changes".


There must still be information stored /somewhere/ that signals
whether the drives are in sync or that the mirror needs to be rebuilt.
Such information won't be on a standard non-raided drive.

Yes, information that the standard controller in the *new*
system will ignore

Say you.

because the new system isn't trying to run these two drives as a raid array,

unless it happened to be a raid controller

Exactly.

and the user then decided to define an array...

Not necessarily.

but with either single drive all the data is accessible, except

as you mentioned

That's not why I mentioned it.

there is the issue of one drive being damaged in some way or not logically
in sync with the other, so if there is a question of which is intact then
both need to be checked for data freshness.


that would prevent use in any other system

Well, that's up to the people who designed/wrote the particular RAID
bios of that other system. I can't speak for them and neither can you.

It's not up to them,

Yes it is, if they decide to not accept a drive that has the signs of
having been in a different raid configuration that's not their own.

you keep missing the crucial piece of the puzzle

So you keep saying.

which was the precondition

What precondition.

that if the data was already written to a single drive

A RAID1 drive member.

and the raid controller can incorporate it into a RAID1 array without
having to copy the data to it again, it is showing that it has left the
data intact regardless of metadata later written.

And now you are missing the point. I never mentioned the user data.
I mentioned the metadata and how that could be a reason why the
drive would be rejected. Whatever more you read into that is of
your own fault.

kony wrote in
On Tue, 27 May 2008 23:11:09 +0100, "Squeeze" wrote:
Arno Wagner wrote in
In comp.sys.ibm.pc.hardware.storage kony wrote:
On Fri, 23 May 2008 11:06:50 -0400, kony wrote:
On Thu, 22 May 2008 13:25:45 -0700 (PDT), wrote:

I have a motherboard with a hardware RAID controller built in and I
intend to set up two identical drives in RAID 1 configuration. My
worry is how I would go about recovering the data from either drive if
my motherboard goes down. I assume that you can't just plug one of the
drives in to another motherboard and expect it to be read by a normal
SATA2 (in my case) connection. So how would I recover the data in this
worst case condition?

Unlike other RAID levels, a RAID1 does not need metadata to work and
in fact can be made on any normal controller by taking a drive that was
not a member of any raid array, hooking it up to the controller, then tel-
ling the controller to dupe that onto a second drive.

I should elaborate on what I wrote above. A RAID1 does need
the metadata to exist and be understood by the controller (which
must have the RAID1 funcitonality) in order to continue functioning
as a two drive mirror of a single logical volume but that is not
necessary to read the data off either member alone.

True. There are RAID 1 controllers, however, that put the metadata
at the beginning od the disk and translate everything after. I don't
know how common that is today, but it used to be a problem. If you
can take a disk out of a RAID1 and access it without any special
measures (LVM translation, e.g.) on a non-RAID controller,

then the metadata is very likely at the end

Or at the 'beginning'.
"Beginning" is a relatively imprecise description, Babblebot.
Where does it say that "beginning" has to be sector 0, eh?

What it writes, can't be overwriting existing data (incl.
partitioning, MBR) when we see it's still there after adding
it as primary member upon which the mirrored volume is built.

That wasn't the question.

It's not a matter of it adding metadata,

The question is: will the existing metadata be a problem
when the drive is introduced to a different computer.

Btw, I was merely correcting the babblebot.
Whatever more you read into that is of your own fault.

[snip]

On Fri, 30 May 2008 00:30:53 +0100, "Squeeze"
wrote:


And now you are missing the point. I never mentioned the user data.
I mentioned the metadata and how that could be a reason why the
drive would be rejected. Whatever more you read into that is of
your own fault.

You keep thinking the metadata matters when it does not, the
reason I mentioned the user data was to enlighten you about
the situation with the metadata, that in the end the
metadata is only a means towards the userdata and when one
independent volume can be added intact to a new array as the
data source, it remains that way whether metadata is there,
or not, whether metadata is compatible or not if it is
there.

Hooking the former RAID1 members up to a new non-raid
controller, or a raid controller but not trying to set it up
as an array - just get the data, there is no expectation
that the drive would be rejected.

Just try it already. There is one more significant reason
why the data access would be a problem, that is if some of
Intel's screwy Maxtrix schemes were used instead of a
straight textbook RAID1. In that case a compatible Intel
Matrix controller would have to be used for some if not all
of the data. I have not nor am I likely to use these
special Maxtrix modes (for exactly this reason) so I don't
know how that would turn out.