RAID newbie...can I have several partitions on a RAID 1 array?

[Ian R]

Hi

I'm thinking of setting up a RAID 1 array with two 250GB Drives (7K250
SATAII )

This is my first venture into RAID so I have a few newbie questions...

Can I split the drive into several partitions or does it have to remain as a
single partition?

If I can, will most software partition managers (PQ Partition Magic,
Acronis, Ghost) cope with RAID or do I need a special partition manager? Can
you recommend one?

As far as my software is concerned I presume they ignore the RAID aspect and
just see it as a normal single drive?

Just in case your were wondering... I am aware that RAID 1 is a mirrored
array. I'll be using the Sil 3114 RAID controller on my ASUS A8N-SLI Premium
Mobo.

Thanks for your time and any info.

Ian.

 

[Arno Wagner]

Hi

I'm thinking of setting up a RAID 1 array with two 250GB Drives (7K250
SATAII )

This is my first venture into RAID so I have a few newbie questions...

Can I split the drive into several partitions or does it have to remain as a
single partition?

You can partition the RAID array. With most hardware-RAID set-ups you
cannot form the ARRAY from partitions, but juts whole disks.

If I can, will most software partition managers (PQ Partition Magic,
Acronis, Ghost) cope with RAID or do I need a special partition manager? Can
you recommend one?

Should work.

As far as my software is concerned I presume they ignore the RAID
aspect and just see it as a normal single drive?
Yes.

Just in case your were wondering... I am aware that RAID 1 is a
mirrored array. I'll be using the Sil 3114 RAID controller on my
ASUS A8N-SLI Premium Mobo.

One thing: For true redundancy, you need a spare controller. There is
software to reconstruct RAID data from the disks only, but (AFAIK) it
costs money and you need another disk. Hardware RAID 1 does not
protect you from controller failure and usually the disk layout is
specifically designed so that you cannot access the individual drives
without the controller. The only reason for this is to force you to
buy a new controller from the same company (i.e. corporate greed) as
you used to create the array. That it is possible to do this
differently is demonstrated by Linux software RAID 1: It places the
RAID descriptor at the end of the disk and you can access each disk
without RAID directly. Hardware controllers usually place the
descriptor at the beginning of the disk to prevent use of the
disk without controller.

Arno

 

[Bob Willard]

You can partition the RAID array. With most hardware-RAID set-ups you
cannot form the ARRAY from partitions, but juts whole disks.




Should work.




One thing: For true redundancy, you need a spare controller. There is
software to reconstruct RAID data from the disks only, but (AFAIK) it
costs money and you need another disk. Hardware RAID 1 does not
protect you from controller failure and usually the disk layout is
specifically designed so that you cannot access the individual drives
without the controller. The only reason for this is to force you to
buy a new controller from the same company (i.e. corporate greed) as
you used to create the array. That it is possible to do this
differently is demonstrated by Linux software RAID 1: It places the
RAID descriptor at the end of the disk and you can access each disk
without RAID directly. Hardware controllers usually place the
descriptor at the beginning of the disk to prevent use of the
disk without controller.

Arno

I don't disagree with Arno at all: as he kinda said, for true
*hardware* redundancy, you need *at least* a spare controller.
But even total hardware redundancy does not supply any protection
against bad software (e.g., Windows) or against funble-fingers.

My conclusion: RAID is nice, but backup is essential.

 

[Arno Wagner]

Arno Wagner wrote:

I don't disagree with Arno at all: as he kinda said, for true
*hardware* redundancy, you need *at least* a spare controller.
But even total hardware redundancy does not supply any protection
against bad software (e.g., Windows) or against funble-fingers.

My conclusion: RAID is nice, but backup is essential.

Indeed. You are entirely correct of course. With current backup
you can do away with the spare controller. I am getting so used to
people here running without backup, that I start to overlook
the obvious. Thanks for reminding me!

