From owner-freebsd-hackers  Mon Oct 27 06:19:18 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id GAA22081
          for hackers-outgoing; Mon, 27 Oct 1997 06:19:18 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from elvis.vnet.net (elvis.vnet.net [166.82.1.5])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id GAA22075
          for <hackers@FreeBSD.ORG>; Mon, 27 Oct 1997 06:19:09 -0800 (PST)
          (envelope-from rivers@dignus.com)
Received: from ponds.dignus.com (ponds.vnet.net [166.82.177.48])
          by elvis.vnet.net (8.8.5/8.8.4) with ESMTP
	  id JAA12570; Mon, 27 Oct 1997 09:19:02 -0500 (EST)
Received: from lakes.dignus.com (lakes [10.0.0.3])
	by ponds.dignus.com (8.8.5/8.8.5) with ESMTP id IAA20509;
	Mon, 27 Oct 1997 08:06:38 -0500 (EST)
Received: (from rivers@localhost) by lakes.dignus.com (8.8.5/8.6.9) id HAA02897; Mon, 27 Oct 1997 07:55:48 -0500 (EST)
Date: Mon, 27 Oct 1997 07:55:48 -0500 (EST)
From: Thomas David Rivers <rivers@dignus.com>
Message-Id: <199710271255.HAA02897@lakes.dignus.com>
To: perlsta@cs.sunyit.edu, tom@sdf.com
Subject: Re: Parity Ram
Cc: hackers@FreeBSD.ORG
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

> On Sun, 26 Oct 1997, Alfred Perlstein wrote:
> 
> > > > Do you know anything of Richard Hamming's assertion that parity memory
> > > > (the old fashioned even/odd type) is-a-bad -thing in large
> > > > configurations?
> > > 
> > >   I think it bullshit.  I've never heard of this before.  Nor have you in
> > > the two times you've mentioned it, actually stated what is supposed to be
> > > so bad about it.
> > 
> > more bits means more chance of error even if they are "error-correcting"
> > bits?
> 
>   And how is that bad?  Even simple parity systems will catch 100% of all
> single bit errors, regardless of where the bit appears.
> 
>   More bits mean more redundancy.  That means it gets safer, not riskier.
> 
> Tom
> 
> 

 In reliability - more doesn't always mean safer.

 Say, for example, I spread my database across two disks - but both
have to be running for the software to gain access.  Then, I've just
doubled the probability of failure; not halved it.

 But - if I don't spread things out; but increase redundancy, I
may have improved the situation.  It depends on the path to the data
(recall your database theory - you need one way to access information,
redundancy in access paths can cause serious problems as well.)

	- Dave Rivers -