From owner-freebsd-hackers  Mon Oct 27 08:26:07 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id IAA29926
          for hackers-outgoing; Mon, 27 Oct 1997 08:26:07 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA29914
          for <hackers@FreeBSD.ORG>; Mon, 27 Oct 1997 08:26:03 -0800 (PST)
          (envelope-from jkh@time.cdrom.com)
Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id IAA02715; Mon, 27 Oct 1997 08:24:21 -0800 (PST)
To: Thomas David Rivers <rivers@dignus.com>
cc: perlsta@cs.sunyit.edu, tom@sdf.com, hackers@FreeBSD.ORG
Subject: Re: Parity Ram 
In-reply-to: Your message of "Mon, 27 Oct 1997 07:55:48 EST."
             <199710271255.HAA02897@lakes.dignus.com> 
Date: Mon, 27 Oct 1997 08:24:21 -0800
Message-ID: <2711.877969461@time.cdrom.com>
From: "Jordan K. Hubbard" <jkh@time.cdrom.com>
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

>  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.

I think he meant "more" in terms of redundancy, not distribution.

Sure, if I split a database into 5000 chunks and put each chunk onto a
distinct node on my network then I've made things pretty fragile in
the process, but if each of those 5000 chunks is *identical* and any
one of the 5000 notes can provide it to a client, then I've created
something far more resistant to failure.  Let's not confuse this
situation by comparing apples and oranges. :)

						Jordan