Raid 5 question...settle a bet!

[SlickVic]

Help settle a bet:beer:

We have a Compaq server that has 3 hot-swap disks with a hardware RAID 5 configuration (no hot spare) running Windows 2000 Server. Since RAID 5 requires a 3 disk minimum, I say if 1 disk fails, the server stops working.

My friend says it will keep running long enough for a replacement drive to be put in for rebuilding?

Who's right?

TIA

 

[MercenaryForHire]

Your friend. RAID 5 has the 3 disk minimum because that's the number of disks required to get redundancy. One disk can fail, and it'll go to parity-rebuild mode (slow as hell) until you replace it.

- M4H

 

[compudog]

I believe you can pull one drive out and still leave the server running until a replacement is installed, but there is a performance hit and the controller device must support this. I could be wrong, but that is the way it was explained to me.

 

[compudog]

Oops! M4H was faster!!!

 

[jose]

How much money did you just loose ? (he's right)

Regards,
Jose

 

[mcveigh]

it will stll run

 

[sharkeeper]

Help settle a bet

We have a Compaq server that has 3 hot-swap disks with a hardware RAID 5 configuration (no hot spare) running Windows 2000 Server. Since RAID 5 requires a 3 disk minimum, I say if 1 disk fails, the server stops working.

My friend says it will keep running long enough for a replacement drive to be put in for rebuilding?

Who's right?

TIA

You lose!

The HBA will set any logical drives within the array of physical drives to DEGRADED. Performance is NOT affected. (Performance IS slower during a rebuild and this can be tuned to suit needs through GAM) HOWEVER, if you lose ANOTHER disk even while the rebuild process is commencing the data is TOAST.

The 3 Disk requirement for RAID5 just means three disks are required to build a RAID5 array. You can have many more than three but the same rule always applies. (you can only lose one!)

Cheers!

 

[JustAnAverageGuy]

you're wrong.

 

[SlickVic]

Ouch..I'm taking a beating...boy, will I hear it tomorrow...I could have sworn you needed at least 3 drives, but guess I need to go re-read my books.

I lost a case of beer BTW

Thanks all

 

[Mday]

Originally posted by: SlickVic
Ouch..I'm taking a beating...boy, will I hear it tomorrow...I could have sworn you needed at least 3 drives, but guess I need to go re-read my books.

I lost a case of beer BTW

Thanks all

raid 5 requires 3 drives min. otherwise you dont have raid 5. there are 2 striped and one parity for the base case of 3 drives. you can add more parity and more striped drives as you want. obviously if the number of parity drives = the number of striped drives, you may as well run raid 10.

if you lose one drive, assuming it's a striped drive, your array is down. you can restore it by the replacing the drive, and running the restoration sequence (see the controller manual). if you lose a parity drive, your array may or may not be down depending on how your controller deals with things. but for the most part, if you lose a parity drive, your array will still be up. there are raid 5 capable systems that keep a "4th" drive around for a "3"-drive raid 5 implementation as a spare. this drive isnt used until a drive goes down. and once it goes down, that drive kicks in.

depending on how you phrased the actual bet, you may or may not lose.

 

[Cerb]

You lose. Pull one out. it will slow down, but keep on going. That's why RAID 5 takes up about 1 drive's worth of room.

 

[LordOfAll]

If raid 5 didnt work this way there is no point in having it. Raid 0 is faster all around. That is one diff, raid 5 can lose a drive and still function.

 

[Sunner]

Originally posted by: Mday

Originally posted by: SlickVic
Ouch..I'm taking a beating...boy, will I hear it tomorrow...I could have sworn you needed at least 3 drives, but guess I need to go re-read my books.

I lost a case of beer BTW

Thanks all

raid 5 requires 3 drives min. otherwise you dont have raid 5. there are 2 striped and one parity for the base case of 3 drives. you can add more parity and more striped drives as you want. obviously if the number of parity drives = the number of striped drives, you may as well run raid 10.

if you lose one drive, assuming it's a striped drive, your array is down. you can restore it by the replacing the drive, and running the restoration sequence (see the controller manual). if you lose a parity drive, your array may or may not be down depending on how your controller deals with things. but for the most part, if you lose a parity drive, your array will still be up. there are raid 5 capable systems that keep a "4th" drive around for a "3"-drive raid 5 implementation as a spare. this drive isnt used until a drive goes down. and once it goes down, that drive kicks in.

depending on how you phrased the actual bet, you may or may not lose.

Actually the parity data is split up between the drives, so it doesn't matter which one you lose, the array will remain up, albeit slower than if it were entirely intact.

 

[sharkeeper]

raid 5 requires 3 drives min. otherwise you dont have raid 5. there are 2 striped and one parity for the base case of 3 drives. you can add more parity and more striped drives as you want. obviously if the number of parity drives = the number of striped drives, you may as well run raid 10.

if you lose one drive, assuming it's a striped drive, your array is down. you can restore it by the replacing the drive, and running the restoration sequence (see the controller manual). if you lose a parity drive, your array may or may not be down depending on how your controller deals with things. but for the most part, if you lose a parity drive, your array will still be up. there are raid 5 capable systems that keep a "4th" drive around for a "3"-drive raid 5 implementation as a spare. this drive isnt used until a drive goes down. and once it goes down, that drive kicks in.

depending on how you phrased the actual bet, you may or may not lose.

What you have described is RAID3.

Actually the parity data is split up between the drives, so it doesn't matter which one you lose, the array will remain up, albeit slower than if it were entirely intact.

The penalty (in speed) only begins when the rebuild starts after the missing member is replaced with a non defunct drive or a defunct drive is forced back online via GAM. Degraded RAID5 arrays actually can run faster since the XOR engine goes idle and the parity is no longer needed.

Cheers!

 

[Sunner]

The penalty (in speed) only begins when the rebuild starts after the missing member is replaced with a non defunct drive or a defunct drive is forced back online via GAM. Degraded RAID5 arrays actually can run faster since the XOR engine goes idle and the parity is no longer needed.

Cheers!

True dat.

 

[SCSIRAID]

The penalty (in speed) only begins when the rebuild starts after the missing member is replaced with a non defunct drive or a defunct drive is forced back online via GAM. Degraded RAID5 arrays actually can run faster since the XOR engine goes idle and the parity is no longer needed

Untrue... The performance degredation occurs from the time that the drive fails until the rebuild completes. Once the array goes degraded, if the user accesses data that was on the failed drive then the xor engine is used recreate that missing data. So in the case of the three drive RAID 5 with one drive defunct, assuming random data access, one third of the read ops would require the reading of both remaining drives and then the missing data would be regenerated using the xor engine. The write penalty would be increased on writes to the missing drive since the missing data would have to be regenerated from the other two drives via the xor engine before the parity could be updated to reflect the influence of the new data. A write to data that is on one of the remaining drives still updates the parity since the parity is needed to regenerate the data when the failed drive is replaced.

 

[Scorpion]

Degraded RAID5 arrays actually can run faster since the XOR engine goes idle and the parity is no longer needed.

I don't believe this is true, as long as it wasn't the parity drive that got hosed. The XOR engine would still need to run in the case of a missing drive to determine what should have been on the other drive, based on what is on the parity drive.

Edit: Basically what SCSIRAID said right above me.

 

[Pariah]

Originally posted by: ScoRp!oN

Degraded RAID5 arrays actually can run faster since the XOR engine goes idle and the parity is no longer needed.

I don't believe this is true, as long as it wasn't the parity drive that got hosed. The XOR engine would still need to run in the case of a missing drive to determine what should have been on the other drive, based on what is on the parity drive.

Edit: Basically what SCSIRAID said right above me.

There is no parity drive in a RAID 5 array. Parity data is spread equally among all the drives in the array.

 

[sharkeeper]

I'll run some tests on a system with a 100MHz i960RN XOR PPU and see what happens when a disk is removed. (besides that really loud beeping!)

Interesting theory as several people have told me that degraded R5 arrays are read similar to R0. I guess this depends on the controller too.

Cheers!

 

[Sunner]

Originally posted by: shuttleteam
I'll run some tests on a system with a 100MHz i960RN XOR PPU and see what happens when a disk is removed. (besides that really loud beeping!)

Interesting theory as several people have told me that degraded R5 arrays are read similar to R0. I guess this depends on the controller too.

Cheers!

When you just think quickly(a tad too quickly perhaps?) that seems very reasonable.
But thinking for another minute, it's true as SCSIRAID said.
And thinking even a bit more, write performance should increase, seeing as the controller can't very well write any parity information onto a degraded array, while reads should suffer, since some data will have to be recreated from the parity data?

No?

I need a beer... :beer:

 

[gsellis]

Originally posted by: SlickVic
I lost a case of beer BTW

Thanks all

In that case, just give him one and tell him the other 23 are redundant

 

[Pariah]

And thinking even a bit more, write performance should increase, seeing as the controller can't very well write any parity information onto a degraded array, while reads should suffer, since some data will have to be recreated from the parity data?

No, because despite the missing drive, the controller has to pretend that the drive is still there for all writes so the array can be properly rebuilt when the dead drive is replaced. Data is evenly distributed among the drives in a RAID 5 array, so you can't have 50GB each on 2 drives and 30GB on the third drive. The controller has to rebuild data and parity data from the missing drive so that it can be properly updated on the remaining drives for any writes to the array.

 

[SCSIRAID]

The algorithm MUST update the parity information onto the array for the rebuild to work.... Two cases exist...

Edit: I left off the most important case of all.... 1a

Case 1... 3 drive R5. If the stripe being written to is missing a data component (because of the failed drive) but the data unit being written is on the surviving drive then the algorighm must do the following.... 1) read old data 2) xor old data with new data to determine where old data and new data differ 3) read old parity 4) xor the output from step 2 into the old parity read in step 3 5) write the outcome of step 4 to the parity stripe, 6) write the new data to the data stripe. This keeps the stripe 'in sync' so that when the replacement drive is inserted and rebuild occurs that the missing data can be regenerated. If you just write the new data and leave the parity alone... the data generated during the rebuild will be wrong.

