Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!gem.mps.ohio-state.edu!apple!apple.com!desnoyer
From: desnoyer@apple.com (Peter Desnoyers)
Newsgroups: comp.arch
Subject: Re: Slow SCSI
Message-ID: <5375@internal.Apple.COM>
Date: 22 Nov 89 21:21:59 GMT
Sender: usenet@Apple.COM
Organization: Apple Computer, Inc.
Lines: 28
References:<35985@ames.arc.nasa.gov> <18292@watdragon.waterloo.edu> <48398@leo.UUCP> <15249@haddock.ima.isc.com>

In article <15249@haddock.ima.isc.com> news@haddock.ima.isc.com (overhead) 
writes:
> >In article <18292@watdragon.waterloo.edu>, ccplumb@rose.waterloo.edu (
> >Colin Plumb) writes:
> >> Arrays of cheap disks is one nice idea, like the CM's data vault.
> >> Want 100 MB/sec?  Get 100 SCSI drives and run them in parallel.
> >
> >Sounds great! But what do I do when one of these inexpensive drives breaks
> >and how do I go about backing up 100 SCSI drives (~70MB of data)?
> 
> Let's say you have 32 drives providing data.  Some number of
> additional drives run in parallel for ECC correction.  There
> might be 48 drives total, providing 2 bit correction.  Thus for
> any 32 bit word - 2 bits could be wrong and yet still be reliably
> computable from the total data.  

You can get even better performance by relying on the fact that hard 
errors are erasure errors rather than random errors - i.e. the disk tells 
you that it can't read the data, instead of silently corrupting it. For 
instance, you can correct all 1-bit errors with a single parity bit. 

You still need a backup system - for instance, to recover from a fire.
However, that is a problem no matter how you go about creating 
a gigabyte file system. 

                                      Peter Desnoyers
                                      Apple ATG
                                      (408) 974-4469