As Bob says, RAID only protects from hardware problems, so it only
fills part of the things a backup does. Essentially RAID is a
''hassle reducer'': It decreases the probability that you need
to restore your backup.

Arno

 

[Curious George]

"at least" is the key phrase. Adding a second controller and array
means that the host computer is now a single point of failure instead
of the DAS as well. That may be OK but the real goal is redundancy
that is appropriate to the situaion/applicaion. IMHO In a lot of
cases with modern HW the old online second controller concept is a
waste that well exceeds the point of diminishing returns. IMHO it is
more common for either simpler DAS or larger cluster other
multi-computer system to make more sense. YMMV. Of course I'm
talking live HW, not spares. You may disagree but the key is there is
no definitive best protection via redundancy on a small scale- it all
depends.

Indeed. You are entirely correct of course. With current backup
you can do away with the spare controller. I am getting so used to

Often, especially with desktops like the OP has.

But without raid the whole system or volume goes down during a repair
and restore when there is hardware failure/decommission or certain
kinds of storage upgrades. Sometimes that isn't acceptable so the
argument for raid in those cases goes beyond the protection mechanism.

Also there are some RAID implementations that can assist is resisting
data loss/corruption due to failing/marginal media. Backup and manual
intervention does not address that particularly well.

Of course the OP is talking about entry level PC desktop RAID 1. But
there are also theoretical performance benefits in better
implementations as well as some other levels which are used to boost
storage speeds. In those cases, of course. the presence of a current
backup is quite irrelevant to the argument for raid.

people here running without backup, that I start to overlook
the obvious. Thanks for reminding me!

As Bob says, RAID only protects from hardware problems, so it only
fills part of the things a backup does. Essentially RAID is a
''hassle reducer'': It decreases the probability that you need
to restore your backup.

I agree with this point. But I'd add the caveat that entry level
desktop RAID like the OP's is not 100% foolproof automatic protection
against any & every kind of failure or failing media. So your careful
wording which includes "hassle reducer" and "decreases" is quite
appropriate IMO. Perhaps I'd add the word "potential" to "hassle
reducer." But that's me

 

[Arno Wagner]

"at least" is the key phrase. Adding a second controller and array
means that the host computer is now a single point of failure instead
of the DAS as well. That may be OK but the real goal is redundancy
that is appropriate to the situaion/applicaion. IMHO In a lot of
cases with modern HW the old online second controller concept is a
waste that well exceeds the point of diminishing returns. IMHO it is
more common for either simpler DAS or larger cluster other
multi-computer system to make more sense. YMMV. Of course I'm
talking live HW, not spares. You may disagree but the key is there is
no definitive best protection via redundancy on a small scale- it all
depends.

You did get that we were talking about a cold spare and no second
array was ever mentioned?

Often, especially with desktops like the OP has.

But without raid the whole system or volume goes down during a repair
and restore when there is hardware failure/decommission or certain
kinds of storage upgrades. Sometimes that isn't acceptable so the
argument for raid in those cases goes beyond the protection mechanism.

Also there are some RAID implementations that can assist is resisting
data loss/corruption due to failing/marginal media. Backup and manual
intervention does not address that particularly well.

Of course the OP is talking about entry level PC desktop RAID 1.

Indeed. BIOS level at that. See above.

But
there are also theoretical performance benefits in better
implementations as well as some other levels which are used to boost
storage speeds. In those cases, of course. the presence of a current
backup is quite irrelevant to the argument for raid.

I agree with this point. But I'd add the caveat that entry level
desktop RAID like the OP's is not 100% foolproof automatic protection
against any & every kind of failure or failing media. So your careful
wording which includes "hassle reducer" and "decreases" is quite
appropriate IMO. Perhaps I'd add the word "potential" to "hassle
reducer." But that's me

Well, I personally have experienced hassle reduction from RAID1
and RAID5, so I feel entitled to not add "potential". You are
free to do so of course ;-)

Arno

 

