RAID? Was: PATA hard disks, anyone?

[Paul Berger]

On 2018-03-27 10:05 PM, Ali via cctalk wrote:
>      
>
>
> -------- Original message --------
> From: Fred Cisin via cctalk <cctalk at classiccmp.org>
> Date: 3/27/18  5:51 PM  (GMT-08:00)
> To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org>
> Subject: RAID?  Was: PATA hard disks, anyone?
>
> How many drives would you need, to be able to set up a RAID, or hot
> swappable RAUD (Redundant Array of Unreliable Drives), that could give
> decent reliability with such drives?
> 10 -
> Two sets of 5 drive  RAID 6 volumes in a RAID 1 array.
> You would then need to lose 5 drives before data failure is imminent. The 6th one will do you in. If you haven't fixed 50 percent failure then you deserve to lose your data.
> Disclaimer: this is my totally unscientific unprofessional and biased estimate. My daily activities of life have nothing to do with the IT industry. Proceed at your own peril. Etc. Etc.
> -Ali
>
>
To meet Fred's original criteria you would only need 4 to create a 
minimal RAID 6 array.  In theory a RAID 1 array (mirrored) of 4 or more 
disk could also survive a second disk failure as long as one copy of all 
the pairs in the array survive but you are starting to play the odds, 
and I know of some cases where people have lost . You can improve the 
odds by having a hot spare that automatically take over for a failed 
disk.  One of  the most important things is the array manager has to 
have some way of notifying you that there has been a failure so that you 
can take action, however my observations as a hardware support person is 
that even when there is error notification it is often missed or ignored 
until subsequent failures kill off the array.   It also appears to be a 
fairly common notion that if you have RAID there is no need to ever 
backup, but I assure you RAID is not foolproof and arrays do fail.   One 
of the big problems facing using large disks to build arrays is the 
number of accesses just to build the array may put a serious dent in the 
speced number of accesses before error or in some cases even exceed it.

Paul.