From owner-freebsd-hardware@FreeBSD.ORG Wed Aug 4 19:45:48 2004 Return-Path: Delivered-To: freebsd-hardware@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7983216A4CE for ; Wed, 4 Aug 2004 19:45:48 +0000 (GMT) Received: from 2p.hu (fehercapa.kektintahal.pirospolip.hu [195.70.35.189]) by mx1.FreeBSD.org (Postfix) with ESMTP id A47EF43D45 for ; Wed, 4 Aug 2004 19:45:47 +0000 (GMT) (envelope-from wigyori@2p.hu) Received: from localhost (localhost [127.0.0.1]) by 2p.hu (Postfix) with ESMTP id ECBAC97255; Wed, 4 Aug 2004 21:47:37 +0200 (CEST) Received: from 2p.hu ([127.0.0.1]) by localhost (fehercapa [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14012-08; Wed, 4 Aug 2004 21:47:37 +0200 (CEST) Received: by 2p.hu (Postfix, from userid 1000) id B468697288; Wed, 4 Aug 2004 21:47:37 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by 2p.hu (Postfix) with ESMTP id B377C97255; Wed, 4 Aug 2004 21:47:37 +0200 (CEST) Date: Wed, 4 Aug 2004 21:47:37 +0200 (CEST) From: Zoltan HERPAI X-X-Sender: wigyori@fehercapa.kektintahal.pirospolip.hu To: freebsd-hardware@freebsd.org In-Reply-To: <20040804164954.GB10063@Odin.AC.HMC.Edu> Message-ID: References: <4110C9C7.6080506@kaqelectronics.dyndns.org> <20040804164954.GB10063@Odin.AC.HMC.Edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-new at megaweb.hu cc: kat-free@kaqelectronics.dyndns.org Subject: Re: Big Problem X-BeenThere: freebsd-hardware@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: General discussion of FreeBSD hardware List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Aug 2004 19:45:48 -0000 On Wed, 4 Aug 2004, Brooks Davis wrote: > On Wed, Aug 04, 2004 at 07:34:31PM +0800, Kathy Quinlan wrote: > > Design a computer (probably multiple AMD 64's) to handle 10TB of memory > > (+ a few extra Gb of ram for system overhead) and hold the file in one > > physical computer system. > You would do well to read up on the techniques used by google to manage > unreliable systems and provide high-performance search. what about the tandem non-stop systems? it'll cost a pile of bucks.. but, i'm still unsure why a large cluster of oracle, or any specially designed rdbms wouldn't do the job. -w-