[Folkert Rienstra]

"at least" is the key phrase. Adding a second controller and array
means that the host computer is now a single point of failure instead
of the DAS as well.

That was my first take as well.
I think he meant the restore/recovery part of a breakdown, ie not being
able to simply hang it on any other controller and be going again if the
controller fails.

That may be OK but the real goal is redundancy that is appropriate to
the situation/application. IMHO In a lot of cases with modern HW the
old online second controller concept is a waste that well exceeds the
point of diminishing returns. IMHO it is more common for either simpler
DAS or larger cluster other multi-computer system to make more sense.
YMMV.

Of course I'm talking live HW, not spares.

He was.

You may disagree but the key is there is no definitive best protection via
redundancy on a small scale- it all depends.

Redundancy as in 'non-interrupted'. Having a spare is not really redundant.

But still need an extra drive of nearly the size of the array (except R0)
in case of a controller failure.

Often, especially with desktops like the OP has.

But without raid the whole system or volume goes down during a repair
and restore when there is hardware failure/decommission or certain
kinds of storage upgrades. Sometimes that isn't acceptable so the
argument for raid in those cases goes beyond the protection mechanism.

I tend to think that that is the same thing, they come together:
because it doesn't (logically) break you don't loose any up-time.

Also there are some RAID implementations that can assist is resisting
data loss/corruption due to failing/marginal media.

Backup and manual intervention does not address that particularly well.

I fail to see the point re backup.
Presumably you mean that it helps in preventing from having to use your
backup, even assuming that the lost data was actually already backed up.

Of course the OP is talking about entry level PC desktop RAID 1.
But there are also theoretical performance benefits in better
implementations as well as some other levels which are used to boost
storage speeds. In those cases, of course. the presence of a current
backup is quite irrelevant to the argument for raid.

Hallmark of the babblebot:
the need to babble, short attention span, no time
to think things through, know everything already.

As I constantly do, you're welcome (to go away too).

It decreases the probability that you need to restore your backup.

That is IF the rebuild goes according to plan. That can be quite a "hassle".

 

[Curious George]

I fail to see the point re backup.
Presumably you mean that it helps in preventing from having to use your
backup, even assuming that the lost data was actually already backed up.

If there is corruption or data loss due to failing/damaged/marginal
media that can be a hassle to correct via backup and manual
intervention. That is because if things have reached that point the
entire array's data is suspect. One either needs to launch an
investigation and restore individual affected files or take the
machine down and rollback.

With an unintelligent or improperly maintained/configured array that
corruption will propagate. But in an ideal raid scenario these
problems are corrected/compensated for either on the fly or as part of
regular automated maintenance.

 

[Curious George]

You did get that we were talking about a cold spare and no second
array was ever mentioned?

The problem is if a phrase like "true redundancy" is going to be used
with "second controller" that implies a failover or duplexing
scenario. A cold spare is exactly that. It is "redundant" in only
the loosest of definitions.

Well, I personally have experienced hassle reduction from RAID1
and RAID5, so I feel entitled to not add "potential". You are
free to do so of course ;-)

Things have to fail and rebuild just right. The statistical success
or failure depends on a number of variables

 

[Arno Wagner]

On 13 Sep 2006 13:23:28 GMT, Arno Wagner <[email protected]> wrote:

The problem is if a phrase like "true redundancy" is going to be used
with "second controller" that implies a failover or duplexing
scenario. A cold spare is exactly that. It is "redundant" in only
the loosest of definitions.

It is offline redundandcy, i.e. requires manual intervention and
will do less for reducing downtime. But it is redundancy. There
are solutions with different characteristics for this problem.

Arno

 

[SA]

Can I split the drive into several partitions or does it have to remain as
a
single partition?

Yes, you can make as many partitions as supported by the OS.

If I can, will most software partition managers (PQ Partition Magic,
Acronis, Ghost) cope with RAID or do I need a special partition manager?
Can you recommend one?

