[LAU] RAID and AVLinux

[Arnold Krille]

Hi,

On Monday 12 October 2009 19:44:47 Jörn Nettingsmeier wrote:
> Arnold Krille wrote:
> > Unless I miss something on AVLinux:
> > On Saturday 03 October 2009 21:36:54 Jörn Nettingsmeier wrote:
> >> Jonathan E. Brickman wrote:
> >>>>  You should at least use RAID6.
> >>> 1.  How does RAID6 differ from RAID5?
> >> raid 6 uses a more elaborate algorithm than the simple parity of raid5,
> >> to calculate two redundant bits. so you can recover from the failure of
> >> two disks out of a raid6 array.
> >
> > Loosing two disks means you got more then two coupled. If so, you have
> > definitely several of the same charge in that array. (Don't deny it, the
> > human laziness speaks against you.)
> > Recovering will still do heavy load on the disks. Now calculate the
> > probability of two disks of the same charge failing without a third disk
> > of that charge failing during recovery. Pretty low, huh?
> that remark is bogus. each disk design has a mean-time between failures
> of X hours. that means of N disks, N/2 will have failed after time X for
> a sufficiently high number of samples N.
> the failure of each individual disk is a statistically independent
> event.

Please listen to what I said: Two (or more) disks of the same manufacturer and 
same type and maybe even continuous id-numbers.
And, bang!, now the failure of one device is highly connected to the failure 
of the other one. Because the error (or call it small mis-fit) happening in the 
production of the first is repeated in the second with a high probability.

And I worked on a manufacturing band several times, I know how humans catch 
slight errors only after doing them the third or fourth time. By which its too 
late to sort out and check the last three products.

> there is absolutely no synchronized self-destruct of disks
> belonging to the same batch.

Yes, there is! I know from bad experience, both my own (not very tragic) and 
that of a big company.

Have fun and make backups,

Arnold
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://lists.linuxaudio.org/pipermail/linux-audio-user/attachments/20091012/cac40bd2/attachment.pgp