RAID1 - what happens if your motherboard RAID controller dies?

  • Thread starter Thread starter clangers_snout
  • Start date Start date
kony wrote in news:[email protected]
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".
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.
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 news:[email protected]
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]
 
kony said:
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.

I wouldn't waste too much of your time trying to explain things to this
troll. He looks like he's another one of those "never wrong" people.
 
kony wrote in news:[email protected]
The answer is: no, it is not a problem-

You really need to replace that broken record, boy.
Go back and reread the thread about what I said about existing meta
data and acceptance by new systems and RAID bios programmers.
 
Shadow36 wrote
I wouldn't waste too much of your time trying to explain things to this
troll. He looks like he's another one of those "never wrong" people.

Like that Konehead, you mean?
He's speculating just as much but his 'expeculations' are always 'better'.
 
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?

RAID1 might not be a problem in some cases, as RAID1 is just otherwise
known as mirroring. For the most part, mirroring maintains the original
partitioning structure intact without the wierdness of RAID5. As others
have pointed out the RAID schemes differ in how they maintain their
metadata (the data that organizes the RAID structures). But usually it's
no big deal, putting the drive into a new machine may just mean that the
first machine's metadata is ignored and they recreate the metadata into
the same location on the new machine.

Now just to be nitpicky, motherboard RAID is not really "hardware RAID".
It still uses the system processor to do the RAIDing. The software just
exists inside the BIOS as opposed to inside a Windows device driver, but
it's software nonetheless. In fact, in most cases it resides in both
BIOS and a Windows device driver, where the drive loads via BIOS driver,
and then the BIOS driver hands off the duties to the Windows driver once
it loads. The BIOS & Windows drivers are supplied by the same
manufacturer and therefore are compatible with each other.

A true hardware RAID would not have such a problem, because neither the
operating system nor the system BIOS would even know that they are
running on a RAIDed disk. The disk would be RAIDed by either an external
disk storage array with its own microprocessor, or at the very least by
a plug-in RAID card, also with its own internal intelligence.

Yousuf Khan
 
Frank said:
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?

These days, there are only a few possibilities of where the metadata is
written to. One would be to one of the 4 primary partitions. The second
place would be to one of the multiple extended partitions. The last
possibility is that it is not written to a visible partition anywhere,
but just that the partitions have been edited short by one cylinder and
it keeps everything in that invisible last cylinder.

Yousuf Khan
 
These days, there are only a few possibilities of where the metadata is
written to. One would be to one of the 4 primary partitions. The second
place would be to one of the multiple extended partitions. The last
possibility is that it is not written to a visible partition anywhere,
but just that the partitions have been edited short by one cylinder and
it keeps everything in that invisible last cylinder.

It is never written to partitions. There is no space for it.
It also hast to go to all disks (RAID1) or at least to two
(RAID5) or three (RAID6) disks. ALso cylinders have gone out
of fashion a long time ago. Today you just shorten the disk by one
or two sectors.

Arno
 
Yousuf Khan wrote in news:[email protected]
RAID1 might not be a problem in some cases, as RAID1 is just otherwise
known as mirroring. For the most part, mirroring maintains the original
partitioning structure intact without the wierdness of RAID5. As others
have pointed out the RAID schemes differ in how they maintain their
metadata (the data that organizes the RAID structures). But usually it's
no big deal, putting the drive into a new machine may just mean that the
first machine's metadata is ignored and they recreate the metadata into
the same location on the new machine.
Now just to be nitpicky,

Says Yousuf Khan, comp.sys.ibm.pc.hardware.storage kOOk of the year Award nominee.
motherboard RAID is not really "hardware RAID".
It still uses the system processor to do the RAIDing.
The software just exists inside the BIOS

Gee, maybe because that is what BIOS means?
as opposed to inside a Windows device driver,

Like that doesn't use the system processor.
but it's software nonetheless.

Yeah, the windows driver obviously isn't.

No? Really?
in most cases

Is that a fact.
it resides in both BIOS and a Windows device driver,

Or the driver just uses some of the 32-bit routines supplied by the bios
and not know of any array structures, very similar to hardware assisted
RAID.
where the drive loads via BIOS driver,
..

and then the BIOS driver hands off the duties to the Windows driver
once it loads.
The BIOS & Windows drivers are supplied by the same
manufacturer and therefore are compatible with each other.

Like that is any different with any other hardware.
A true hardware RAID would not have such a problem,

Problem, mister kOOk?
because neither the operating system

No difference there, whether single drive, firmware RAID
or Hardware assisted RAID.
nor the system BIOS

Like that has got anything to do with it when the RAID card,
or any card for that matter, comes with it's own bios.
would even know that they are running on a RAIDed disk.

Same with any other type.
 
kony wrote in news:[email protected]
No, that is not the question except to _you_.

Fine, he can come to you then and ask you to fix his problem when against
all odds his new system refuses to accept the disk because you guaranteed
him that there would be no such problem, ever.
You keep failing to understand that there is no problem from
metadata being there because the new system with standard
non-raid controller doesn't use metadata.

