using raid 5 with a san

Posted in 2005

Summary

Question: does a fast SAN (big cache, fibre, multiple controllers) make RAID 5 acceptable for Informix, or should RAID 1/1+0 still be used? Replies split: some said it depends on the array model and read/write mix, and that with multiple trays, large controller cache and several LUNs with dbspaces separated by usage RAID 5 can perform acceptably and saves space; others recommended RAID 1+0 with multiple slices. Art Kagel posted his standard anti-RAID5 argument (write penalty, severe degradation during rebuild, silent corruption from flaky drives since parity isn't checked on read) favouring RAID 10. No single agreed conclusion beyond the general advice to prefer RAID 10 and tune layout per workload.

Auto-generated by DrWatson from the posts below — may be imperfect; read the full thread.

Topics: Performance & Tuning

Floyd Wellershaus — Thu, 17 Feb 2005 13:11:54 — source: IIUG Forums & Mailing Lists

Hello, Here's one for you Art, ( just kidding ) anybody please. I know that raid 5 is a performance no no with Informix. However, we are getting a San. The way I understand it, this high performance San can raid and strip across disks anyway it likes, and that is totally transparent to the OS and to informix. The san with all it's dual channels, high speed fiber, super fast processors etc.. should mitigate the performance hits of raid 5. Am I correct in this assumption, or is there a reason to not use raid 5 even with a high performance San. And if so, what is the recommendation, Raid 1 ? Thanks, Floyd ======================== -<<Floyd Wellershaus>>- Database Administrator Unix Administrator email: fwellers@yahoo.com Work: 703-733-4126 Pager: 703-705-9241 Email Pager: 7037059241@my2way.com Home: 703-430-0805 Cell: 703-477-6045 ========================

↪ replying to Floyd Wellershaus

liewkn@mydbsolve.com — Thu, 17 Feb 2005 15:20:59 — source: IIUG Forums & Mailing Lists

Use RAID 1+0 with multi slice/volumn according to planned size of table(historical/transaction/static). Floyd Welle.... wrote: >Hello, >Here's one for you Art, ( just kidding ) anybody please. > >I know that raid 5 is a performance no no with Informix. However, we are getting a San. The way I understand it, this high performance San can raid and strip across disks anyway it likes, and that is totally transparent to the OS and to informix. >The san with all it's dual channels, high speed fiber, super fast processors etc.. should mitigate the performance hits of raid 5. > >Am I correct in this assumption, or is there a reason to not use raid 5 even with a high performance San. And if so, what is the recommendation, Raid 1 ? > >Thanks, >Floyd > > >======================== >-<<Floyd Wellershaus>>- >Database Administrator >Unix Administrator > >email: fwellers@yahoo.com >Work: 703-733-4126 >Pager: 703-705-9241 >Email Pager: 7037059241@my2way.com >Home: 703-430-0805 >Cell: 703-477-6045 >======================== > > > > > > > > -- DB Solve Technologies Consulting Sdn. Bhd. Liew KN _________________________________________________________________________ This e-mail and its attachments may contain DB Solve Technologies Consulting Sdn. Bhd. proprietary information that is privileged, confidential or subject to copyright belonging to DB Solve Technologies Consulting Sdn. Bhd.This e-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this e-mail, or the employee or agent responsible for delivering this e-mail to the intended recipient, you are hereby notified that any dissemination, distribution, copying or action taken in relation to the contents of and attachments to this e-mail is strictly prohibited and may be unlawful. If you have received this e-mail in error, please notify the sender immediately and permanently delete the original and any copy of this e-mail and any printout.

↪ replying to Floyd Wellershaus

ERIEZNIKR@REPSOLYPF.COM — Thu, 17 Feb 2005 16:01:01 — source: IIUG Forums & Mailing Lists

It depends on the underlying technologies... eg. HP EVA, EMC's Symettrix, older and newer models, all of them behave completely different. Some perform really good on RAID5 Is your DB write intensive or mostly read-intensive? Consider stripping with RAID1 -----Mensaje original----- De: forum.subscriber@iiug.org [mailto:forum.subscriber@iiug.org] En nombre de Floyd Welle.... Enviado el: Jueves, 17 de Febrero de 2005 10:12 a.m. Para: ids@iiug.org Asunto: using raid 5 with a san [4283] Hello, Here's one for you Art, ( just kidding ) anybody please. I know that raid 5 is a performance no no with Informix. However, we are getting a San. The way I understand it, this high performance San can raid and strip across disks anyway it likes, and that is totally transparent to the OS and to informix. The san with all it's dual channels, high speed fiber, super fast processors etc.. should mitigate the performance hits of raid 5. Am I correct in this assumption, or is there a reason to not use raid 5 even with a high performance San. And if so, what is the recommendation, Raid 1 ? Thanks, Floyd ======================== -<<Floyd Wellershaus>>- Database Administrator Unix Administrator email: fwellers@yahoo.com Work: 703-733-4126 Pager: 703-705-9241 Email Pager: 7037059241@my2way.com Home: 703-430-0805 Cell: 703-477-6045 ======================== AVISO LEGAL: Esta informacion es privada y confidencial y esta dirigida unicamente a su destinatario. Si usted no es el destinatario original de este mensaje y por este medio pudo acceder a dicha informacion por favor elimine el mensaje. La distribucion o copia de este mensaje esta estrictamente prohibida. Esta comunicacion es solo para propositos de informacion y no debe ser considerada como propuesta, aceptacion ni como una declaracion de voluntad oficial de REPSOL YPF S.A. y/o subsidiarias y/o afiliadas. La transmision de e-mails no garantiza que el correo electronico sea seguro o libre de error. Por consiguiente, no manifestamos que esta informacion sea completa o precisa. Toda informacion esta sujeta a alterarse sin previo aviso. This information is private and confidential and intended for the recipient only. If you are not the intended recipient of this message you are hereby notified that any review, dissemination, distribution or copying of this message is strictly prohibited. This communication is for information purposes only and shall not be regarded neither as a proposal, acceptance nor as a statement of will or official statement from REPSOL YPF S.A. and/or subsidiaries and/or affiliates. Email transmission cannot be guaranteed to be secure or error-free. Therefore, we do not represent that this information is complete or accurate and it should not be relied upon as such. All information is subject to change without notice.

↪ replying to liewkn@mydbsolve.com

Malcolm Perrior — Thu, 17 Feb 2005 17:12:58 — source: IIUG Forums & Mailing Lists

--- liewkn@mydbsolve.com wrote: > Use RAID 1+0 with multi slice/volumn according to > planned size of > table(historical/transaction/static). > Why? In what way is this preferable to the setup the original poster asked for comment on? (I'd like to know as well because my UNIX admin forced a RAID5 SAN upon us). Malc

↪ replying to Malcolm Perrior

kannan.thirugnanam@JTax.com — Thu, 17 Feb 2005 18:22:10 — source: IIUG Forums & Mailing Lists

--0__=0ABBE538DFF003648f9e8a93df938690918c0ABBE538DFF00364 Content-type: multipart/alternative; Boundary="1__=0ABBE538DFF003648f9e8a93df938690918c0ABBE538DFF00364" --1__=0ABBE538DFF003648f9e8a93df938690918c0ABBE538DFF00364 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable If you have multiple trays with 1GB of cache in the controllers and hav= e multiple LUNs defined, you could achieve very good performance. Space would be an advantage in RAID5 when compared to RAID1 or RAID1+0.= I am not sure about what SAN system you have/getting, but in some SANs = you could loose (one disk / tray + 1). Say if you have 6 trays in one array, you could loose 7 disks and still= be running (with some degraded performance). Configuring multiple LUNs and separating the TblSpaces(DBspaces) depend= ing on the usage, you could significantly enhance the I/Os. There is no one thumb rule to configure for all the environments. It th= e job of the DBA and System Admin to sit together and figure it out. Good Luck, Kannan Thirugnanam = "Malcolm Per...." = <malc_p@btinterne = t.com>@SMTP@Excha = To nge ids@iiug.org@SMTP@Exchange = = cc 02/17/2005 12:13 = PM Subj= ect Re: using raid 5 with a san = [4287] = = = = = = = --- liewkn@mydbsolve.com wrote: > Use RAID 1+0 with multi slice/volumn according to > planned size of > table(historical/transaction/static). > Why? In what way is this preferable to the setup the original poster asked for comment on? (I'd like to know as well because my UNIX admin forced a RAID5 SAN upon us). Malc = --1__=0ABBE538DFF003648f9e8a93df938690918c0ABBE538DFF00364 Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable <html><body> If you have multiple trays with 1GB of cache in the controllers and = have multiple LUNs defined, you could achieve very good performance. <b= r> Space would be an advantage in RAID5 when compared to RAID1 or RAID1+0.= I am not sure about what SAN system you have/getting, but in some SANs = you could loose (one disk / tray + 1). Say if you have 6 trays in one array, you could loose 7 disks and still= be running (with some degraded performance). Configuring multiple LUNs and separating the TblSpaces(DBspaces) depend= ing on the usage, you could significantly enhance the I/Os. There is no one thumb rule to configure for all the environments. It th= e job of the DBA and System Admin to sit together and figure it out.<br= > <tt>Good Luck, Kannan Thirugnanam </tt> <img src=3D"cid:10__=3D0ABBE538DFF003648f9e8a93df93869@JTax.com" width=3D= "16" height=3D"16" alt=3D"Inactive hide details for "Malcolm Per..= .." <malc_p@btinternet.com>@SMTP@Exchange">"Malcolm Per= ...." <malc_p@btinternet.com>@SMTP@Exchange <table width=3D"100%" border=3D"0" cellspacing=3D"0" cellpadding=3D"0">= <tr valign=3D"top"><td style=3D"background-image:url(cid:20__=3D0ABBE53= 8DFF003648f9e8a93df93869@JTax.com); background-repeat: no-repeat; " wid= th=3D"40%"> <ul> <ul> <ul> <ul>"Malcolm Per...." <malc_p@btintern= et.com>@SMTP@Exchange 02/17/2005 12:13 PM</ul> </ul> </ul> </ul> </td><td width=3D"60%"> <table width=3D"100%" border=3D"0" cellspacing=3D"0" cellpadding=3D"0">= <tr valign=3D"top"><td width=3D"1%" valign=3D"middle"><img src=3D"cid:3= 0__=3D0ABBE538DFF003648f9e8a93df93869@JTax.com" border=3D"0" height=3D"= 1" width=3D"58" alt=3D""> <div align=3D"right">To</div></td><td width=3D"= 100%"><img src=3D"cid:30__=3D0ABBE538DFF003648f9e8a93df93869@JTax.com" = border=3D"0" height=3D"1" width=3D"1" alt=3D""> ids@iiug.org@SMTP@Exchange</td></tr> <tr valign=3D"top"><td width=3D"1%" valign=3D"middle"><img src=3D"cid:3= 0__=3D0ABBE538DFF003648f9e8a93df93869@JTax.com" border=3D"0" height=3D"= 1" width=3D"58" alt=3D""> <div align=3D"right">cc</div></td><td width=3D"= 100%"><img src=3D"cid:30__=3D0ABBE538DFF003648f9e8a93df93869@JTax.com" = border=3D"0" height=3D"1" width=3D"1" alt=3D""> </td></tr> <tr valign=3D"top"><td width=3D"1%" valign=3D"middle"><img src=3D"cid:3= 0__=3D0ABBE538DFF003648f9e8a93df93869@JTax.com" border=3D"0" height=3D"= 1" width=3D"58" alt=3D""> <div align=3D"right">Subject</div></td><td widt= h=3D"100%"><img src=3D"cid:30__=3D0ABBE538DFF003648f9e8a93df93869@JTax.= com" border=3D"0" height=3D"1" width=3D"1" alt=3D""> Re: using raid 5 with a san [4287] </td></tr= > </table> <table border=3D"0" cellspacing=3D"0" cellpadding=3D"0"> <tr valign=3D"top"><td width=3D"58"><img src=3D"cid:30__=3D0ABBE538DFF0= 03648f9e8a93df93869@JTax.com" border=3D"0" height=3D"1" width=3D"1" alt= =3D""></td><td width=3D"336"><img src=3D"cid:30__=3D0ABBE538DFF003648f9= e8a93df93869@JTax.com" border=3D"0" height=3D"1" width=3D"1" alt=3D""><= /td></tr> </table> </td></tr> </table> --- liewkn@mydbsolve.com wrote: > Use RAID 1+0 with multi slice/volumn accordin= g to > planned size of > table(historical/transaction/static).<= br> > Why? In what way is this preferable to the setup t= he original poster asked for comment on? (I'd like to= know as well because my UNIX admin forced a RAID5 = SAN upon us). Malc </body></html>= --1__=0ABBE538DFF003648f9e8a93df938690918c0ABBE538DFF00364-- --0__=0ABBE538DFF003648f9e8a93df938690918c0ABBE538DFF00364 Content-type: image/gif; name=@@D

↪ replying to Malcolm Perrior

Lavoie, Diane — Thu, 17 Feb 2005 19:04:27 — source: IIUG Forums & Mailing Lists

I am interested to know too, my UNIX admin forced Raid5 SAN too. -----Original Message----- From: Malcolm Per.... [mailto:malc_p@btinternet.com] Sent: Thursday, February 17, 2005 12:13 PM To: ids@iiug.org Subject: Re: using raid 5 with a san [4287] --- liewkn@mydbsolve.com wrote: > Use RAID 1+0 with multi slice/volumn according to planned size of > table(historical/transaction/static). > Why? In what way is this preferable to the setup the original poster asked for comment on? (I'd like to know as well because my UNIX admin forced a RAID5 SAN upon us). Malc

↪ replying to Malcolm Perrior

ART KAGEL, BLOOMBERG/ — Thu, 17 Feb 2005 21:17:56 — source: IIUG Forums & Mailing Lists

OK, here's my quarterly NO RAID5 Rant, which explains why I oppose RAID5 altogether and especially for Informix databases. If you need more ammo against the pointy of hair, see the BAARF web site, there are articles from well respected Oracle folk, in addition to my posting, there for you to see and use. (www.baarf.com). Art S. Kagel RAID5 versus RAID10 (or even RAID3 or RAID4) What is RAID5? OK here is the deal, RAID5 uses ONLY ONE parity drive per stripe and many RAID5 arrays are 5 (if your counts are different adjust the calculations appropriately) drives (4 data and 1 parity though it is not a single drive that is holding all of the parity as in RAID 3 & 4 but read on). If you have 10 drives or say 20GB each for 200GB RAID5 will use 20% for parity so you will have 160GB of storage. Now since RAID10, like mirroring (RAID1), uses 1 (or more) mirror drive for each primary drive you areusing 50% for redundancy so to get the same 160GB of storage you will need 8 pairs or 16 - 20GB drives, which is why RAID5 is so popular. This intro is just to put things into perspective. RAID5 is physically a stripe set like RAID0 but with data recovery included. RAID5 reserves one disk block out of each stripe block for parity data. The parity block contains an error correction code which can correct any error in the RAID5 block, in effect it is used in combination with the remaining data blocks to recreate any single missing block, gone missing because a drive has failed. The innovation of RAID5 over RAID3 & RAID4 is that the parity is distributed on a round robin basis so that there can be independent reading of different blocks from the several drives. This is why RAID5 became more popular than RAID3 & RAID4 which must sychronously read the same block from all drives together. So, if Drive2 fails blocks 1,2,4,5,6 &7 are data blocks on this drive and blocks 3 and 8 are parity blocks on this drive. So that means that the parity on Drive5 will be used to recreate the data block from Disk2 if block 1 is requested before a new drive replaces Drive2 or during the rebuilding of the new Drive2 replacement. Likewise the parity on Drive1 will be used to repair block 2 and the parity on Drive3 will repair block4, etc. For block 2 all the data is safely on the remaining drives but during the rebuilding of Drive2's replacement a new parity block will be calculated from the block 2 data and will be written to Drive 2. Now when a disk block is read from the array the RAID software/firmware calculates which RAID block contains the disk block, which drive the disk block is on and which drive contains the parity block for that RAID block and reads ONLY the data drive. It returns the data block . If you later modify the data block it recalculates the parity by subtracting the old block and adding in the new version then in two separate operations it writes the data block followed by the new parity block. To do this it must first read the parity block from whichever drive contains the parity for that stripe block and reread the unmodified data for the updated block from the original drive. This read-read-write-write is known as the RAID5 write penalty since these two writes are sequential and synchronous the write system call cannot return until the reread and both writes complete, for safety, so writing to RAID5 is up to 50% slower than RAID0 for an array of the same capacity. Now what is RAID10: RAID10 is one of the combinations of RAID1 (mirroring) and RAID0 (striping) which are possible. There used to be confusion about what RAID01 or RAID01 meant and different RAID vendors defined them differently. About five years or so ago I proposed the following standard language which seems to have taken hold. When N mirrored pairs are striped together this is called RAID10 because the mirroring (RAID1) is applied before striping (RAID0). The other option is to create two stripe sets and mirror them one to the other, this is known as RAID01 (because the RAID0 is applied first). In either a RAID01 or RAID10 system each and every disk block is completely duplicated on its drive's mirror. Performance-wise both RAID01 and RAID10 are functionally equivalent. The difference comes in during recovery where RAID01 suffers from some of the same problems I will describe affecting RAID5 while RAID10 does not. Now if a drive in the RAID5 array dies, is removed, or is shut off data is returned by reading the blocks from the remaining drives and calculating the missing data using the parity, assuming the defunct drive is not the parity block drive for that RAID block. Note that it takes 4 physical reads to replace the missing disk block (for a 5 drive array) for four out of every five disk blocks leading to a 64% performance degradation until the problem is discovered and a new drive can be mapped in to begin recovery. If a drive in the RAID10 array dies data is returned from its mirror drive in a single read with only minor (6.25% on average) performance reduction when two non-contiguous blocks are needed from the damaged pair and none otherwise. One begins to get an inkling of what is going on and why I dislike RAID5, but there's more. What's wrong besides a bit of performance I don't know I'm missing? OK, so that brings us to the final question of the day which is: What is the problem with RAID5? It does recover a failed drive right? So writes are slower, I don't do enough writing to worry about it and the cache helps a lot also, I've got LOTS of cache! The problem is that despite the improved reliability of modern drives and the improved error correction codes on most drives, and even despite the additional 8 bytes of error correction that EMC puts on every Clariion drive disk block (if you are lucky enough to use EMC systems), it is more than a little possible that a drive will become flaky and begin to return garbage. This is known as partial media failure. Now SCSI controllers reserve several hundred disk blocks to be remapped to replace fading sectors with unused ones, but if the drive is going these will not last very long and will run out and SCSI does NOT report correctable errors back to the OS! Therefore you will not know the drive is becoming unstable until it is too late and there are no more replacement sectors and the drive begins to return garbage. [Note that the recently popular ATA drives do not (TMK) include bad sector remapping in their hardware so garbage is returned that much sooner.] When a drive returns garbage, since RAID5 does not EVER check parity on read (RAID3 & RAID4 do BTW and both perform better for databases than RAID5 to boot) when you write the garbage sector back garbage parity will be calculated and your RAID5 integrity is lost! Similarly if a drive fails and one of the remaining drives is flaky the replacement will be rebuilt with garbage also. Need more? During recovery, read performance for a RAID5 array is degraded by as much as 80%. Some advanced arrays let you configure the preference more toward recovery or toward performance. However, doing so will increase recovery time and increase the likelihood of losing a second drive in the array before recovery completes resulting in catastrophic data loss. RAID10 on the other hand will only be recovering

↪ replying to ART KAGEL, BLOOMBERG/

liewkn@mydbsolve.com — Fri, 18 Feb 2005 00:21:07 — source: IIUG Forums & Mailing Lists

Thanks Art Kagel ART KAGEL, .... wrote: >OK, here's my quarterly NO RAID5 Rant, which explains why I oppose RAID5 >altogether and especially for Informix databases. If you need more ammo against > the pointy of hair, see the BAARF web site, there are articles from well >respected Oracle folk, in addition to my posting, there for you to see and use. >(www.baarf.com). > >Art S. Kagel > >RAID5 versus RAID10 (or even RAID3 or RAID4) > >What is RAID5? > >OK here is the deal, RAID5 uses ONLY ONE parity drive per stripe and many >RAID5 arrays are 5 (if your counts are different adjust the calculations >appropriately) drives (4 data and 1 parity though it is not a single >drive that is holding all of the parity as in RAID 3 & 4 but read on). If >you have 10 drives or say 20GB each for 200GB RAID5 will use 20% for >parity so you will have 160GB of storage. Now since RAID10, like >mirroring (RAID1), uses 1 (or more) mirror drive for each primary drive >you areusing 50% for redundancy so to get the same 160GB of storage you >will need 8 pairs or 16 - 20GB drives, which is why RAID5 is so popular. >This intro is just to put things into perspective. > >RAID5 is physically a stripe set like RAID0 but with data recovery >included. RAID5 reserves one disk block out of each stripe block for >parity data. The parity block contains an error correction code which can >correct any error in the RAID5 block, in effect it is used in combination >with the remaining data blocks to recreate any single missing block, gone >missing because a drive has failed. The innovation of RAID5 over RAID3 & >RAID4 is that the parity is distributed on a round robin basis so that >there can be independent reading of different blocks from the several >drives. This is why RAID5 became more popular than RAID3 & RAID4 which >must sychronously read the same block from all drives together. So, if >Drive2 fails blocks 1,2,4,5,6 &7 are data blocks on this drive and blocks >3 and 8 are parity blocks on this drive. So that means that the parity on >Drive5 will be used to recreate the data block from Disk2 if block 1 is >requested before a new drive replaces Drive2 or during the rebuilding of >the new Drive2 replacement. Likewise the parity on Drive1 will be used to >repair block 2 and the parity on Drive3 will repair block4, etc. For >block 2 all the data is safely on the remaining drives but during the >rebuilding of Drive2's replacement a new parity block will be calculated >from the block 2 data and will be written to Drive 2. > >Now when a disk block is read from the array the RAID software/firmware >calculates which RAID block contains the disk block, which drive the disk >block is on and which drive contains the parity block for that RAID block >and reads ONLY the data drive. It returns the data block . If you later >modify the data block it recalculates the parity by subtracting the old >block and adding in the new version then in two separate operations it >writes the data block followed by the new parity block. To do this it >must first read the parity block from whichever drive contains the parity >for that stripe block and reread the unmodified data for the updated block >from the original drive. This read-read-write-write is known as the RAID5 >write penalty since these two writes are sequential and synchronous the >write system call cannot return until the reread and both writes complete, >for safety, so writing to RAID5 is up to 50% slower than RAID0 for an >array of the same capacity. > >Now what is RAID10: > >RAID10 is one of the combinations of RAID1 (mirroring) and RAID0 >(striping) which are possible. There used to be confusion about what >RAID01 or RAID01 meant and different RAID vendors defined them differently. >About five years or so ago I proposed the following standard language which >seems to have taken hold. When N mirrored pairs are striped together >this is called RAID10 because the mirroring (RAID1) is applied before >striping (RAID0). The other option is to create two stripe sets and mirror >them one to the other, this is known as RAID01 (because the RAID0 is applied >first). In either a RAID01 or RAID10 system each and every disk block is >completely duplicated on its drive's mirror. Performance-wise both RAID01 >and RAID10 are functionally equivalent. The difference comes in during >recovery where RAID01 suffers from some of the same problems I will describe >affecting RAID5 while RAID10 does not. > >Now if a drive in the RAID5 array dies, is removed, or is shut off data is >returned by reading the blocks from the remaining drives and calculating >the missing data using the parity, assuming the defunct drive is not the >parity block drive for that RAID block. Note that it takes 4 physical >reads to replace the missing disk block (for a 5 drive array) for four out >of every five disk blocks leading to a 64% performance degradation until the >problem is discovered and a new drive can be mapped in to begin recovery. > >If a drive in the RAID10 array dies data is returned from its mirror drive >in a single read with only minor (6.25% on average) performance reduction >when two non-contiguous blocks are needed from the damaged pair and none >otherwise. > >One begins to get an inkling of what is going on and why I dislike RAID5, >but there's more. > >What's wrong besides a bit of performance I don't know I'm missing? > >OK, so that brings us to the final question of the day which is: What is >the problem with RAID5? It does recover a failed drive right? So writes >are slower, I don't do enough writing to worry about it and the cache >helps a lot also, I've got LOTS of cache! The problem is that despite the >improved reliability of modern drives and the improved error correction >codes on most drives, and even despite the additional 8 bytes of error >correction that EMC puts on every Clariion drive disk block (if you are >lucky enough to use EMC systems), it is more than a little possible that >a drive will become flaky and begin to return garbage. This is known as >partial media failure. Now SCSI controllers reserve several hundred disk >blocks to be remapped to replace fading sectors with unused ones, but if >the drive is going these will not last very long and will run out and SCSI >does NOT report correctable errors back to the OS! Therefore you will not >know the drive is becoming unstable until it is too late and there are no >more replacement sectors and the drive begins to return garbage. [Note >that the recently popular ATA drives do not (TMK) include bad sector >remapping in their hardware so garbage is returned that much sooner.] >When a drive returns garbage, since RAID5 does not EVER check parity on >read (RAID3 & RAID4 do BTW and both perform better for databases than >RAID5 to boot) when you write the garbage sector back garbage parity will >be calculated and your RAID5 integrity is lost! Similarly if a drive >fails and one of the remaining drives is flaky the replacement will be >rebuilt with garbage also. > >Need more? During recovery, read performance for a RAID5 array is degraded >by as much as 80%. Some advanced arrays let you configure the preference >more toward recovery or toward performance. However, doing so will >increase recovery time