You can simply manage it with Windows. No extra software required.

As far as my software is concerned I presume they ignore the RAID aspect
and just see it as a normal single drive?

Correct

 

[Curious George]

It is offline redundandcy, i.e. requires manual intervention and
will do less for reducing downtime. But it is redundancy. There
are solutions with different characteristics for this problem.

I'm afraid it's no more redundancy than running out the same day and
buying a replacement from a store or filing a warranty claim when you
have same or next day service.

You hold spares because you anticipate failure after the unit is hard
to replace, or downtime is so critical that it isn't cost effective or
realistic to wait for service. It's neither the first thing one
thinks of when discussing "redundancy" nor is it the first thing one
recommends to a typical desktop user with RAID 1 on the cheap (for a
number of reasons).

Yes you have more than 1 unit. But "true redundancy"? Definitely
not. "Necessary" redundancy? Not clear cut in the OP's case IMHO.

 

[Arno Wagner]

It is offline redundandcy, i.e. requires manual intervention and
will do less for reducing downtime. But it is redundancy. There
are solutions with different characteristics for this problem.

[/QUOTE]

I'm afraid it's no more redundancy than running out the same day and
buying a replacement from a store or filing a warranty claim when you
have same or next day service.

It is. You can react faster. And do you know the spare will
be in stock or on the market anymore? No. Your cold spare
is available and available relatively fast.

You hold spares because you anticipate failure after the unit is hard
to replace, or downtime is so critical that it isn't cost effective or
realistic to wait for service.

Also you hold spares to reduce replacement effort and operating
time in degraded state. At least I do.

It's neither the first thing one
thinks of when discussing "redundancy" nor is it the first thing one
recommends to a typical desktop user with RAID 1 on the cheap (for a
number of reasons).

That is your opinion. Mine is different.

Yes you have more than 1 unit. But "true redundancy"? Definitely
not. "Necessary" redundancy? Not clear cut in the OP's case IMHO.

Very clear actually. If the OB as a "RAID newbe" has a controller
failure, the only low effort data recovery approach open to him is
to have an identical or compatible spare controller.

Redundancy does not necessarily mean it will continue to operate.
It can also mean it is easier to repair. Depends on the sutuation.
For the OP it means that with a hardware failure, he can still
get at his data. And from the number of postings I have seen here
from people that had a controller failure and could not get at
their data, I think it is a real issue.

And BTW, "true redundancy" just means redundancy for all
essential components, which included the controller. It does
not mean that it has to be "online redundancy".

Arno

 

[Gerhard Fiedler]

You hold spares because you anticipate failure after the unit is hard
to replace, or downtime is so critical that it isn't cost effective or
realistic to wait for service. It's neither the first thing one
thinks of when discussing "redundancy"

E.g. http://en.wikipedia.org/wiki/Redundancy_(engineering):

"In engineering, the duplication of critical components of a system with
the intention of increasing reliability of the system, usually in the case
of a backup or fail-safe, is called redundancy."

"Duplication of critical components" in the form of cold spares on-site
usually reduces downtime, which increases the average availability.
Increased average availability means increased system reliability. Which
seems to mean that this falls within "redundancy".

Most cars have a redundant 5th wheel as "cold spare".

Gerhard

 

[Arno Wagner]

Curious George wrote:

E.g. http://en.wikipedia.org/wiki/Redundancy_(engineering):

"In engineering, the duplication of critical components of a system with
the intention of increasing reliability of the system, usually in the case
of a backup or fail-safe, is called redundancy."

"Duplication of critical components" in the form of cold spares on-site
usually reduces downtime, which increases the average availability.
Increased average availability means increased system reliability. Which
seems to mean that this falls within "redundancy".

Most cars have a redundant 5th wheel as "cold spare".

Good example!

Arno

 

[Curious George]

Good example!

Indeed. As spare tires are never referred to as "redundant tires" or
"true redundancy." They are "spares."

