RAID1 - what happens if your motherboard RAID controller dies?
clanger...@yahoo.co.uk
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?
Arno Wagner
Coingratulations, you have found one inherent porblem with
hardware-RAID (as opposed to software RAID).
Having a spare mainboard is handy. This has all sorts of
problems, e.g. whai if the CPU dies and a replacement
is difficult to obtain. Controller card is a little better
but not oo much. There is RAID recovery software,
but it costs money.
I would advise to use software RAID instead, as here
you can just move the drives to a different machine.
Arno
NB
You would need to replace the motherboard anyways, and that would fix
the problem (assuming the motherboard hasn't been discontinued).
SteveH
It depends entirely on the mobo/controller(s) in question. For example, I
have a customer whose MSI socket 754 mobo failed, this had 2 SATA srives in
Raid1. I got him a new board, an Intel P35 based one, so different kit all
round. I attached one of the drives in normal mode and it was read
immediately, just needed to change the drivers and we were up and running. I
then just added the 2ns drive back and rebuilt the Raid.
This does not mean however that it will work this way every time, you just
have to suck it and see sometimes.
--
SteveH
Squeeze
> 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
You do? What is your assumption based on?
> 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.
No? Why not? Have you tried?
> So how would I recover the data in this worst case condition?
Not, based on your assumption.
How does the word "backup" sound to you?
Arno Wagner
The issue here is where the RAID stores its metadata. If in EEPROM,
you are fine. If on the end of the disk, you are fine as well.
If at the beginning of the disk, it gets difficult.
But, true, for RAID1 you may get lucky. I would advise you to
try removing a disk and reading it non-raided in a different
computer. If that works, it should also work in the future ;-)
Arno
Mike Ruskai
clanger...@yahoo.co.uk dribble thusly:
You assume incorrectly, in every RAID1 setup I've seen. Each member can be
accessed as a stand-alone drive if necessary, on a normal controller.
Whatever on-disc configuration information there is resides outside the normal
disc layout (partition, LVM, whatever).
Squeeze
> > clanger...@yahoo.co.uk 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?
>
> > It depends entirely on the mobo/controller(s) in question. For example, I
> > have a customer whose MSI socket 754 mobo failed, this had 2 SATA srives
> > in Raid1. I got him a new board, an Intel P35 based one, so different kit all
> > round. I attached one of the drives in normal mode and it was read
> > immediately, just needed to change the drivers and we were up and running.
> > I then just added the 2ns drive back and rebuilt the Raid.
> > This does not mean however that it will work this way every time, you just
> > have to suck it and see sometimes.
>
> The issue here is where the RAID stores its metadata. If in EEPROM,
> you are fine. If on the end of the disk, you are fine as well.
> If at the beginning of the disk, it gets difficult.
Difficult, babblebot?
>
> But, true, for RAID1 you may get lucky.
> *I would advise you*
Don't you love the sound of that.
He get's corrected yet immediately starts to advise again.
Maybe this time his advice is better, no?
> 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
>
> Arno
SteveH
>
>> 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, more or less.
--
SteveH
kony
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 telling the controller
to dupe that onto a second drive.
Because it's RAID1 you should be able to pull either drive
(assuming both are still working, that whatever killed the
motherboard did not effect the drive(s)), install in any
other standard SATA150 or 300 system and have all the data
intact.
IF you had been talking about a RAID0 instead, you'd need to
connect them to a compatible controller, the safest bet is
to buy another motherboard with exact same southbridge chip
or discrete RAID controller chip - depending on which chip
gives it the raid functionality... usually on consumer gear
today it's the southbridge like an Intel ICH9R for example.
However, it is possible that with the Intel Matrix RAID you
might be able to set up some kind of RAID that is not
supported by separate controllers, I am only speaking of a
traditional RAID1 above where you have the array using the
entirety of both drives, not trying to regain excess space
on one if one is larger than the other, but once you had an
array set up it would not be a problem to put multiple
partitions on it.
Ultimately the safest bet is to test your recovery strategy.
Put some test data on the array, then power off pull drive
and put in another system to confirm you have access to it.
It should also be said that an online RAID1 isn't really a
substitute for a removable/removed backup of the data since
a power surge, PSU failure, virus or whatever could equally
wipe out drives and/or data simultaneously.
Squeeze
> 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.
By the time it happens computers without RAID capability may not be
available anymore. RAID controllers may well check in specific places
for any evidence of previous raid implementation and refuse to accept
it when its not their own, even if you want to use it as non-raided.
To avoid such unwanted behaviour the RAID capability must be able
to be switched off entirely.
Like you said, it depends. That's not what the babblebot said.
If want to be sure, have backups.
kony
<rubbe...@duckies.au> wrote:
>SteveH wrote in news:LKuZj.8101$DZ6....@text.news.virginmedia.com
>> 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 -
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, there is no
reason to believe it will make any changes to the drive that
would prevent use in any other system that would've
otherwise supported the same drive if it were a single
logical volume, because essentially a RAID1 IS two single
logical volumes, that's the whole point of it.
>By the time it happens computers without RAID capability may not be
>available anymore.
Which is also a bit irrelevant, since the issue supposed was
IF it'd need be a RAID controller and IF that were true the
issue isn't just does it have RAID or not but rather is the
RAID controller very nearly the same. Even a different bios
for the same raid controller has the potential to break
things, but fortunately since we're talking about RAID1
these factors don't matter.
>RAID controllers may well check in specific places
>for any evidence of previous raid implementation and refuse to accept
>it when its not their own, even if you want to use it as non-raided.
False. If the RAID array depended on the metadata to
identify the configuration and could not do so, it would not
be able to create an array with two drives. Since a RAID1
does not need to have an array with two drives in order to
read the data off of either drive, which is again the whole
point of RAID1, and since a drive that held data which had
never been in any array can be made the source in a new
array, we can conclude that even if there were a case where
a new/different controller wouldn't make a RAID1 array with
these two drives without having to wipe and recreate it on
the 2nd drive - it still wouldn't matter since either is an
independent volume holding all the data. The drive could
simply be read as a single drive span.
>To avoid such unwanted behaviour the RAID capability must be able
>to be switched off entirely.
There's no such distinction necessary. Hook either of the
drives up to a raid or non-raid controller, period. No
special thoughts or actions or features required.
>
>Like you said, it depends.
Name 1 controller less than several years old that can't
take a RAID1 member and read off the data, assuming
otherwise compatible in a very basic way (same data
interface, SATA or PATA, supporting the drive capacity if
PATA, etc).
kony
wrote:
>On Thu, 22 May 2008 13:25:45 -0700 (PDT),
>clanger...@yahoo.co.uk 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 telling 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.
Arno Wagner
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 not on disk at all.
Reasons for putting the metadata at the beginning are the
usual: Lazyness, stupidity or a desire to bind you to
a specific product.
Arno
Frank
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
Paul
I think the answer to this one is simple.
You don't need to know where the metadata is stored :-)
Why ? Because RAID1 is not a substitute for backups.
Consider the following scenarios.
1) You download a virus. It zeros a single sector in the middle
of every MP3 file you have stored on the computer. Does the
RAID1 mirror protect from this fault ? No. Both disks have
the exact same (virus damaged) files stored on them.
2) Consider the power supply fails in the computer. The 12V rail
rises to 15V. The motors on both hard drives are burned instantly.
Does the RAID1 help you now ? No. Both disks are dead. Same
thing, if there was an electrical storm passing overhead, and
your house AC is hit. Both motherboard and drives could be
ruined.
That is why you have daily backups - incremental and full backups.
If the computer is destroyed, you reach for that USB external enclosure
you use on a daily basis, and you do a cold metal restore to
the newly constructed computer. Now it doesn't matter where the
metadata is. Because the backup image has captured the data.
By storing the USB external enclosure in a safe place, away
from the computer, there are better odds it'll survive an
act of God.
Another point. If you're going RAID1, connecting the computer
to an uninterruptible power supply. If the uninterruptible power
supply has a serial cable to connect to the back of the computer,
that will allow an automated and orderly shutdown if you aren't
present when the power goes off. That will help maintain the exact
mirroring of your RAID1 drives. Otherwise, an abrupt shutdown, could
leave divergent contents.
Paul
Frank
> I think the answer to this one is simple.
>
> You don't need to know where the metadata is stored :-)
>
> Why ? Because RAID1 is not a substitute for backups.
>
Excuse me, Paul, but there is one thing I don't like: "You don't need
to know", since "I like to know!"
Let me explain: Raid 1 is no substitute for a backup, that's correct.
But if I receive RAID for free (with a P35 mainboard) and considering
the cost for a second hard drive (70 Euros for 0.5GB), it's simply
worth the money.
What I mean is: I pay 70 Euros for the second drive and I receive the
assurance "if a disk crashes (and only in that case) you'll have a
second one with the identical content". Nothing else! No virus
protection, no power problem protection, no whatsoever protection,
only "if one drive fails, the other has the copy and you don't need to
spend money, time and nerves to reconstruct from backup." Of course,
if the system blows up for any other reason, it's very helpful to have
a backup.
On the other hand, my personal statistic:I'm in that business for
nearly twenty years, I've started with a 20 MB MFM-harddrive (yes,
kids, it weight a few kilos!). In that time, I've experienced no virus
problem, no power problems, nothing, but two hard drives crashed in
only 27 months (1st an IBM and 2nd a Samsung). This is my personell,
not representative experience.
And after all these words: Does anybody know, what ICH9R does
(following the discussion of this thread)?
Kind regards
Paul
The metadata position is not public knowledge. If you want to know,
you connect a disk to an Intel Southbridge, create a RAID volume, and
then search for the sector or sectors that have changed.
There is a reasonable chance, that if you took a hard drive connected
as RAID1, on a ICH6R, it would work on a ICH9R. There should be continuity
in the forward direction. There might not be in the reverse direction
(as ICH9R might support RAID5, and ICH6R doesn't, and ICH6R RAID BIOS
won't know what RAID5 is).
The only other company, that offers some kind of statement about
compatibility between controllers, was Promise. Whether that is still
true, is unknown to me.
The reason no public statements are made, is it allows the companies
involved, to change the metadata format, any time they choose, without
warning to the public. As technical requirements merit.
As an example of my own, personal experience. I connected a drive
to a Promise controller (perhaps PDC20378), and discovered that the
first partition was no longer visible. So at least in the case
of that chip, and the metadata it was using, there was some problem
seeing a partition, when moving between an Intel chip and a separate
Promise PDC20378. Tomshardware did an article, some time ago,
where they tried something similar. I had my own theories as to
which test cases would work, and which ones would not. Virtually
any heterogenous case, failed. Some of the homogenous cases
(moving Promise array to another Promise card), worked.
But I don't see any categorical statements being possible, unless
these companies take inter working as a serious technical requirement.
You can buy two PCI or PCI Express controller cards, and put one away
for the day when the first one fails. As some of the cards are dirt
cheap (such as some of the old SIL3112 dual port cards), that is not
such an expensive alternative. But the performance and reliability
of these solutions, leaves a lot to be desired. For example, at
least one person has seen a SIL3112 operating in RAID1 mode,
where the RAID stopped "mirroring" for a period of three months.
When one of the disks died, the data available on the other disk
was "stale" and as near as the poster could determine, about
three months old. Based on that kind of performance, I'd want a
solution that is a bit better behaved.
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.
Based on a few factors like that, I feel a backup is still
a wise investment.
Paul
Arno Wagner
> Reagrds,
> Frank
I don't know what exactly Intel does, but it seems Linux dmraid
(the fakeraid driver) can access intel RAID arrays. That means
even without the controller the disks are accessible with Linux.
It seems Intel stores the metadata in the last two sectors of the
disk (but I found no hard evidence, just heresay). If true,
that would mean that you can use the individual disks in a RAID1 on
any non-raid controller.
Arno
kony
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. 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. There is however a chance
someone could make the wrong choice in the configurator
(raid bios or raid manager software) and it would wipe out
the partition table, sector 0 - and of course the data from
a logical perspective of being unable to access it as-is,
even though the bits are still on the platters it is
prepared for a new partition and filesystem to be created,
not wiped out because the metadata was placed there.
Arno Wagner
> <fmbsg-...@yahoo.de> 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
Boo
> 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
Squeeze
> > SteveH wrote in news:LKuZj.8101$DZ6....@text.news.virginmedia.com
> > > 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]
Squeeze
> > On Fri, 23 May 2008 11:06:50 -0400, kony <sp...@spam.com> wrote:
> > > On Thu, 22 May 2008 13:25:45 -0700 (PDT), clanger...@yahoo.co.uk 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
> > > 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
kony
<rubbe...@duckies.au> 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.
kony
<reply_to_group_not_me@spam_me_no_spam.net> 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.
kony
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.
Squeeze
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]
Squeeze
> On Tue, 27 May 2008 22:19:43 +0100, "Squeeze" <rubbe...@duckies.au> 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
<rubbe...@duckies.au> 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.
kony
<rubbe...@duckies.au> wrote:
>The question is: will the existing metadata be a problem
>when the drive is introduced to a different computer.
>
The answer is: no, it is not a problem- Providing the
condition I already stipulated, that the originating
controller was compatible with a standard controller to the
extent that one can take a drive volume created with the
standard controller and implement that as a new array on the
originating raid controller without losing the data that
member already held.
I'm sure you know a person could make a mistake at that
point, could accidentally wipe out the data on the drive by
choosing the wrong raid bios menu choice to make a new array
treating it as an empty logical volume instead of starting
out by mirroring the source to a second drive... same
difference as adding a spare any other time a drive fails.
Metadata allows array ID, it does not prevent intact single
volumes from working when there was no need for metadata (on
a standard non-raid controller or non-raid config on a raid
controller (single drive span).
However, this may all be beside the point that if the data
is valueable enough to worry about it, the RAID1 should not
be considered the primary backup method but instead a method
of ensuring more immediate data availability.
Squeeze
>
>
> > 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.
>
Looking in the mirror boy?
You really need to replace that broken record, boy.
Squeeze
>
>
> > The question is: will the existing metadata be a problem
> > when the drive is introduced to a different computer.
> >
>
> 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
"kony" <sp...@spam.com> wrote in message
news:68qu34dt9g2ivrmce...@4ax.com...
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
<rubbe...@duckies.au> wrote:
>> 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.
>
No, that is not the question except to _you_.
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. 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).
kony
Thank you for your most valuable insight. I'd have time to
do that if I weren't so busy handing you clues about how to
do simple things like get data off a mirrored volume.
Floyd63
> news:68qu34dt9g2ivrmce...@4ax.com...
> > On Fri, 30 May 2008 00:30:53 +0100, "Squeeze"
> > <rubbe...@duckies.au> 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.
> 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'.
Yousuf Khan
> 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
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.
Yousuf Khan
Arno Wagner
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
Squeeze
> > 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,
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.
> In fact,
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.
Squeeze
ROTFLOL.
>
> Yousuf Khan
Squeeze
> <rubbe...@duckies.au> wrote:
>
>
> > > 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.
> >
>
>
> 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'.
Squeeze
> > 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?
>
> > 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.
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.
>
> Arno
kony
It is impossible for it to be written to any "partition"
structure as a new disk defined as member of an array may
not even have any partitions on it yet, and in cases of
arrays other than a mirror, the partitions would have to be
recreated anyway.
kony
wrote:
On any drive config besides a single drive span, the
metadata has to be written to every disk, including spares.
kony
<rubbe...@duckies.au> wrote:
>Arno Wagner wrote in news:6aij14F...@mid.individual.net
>> In comp.sys.ibm.pc.hardware.storage Yousuf Khan <bbb...@yahoo.com> wrote:
>> > 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?
>>
>> > 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.
>
>How about software RAID, Babblebot.
On software raid it is the same, 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.
kony
<rubbe...@duckies.au> wrote:
>What the OP is looking for is not 'can' as in 'maybe' but 'will'
>as in 'definetely'.
If you want guarantees in life, sorry even things that are
supposed to work don't always... but addressing the question
it is not a problem assuming everything else works as it's
supposed to. By the same token you can't assume using a
non-raid drive on a 2nd non-raid system is guaranteed to
work either, only that it is supposed to work based upon the
standard they are designed under. Similarly you can't
assume all AGP video cards will work on any random
motherboard even if the tech (slot type, voltage, etc) is
supposed to be compatible.
The real solution isn't being able to move a raid drive and
get data, it's to see that raid is meant for constant uptime
of the volume and that a separate offline backup of that
data is prudent in addition to the array.
Arno Wagner
No, it does not have to. It is just far easier and safer
to do it that way, so everybody does it.
Arno
Squeeze
> > Arno Wagner wrote in news:6aij14F...@mid.individual.net
> > > In comp.sys.ibm.pc.hardware.storage Yousuf Khan <bbb...@yahoo.com> wrote:
> > > > 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?
> > >
> > > > 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.
> >
> > How about software RAID, Babblebot.
> 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.
Squeeze
Whatever that is supposed to extra clarify.
One more of your mystifying sentences, as always.
kony
Oh, well, have a free one on me: ?
If you don't know what, note that I left the text above for
your reading pleasure.
kony
wrote:
Oh? Then how do you propose that the drives are identified
as members of the array? I'll grant you that it would be
possible for a (typically hardware) controller to record
drive serial number into an onboard non-volatile memory
area, and by doing so it would not require metadata to be
written to any drive, so in that case what I wrote was
wrong. However in the case where that were true there would
be a requirement to keep the drives with the specific raid
controller, even an otherwise identical controller wouldn't
work with an existing array, and that is a situation a
designer would not want to cause so I must ask for some
example of a controller with array members where some but
not all have metadata.
bbbl67
> > 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.
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
Christian Franke
>> 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.
>
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
Squeeze
> > In comp.sys.ibm.pc.hardware.storage Yousuf Khan <bbb...@yahoo.com> wrote:
> > ...
> > > 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.
> >
> Hi Arno,
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.
Arno Wagner
> Hi Arno,
> 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
Christian Franke
> In comp.sys.ibm.pc.hardware.storage Christian Franke <...> wrote:
> ...
>> 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
> 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.
>
Common RAID Disk Data Format (DDF) is an effort to standardize RAID in
order to provide interoperability between different vendors. It
specifies RAID levels 0-6, with several flavors of RAID 5.
AFIAK, this format is used at least by some recent Adaptec (and ICP)
controllers. There is also a DDF "white paper" from Intel, so this
format may also be used by some Intel controllers. Linux dmraid is able
to detect DDF metadata.
So there may probably be some "need to find out" before further
discussions :-)
@OP: DDF RAID1 does no sector remapping, see section 4.2.2 of the spec.
As a consequence, a disk from a DDF RAID1 array can be accessed as a
single disk on a foreign controller. The metadata block will appear as
unpartitioned space at the end of the disk.
I have seen this layout also on other non-DDF controllers, e.g. 3ware.
Christian
Arno Wagner
>> In comp.sys.ibm.pc.hardware.storage Christian Franke <...> wrote:
>> ...
>>> 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
>> ...
>> 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.
>>
> Common RAID Disk Data Format (DDF) is an effort to standardize RAID in
> order to provide interoperability between different vendors. It
> specifies RAID levels 0-6, with several flavors of RAID 5.
Aha. Interesting.
> AFIAK, this format is used at least by some recent Adaptec (and ICP)
> controllers. There is also a DDF "white paper" from Intel, so this
> format may also be used by some Intel controllers. Linux dmraid is able
> to detect DDF metadata.
> So there may probably be some "need to find out" before further
> discussions :-)
When I find the time.
> @OP: DDF RAID1 does no sector remapping, see section 4.2.2 of the spec.
> As a consequence, a disk from a DDF RAID1 array can be accessed as a
> single disk on a foreign controller. The metadata block will appear as
> unpartitioned space at the end of the disk.
> I have seen this layout also on other non-DDF controllers, e.g. 3ware.
Linux software RAID also does this. (Note that dmraid is not
Linux software RAID). I believe the main reason for placing
the metadata at the start (as some older controllers do) was
intentional incompatibility.
Arno
Squeeze
There, that should teach you to not take that babblebot seriously,
ever again.
>
> Arno
bbbl67
> Says Yousuf Khan, comp.sys.ibm.pc.hardware.storage kOOk of the year Award nominee.
Squeeze, I know you enjoy proudly showing off your generally low IQ,
but why lash out at the world due to your father ass-raping you as a
kid? Aren't there other ways of dealing with your sad predicament?
Counseling, anti-depressants, etc.?
> > 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?
Gee, mongoloid-boy, you've read something about this BIOS, and now
you're showing off to the world that you know what it means? I'm so
proud for you, everybody needs hope.
> > as opposed to inside a Windows device driver,
>
> Like that doesn't use the system processor.
Now, now, Squeeze, it's time for some reading comprehension studies,
you've made so much progress otherwise. I have said Windows and BIOS
make use of the central processor.
> 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.
No, not a chance! The Windows drivers would never make use of routines
inside the BIOS, as the BIOS routines are written for the Real Mode of
the processor, whereas Windows operates in Protected Mode. Real Mode
routines will never work once the processor enters Protected Mode.
Windows device drivers are basically translations of the BIOS routines
from Real Mode to Protected Mode. The BIOS will pass some data
structures stored in memory off to the Windows device drivers, but
once those structures have been passed, the BIOS is ignored and
essentially shut down, while the Windows device drivers take over all
of the hardware I/O.
> No difference there, whether single drive, firmware RAID
> or Hardware assisted RAID.
Listen homo erectus, who can take you seriously, if you don't even
know the difference between hardware raid and firmware raid?
Go get educated first, or stop coming here, we don't need your idiotic
rants here.
Yousuf Khan
Dan
>
> No, not a chance! The Windows drivers would never make use of routines
> inside the BIOS, as the BIOS routines are written for the Real Mode of
> the processor, whereas Windows operates in Protected Mode. Real Mode
> routines will never work once the processor enters Protected Mode.
> Windows device drivers are basically translations of the BIOS routines
> from Real Mode to Protected Mode. The BIOS will pass some data
> structures stored in memory off to the Windows device drivers, but
> once those structures have been passed, the BIOS is ignored and
> essentially shut down, while the Windows device drivers take over all
> of the hardware I/O.
>
reinstalling the os then Right? The Bios will allow acces to the dvd drive.
even though I have a clean system.? I know it is a stupid question, but I
always wondered when someone built a computer how they ever get to load the
driver for the External drives to install the OS?
Dan
kony
BIOS provides boot functionality for several types of
devices, ATAPI and SATA optical drives being two of them, as
well as other SCSI-like add in cards where the control is
handed off to those.
This means on any system for several years time you have the
ability to boot from an optical drive, and the windows CD
follows a bootable disc spec for that. The booted windows
installation cd runs as designs and takes it from there.
After deleting the array you just have to have already
decided if you were going to install to a single drive that
was formerly in the array, if you were wanting to set up a
new array (which you may need to do BEFORE booting and
installing windows to the array) by defining it in the raid
controller bios menu (separate bios module, usually accessed
by a keystroke after main bios module has finished running
at boot-time), or if you instead wanted to install to some
other drive.
kony
<yjk...@gmail.com> wrote:
>On Jun 2, 2:59 pm, "Squeeze" <rubberd...@duckies.au> wrote:
>> Says Yousuf Khan, comp.sys.ibm.pc.hardware.storage kOOk of the year Award nominee.
>
>Squeeze, I know you enjoy proudly showing off your generally low IQ,
>but why lash out at the world due to your father ass-raping you as a
>kid?
Squeeze may not be a well behaved boy, but did we really
need to know that you sit around thinking about men
ass-raping boys?
Dan
"kony" <sp...@spam.com> wrote in message
news:51k954h31m619hb7h...@4ax.com...
Thank you for your replies. This information was exactly what I was looking
for and is very helpfull to me. Raid can be so confusing.
Thanks again,
Dan
Yousuf Khan
> I posted earlier about deleting Raid.. I will have no problem with
> reinstalling the os then Right? The Bios will allow acces to the dvd drive.
> even though I have a clean system.? I know it is a stupid question, but I
> always wondered when someone built a computer how they ever get to load the
> driver for the External drives to install the OS?
As others have said, the BIOS provides support for booting up off of
several different kinds of drives. Most will provide support for
IDE/SATA drives, as well CD/DVD-ROM drives, as well as USB-based drives
(memory sticks and hard disks). Some very specialized BIOSes will
provide RAID drive support too.
Flasherly
The cheap way is PCI support -- a couple SILICON Image 680 series
chipsets for $15 ea. delivered. Promise, KOUMTEC (sp?), ROSEWILL,
etc., whavetever your poison. Although I'm not much of a raiders fan,
and and after the option to variously run multiple HDs/DVDs, it's with
'most' DVDs there occurs something of a problem. Bus latency,
firmware, I'm not exactly sure the solution, per se -- but buying
either a PCI Serial/Parallel ATA raid/non-raid board these days, most
"imply" if not stipulate DVD channel support -- is a misnomer from
what I'm seeing. Many optical devices will balk at loading or
subsequently misfunction. I've a couple of LG DVD writers I've been
fighting a losing battle with a couple MBs and various controller (MB
+PCI) configs, and after going through discussions, I can say I'm not
the only one. Though NON-RAID appears a suggested optical
alternative, I wouldn't stake a DVD on either for surety. DVD -
issues- are a little more than just the occasional experience with
these new "subset and
cut-&-dry mini MBs" with a spare PCI slot or two, three at most.
kony
Typically with a RAID card, to support ATAPI (optical
drives) it needs to either support that with a jumper change
to non-RAID mode (no raid for anything attached) or have a
non-RAID firmware flashed to it.
Some cards, including many of the Silicon Image 0680 cards,
have a spot on the PCB for non-raid jumper, but some (most?)
have a jumper wire soldered there instead of the proper pin
header to allow jumper changes.