Case 1a... 3 drive R5. If the stripe being written to is missing a data component (because of the failed drive) and the write is destined for the missing drive then the algorighm must do the following. 1) read other existing data and parity 2) xor them together to create the missing old data 3) xor the new data with the old data to find out where the data patterns differ (because this is where the parity would differ) 4) xor the result from step 3 with the old parity (to flip the parity in the places where the data patterns differ) 5) write the result from step 4 into the parity stripe. The new data which would have been written on the missing drive if it were present is now 'contained' or 'represented' indirectly in the parity information. When rebuild occurs later.. the xor of the existing data with the parity will yield the 'missing' data.

Case 2... 3 drive R5. If the stripe being written to is missing the parity component (because of the failed drive) then all you do is write the new data. This is probably where the performance improvement claim is coming from. This is only 50% of the time in writes and will be swamped out by the other penaltys due to the drive being missing.

Remember that R5 is striped parity as opposed to a dedicated parity drive. A failed drive will represent missing data in some stripes but missing parity in other stripes.

 

[Sunner]

Originally posted by: Pariah

And thinking even a bit more, write performance should increase, seeing as the controller can't very well write any parity information onto a degraded array, while reads should suffer, since some data will have to be recreated from the parity data?

No, because despite the missing drive, the controller has to pretend that the drive is still there for all writes so the array can be properly rebuilt when the dead drive is replaced. Data is evenly distributed among the drives in a RAID 5 array, so you can't have 50GB each on 2 drives and 30GB on the third drive. The controller has to rebuild data and parity data from the missing drive so that it can be properly updated on the remaining drives for any writes to the array.

Aha, I thought it did that during the rebuild(split it evenly that is).
You learn something new every day, as the saying goes