Yes, but those blocks in RAID 10 are largely irrelevant as they are to independant disks. In RAID 5 you have to write parity to an 'active' drive that is part of the stripe. (They are irrelevant unless of course you are maxing out your SCSI bus - yet another reason why SATA can be faster than SCSI, particularly in RAID 10, every channel is independant). Sorry - my math for RAID 5 was a bit off - I don't know why I was considering only a three dirve situation - which is the worst. It's n+1 you are right. still, for small arrays thats a big penalty. Still, there is definately a penatly contrary to the assertion of the orignal poster. I agree totally that the read+parity-calc+write in the worst case is totaly bad, which is why I alway recommend people should _never ever_ use RAID 5. In this day and age of large capacity chassis, and large capacity SATA drives, RAID 5 is totally inapropriate IMHO for _any_ application least of all databases. In reality I have yet to benchmark a system where RAID 5 on the same number of drives with 8 drives or less in a single array beat a RAID 10 with the same number of drives. I would definately be interested in a SCSI card that could actualy achieve the theoretical performance of RAID 5 especially under Linux. With RAID 5 you get to watch you system crumble and fail when a drive fails and the array goes into a failed state. It's just not worth it. Alex. On 12/26/05, David Lang <dlang@xxxxxxxxxxxx> wrote: > On Mon, 26 Dec 2005, Alex Turner wrote: > > > It's irrelavent what controller, you still have to actualy write the > > parity blocks, which slows down your write speed because you have to > > write n+n/2 blocks. instead of just n blocks making the system write > > 50% more data. > > > > RAID 5 must write 50% more data to disk therefore it will always be slower. > > raid5 writes n+1 blocks not n+n/2 (unless n=2 for a 3-disk raid). you can > have a 15+1 disk raid5 array for example > > however raid1 (and raid10) have to write 2*n blocks to disk. so if you are > talking about pure I/O needed raid5 wins hands down. (the same 16 drives > would be a 8+8 array) > > what slows down raid 5 is that to modify a block you have to read blocks > from all your drives to re-calculate the parity. this interleaving of > reads and writes when all you are logicly doing is writes can really hurt. > (this is why I asked the question that got us off on this tangent, when > doing new writes to an array you don't have to read the blocks as they are > blank, assuming your cacheing is enough so that you can write blocksize*n > before the system starts actually writing the data) > > David Lang > > > Alex. > > > > On 12/25/05, Michael Stone <mstone+postgres@xxxxxxxxx> wrote: > >> On Sat, Dec 24, 2005 at 05:45:20PM -0500, Ron wrote: > >>> Caches help, and the bigger the cache the better, but once you are > >>> doing enough writes fast enough (and that doesn't take much even with > >>> a few GBs of cache) the recalculate-checksums-and-write-new-ones > >>> overhead will decrease the write speed of real data. Bear in mind > >>> that the HD's _raw_ write speed hasn't been decreased. Those HD's > >>> are pounding away as fast as they can for you. Your _effective_ or > >>> _data level_ write speed is what decreases due to overhead. > >> > >> You're overgeneralizing. Assuming a large cache and a sequential write, > >> there's need be no penalty for raid 5. (For random writes you may > >> need to read unrelated blocks in order to calculate parity, but for > >> large sequential writes the parity blocks should all be read from > >> cache.) A modern cpu can calculate parity for raid 5 on the order of > >> gigabytes per second, and even crummy embedded processors can do > >> hundreds of megabytes per second. You may have run into some lousy > >> implementations, but you should be much more specific about what > >> hardware you're talking about instead of making sweeping > >> generalizations. > >> > >>> Side Note: people often forget the other big reason to use RAID 10 > >>> over RAID 5. RAID 5 is always only 2 HD failures from data > >>> loss. RAID 10 can lose up to 1/2 the HD's in the array w/o data loss > >>> unless you get unlucky and lose both members of a RAID 1 set. > >> > >> IOW, your RAID 10 is only 2 HD failures from data loss also. If that's > >> an issue you need to go with RAID 6 or add another disk to each mirror. > >> > >> Mike Stone > >> > >> ---------------------------(end of broadcast)--------------------------- > >> TIP 6: explain analyze is your friend > >> > > > > ---------------------------(end of broadcast)--------------------------- > > TIP 4: Have you searched our list archives? > > > > http://archives.postgresql.org > > >
