Roger, I think that' not total correct. 
The speed of raid 5 depends of several things. Two of them are how big and 
sequential that write io's are. 
There are hardware vendors that implement  raid 5 in their san very tricky:
If the incoming data are "large and sequential" they are buffered by the san 
system in write cache until a full stripe can be written to all disks in a raid 
5 group (typical 4+1). In this way a raid 5 is faster than a raid 1 since the 
write penalty is only 20% and not  50% as in raid 1.
 
hope this was clear
regards
Stefan Holzwarth  

________________________________

Von: ADSM: Dist Stor Manager im Auftrag von Roger Deschner
Gesendet: Do 20.04.2006 19:00
An: ADSM-L AT VM.MARIST DOT EDU
Betreff: Re: SAN Disk for TSM diskpool for backups ?



You will experience slower client backups with ANY configuration that is
RAID5 for your disk storage pools. The reason is that client backup is
100% writes in the disk storage pools, and RAID5 is very slow at writes.
The throughput difference is significant - as much as 75% in our case.

After much experimentation, I have found that RAID1 is best for disk
storage pools. Not RAID5, not RAID10, but RAID1. RAID5 can save you a
little bit of money in disk drives, but you really pay for it in
performance of something that is 100% writes.

Roger Deschner      University of Illinois at Chicago     rogerd AT uic DOT edu



On Wed, 19 Apr 2006, Justin Case wrote:

>Need comments please reply....
>
>We are going to be testing Apple Xserver raid disks array as the disks for
>backing up the clients nightly backups
>to diskpool. Has any one tried or even is anyone using the  Apple Xserver
>raid disks array for TSM server's diskpools
>for nightly backups ???
>
>
>What raid is being used ? We are in the mind set to use RAID5 (5+1) with 1
>spare safety net and have a spare disks on site.
>What issues have come up when using  Apple Xserver raid disks array ??
>Any experiences that other TSM Admin's have had please reply with any
>issues of success or problems ?
>
>
>Thanks
>
>Justin Case
>Duke University
>