Now if someone only drove between their home and a store 3 blocks
away, but insisted on having 8 wheels instead of 4 as part of some
redundant system like some trucks, would you make a big deal about him
traveling with spares?

Yes you have more than 1 unit and it is therefore redundant. But
"true redundancy"? In the normal nomenclature of RAID? Definitely
not. "Necessary" redundancy? Not clear cut in the OP's case IMHO.

 

[Folkert Rienstra]

With this type of stretching you can change any definition into another one.


Which isn't worth a damn if the axle broke.

Good example!

Clueless as always.

 

[Curious George]

It is. You can react faster. And do you know the spare will
be in stock or on the market anymore? No. Your cold spare
is available and available relatively fast.


Also you hold spares to reduce replacement effort and operating
time in degraded state. At least I do.


That is your opinion. Mine is different.


Very clear actually. If the OB as a "RAID newbe" has a controller
failure, the only low effort data recovery approach open to him is
to have an identical or compatible spare controller.

Not clear actually. Because the likelihood of having premature
controller failure on half decent controllers is quite low with
instead SATA Disk abberations much more likely. Rather than spending
double on a cheap controller, there is often more benefit to simply
having a better controller and up to date backups and maintenance
routines. In fact software raid, like what you use, is extremely
attractive compared to low-end controllers. In that case neither RAID
controller or cold spare are necessary.

Furthermore the possibility of such a catastrophe may also call into
question the preference for a single raided system (which the newbie
might have unrealistic expectations about) vs. critical data being
duplicated on a second online machine or appliance. There are many
factors that go into making such a decision, how it is set up, and
therefore where one's focus belongs.

Redundancy does not necessarily mean it will continue to operate.
It can also mean it is easier to repair. Depends on the sutuation.
For the OP it means that with a hardware failure, he can still
get at his data. And from the number of postings I have seen here
from people that had a controller failure and could not get at
their data, I think it is a real issue.

Fraid it also brings up multiple other issues like overconfidence, bad
hardware choice, broken or inappropriate backup system, lack of
hardware reporting or maintenance, etc. as well.

And BTW, "true redundancy" just means redundancy for all
essential components, which included the controller. It does
not mean that it has to be "online redundancy".

Thanks. Now I don't have to look it up in the Arno dictionary.

 

[Curious George]

With this type of stretching you can change any definition into another one.



Which isn't worth a damn if the axle broke.

Everybody knows you should always carry a spare (I mean redundant)
axle for "true redundancy."

 

[Arno Wagner]

It is. You can react faster. And do you know the spare will
be in stock or on the market anymore? No. Your cold spare
is available and available relatively fast.


Also you hold spares to reduce replacement effort and operating
time in degraded state. At least I do.


That is your opinion. Mine is different.


Very clear actually. If the OB as a "RAID newbe" has a controller
failure, the only low effort data recovery approach open to him is
to have an identical or compatible spare controller.

[/QUOTE]

Not clear actually. Because the likelihood of having premature
controller failure on half decent controllers is quite low with
instead SATA Disk abberations much more likely. Rather than spending
double on a cheap controller, there is often more benefit to simply
having a better controller and up to date backups and maintenance
routines. In fact software raid, like what you use, is extremely
attractive compared to low-end controllers. In that case neither RAID
controller or cold spare are necessary.

Furthermore the possibility of such a catastrophe may also call into
question the preference for a single raided system (which the newbie
might have unrealistic expectations about) vs. critical data being
duplicated on a second online machine or appliance. There are many
factors that go into making such a decision, how it is set up, and
therefore where one's focus belongs.

Fraid it also brings up multiple other issues like overconfidence, bad
hardware choice, broken or inappropriate backup system, lack of
hardware reporting or maintenance, etc. as well.

Thanks. Now I don't have to look it up in the Arno dictionary.

If you want an answer, do away with the clever insults....

Arno