I never said anything like that.
Perhaps you need to attend some reading apprehension courses?
IF the new controller happened to be a raid controller as well
(that uses metadata) but it did not understand or find the
metadata it needs in order to resume operation of the two
drives as a mirror, then it *can* either treat each drive as a
single span, or it *can* write metadata it does understand to
the drive (user's choice).

What the OP is looking for is not 'can' as in 'maybe' but 'will'
as in 'definetely'.
 
Arno Wagner wrote in news:[email protected]
It is never written to partitions.

How about software RAID, Babblebot.
There is no space for it.
Bwahaha.

It also hast to go to all disks (RAID1) or at least to two (RAID5) or
three (RAID6) disks.
ALso cylinders have gone out of fashion a long time ago.

Nonsense.
Perhaps you want to explain the number of sectors per track in FAT
boot records. Explain Start CHS and End CHS in partition records.
Yes, you can set a Start LBA and Extend too but often they reflect
the limits set by Start and End CHS.
Today you just shorten the disk by one or two sectors.

(Or not at all).
Yes, you can do that too, but that has nothing to do with
"cylinders have gone out of fashion a long time ago".
Some Partitoners anf Formatters still use full cylinders
for setting borders.
 
kony wrote in news:[email protected]
On software raid it is the same,

What "it" is the same.
(And before you start ranting again: no that is not a question mark at
the end of that sentence).
especially so with software raid since it tends not to have any NV
memory onboard besides the bios so metadata would be the only way
to keep track of drives.

The question was about where the data is written on the disks, not
whether it is written to the disks.
Pity you can software RAID partitions too and last I heard sectors
within partitions are just as (non)volatile as those outside partitions.
 
In comp.sys.ibm.pc.hardware.storage kony said:
On 2 Jun 2008 15:47:48 GMT, Arno Wagner <[email protected]>
wrote:
On any drive config besides a single drive span, the
metadata has to be written to every disk, including spares.

No, it does not have to. It is just far easier and safer
to do it that way, so everybody does it.

Arno
 
No, it does not have to. It is just far easier and safer
to do it that way, so everybody does it.

When I used to administer Sun Solaris systems, we used to use one of
two RAID management tools, Veritas Volume Manager (now owned by
Symantec), and Sun's own Disksuite (now ironically also called "Volume
Manager", I guess there are no trademark issues between the two
companies). The Veritas product was far more of a wizardy-type product
where it setup everything in a standard way which you had little or no
control over. But the Sun product was much more controllable on the
low-level. You could chose your own metadata partitions and their
locations, and which disks you chose to put them on. The metadata was
replicated on every disk in Veritas, but you didn't have to do that in
Disksuite. It was best to have them spread out over a minimum of 3
disks for quorum purposes, and that's all.

Yousuf Khan
 
Arno said:
It is never written to partitions. There is no space for it.
It also hast to go to all disks (RAID1) or at least to two
(RAID5) or three (RAID6) disks. ALso cylinders have gone out
of fashion a long time ago. Today you just shorten the disk by one
or two sectors.

Hi Arno,

that is true, but probably some more space is needed :-)

Quote from DDF 1.2 spec, section 5.1:

"A DDF structure MUST reside on every physical disk that participates in
a RAID configuration in a RAID storage subsystem. A minimum of 32MB MUST
be reserved on each physical disk for a DDF structure. The last block of
the reserved space MUST be the last addressable block of the physical disk."

For details, see SNIA-DDFv1.2.pdf at:
http://www.snia.org/tech_activities/standards/curr_standards/ddf

Christian
 
Christian Franke wrote in news:[email protected]

His name is Babblebot.
that is true,

What "that".
but probably some more space is needed :-)

So "that" is *not* true then.
Quote from DDF 1.2 spec, section 5.1:

"A DDF structure MUST reside on every physical disk that participates in
a RAID configuration in a RAID storage subsystem. A minimum of 32MB MUST
be reserved on each physical disk for a DDF structure. The last block of
the reserved space MUST be the last addressable block of the physical disk."

Really?
Well, Babblebot was merely some 64000 sectors off then. Or 4 cylinders or so.
 
that is true, but probably some more space is needed :-)
Quote from DDF 1.2 spec, section 5.1:
"A DDF structure MUST reside on every physical disk that participates in
a RAID configuration in a RAID storage subsystem. A minimum of 32MB MUST
be reserved on each physical disk for a DDF structure. The last block of
the reserved space MUST be the last addressable block of the physical disk."
Christian

Oh, there is space on the disk that can be used, but there is
no reason why the whle disks would need to be partitioned.
The way this is done is by hiding some sectors of the disk and
possibly remapping the rest. Partitioning is done after and does
not touch the hidden sectors.

Side note: I have ni idea what DDF is (and no need to find out,
since I have never heard the term before ;-), but you can
hide an arbitrary amount of space. Linux software RAID
uses a few kB.

Arno
 
Back
Top