From owner-freebsd-scsi Tue Apr 14 17:58:20 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA03473 for freebsd-scsi-outgoing; Tue, 14 Apr 1998 17:58:20 -0700 (PDT) (envelope-from owner-freebsd-scsi@FreeBSD.ORG) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA03468 for ; Wed, 15 Apr 1998 00:58:18 GMT (envelope-from gibbs@narnia.plutotech.com) Received: (from gibbs@localhost) by narnia.plutotech.com (8.8.8/8.7.3) id SAA24735; Tue, 14 Apr 1998 18:54:24 -0600 (MDT) Date: Tue, 14 Apr 1998 18:54:24 -0600 (MDT) From: "Justin T. Gibbs" Message-Id: <199804150054.SAA24735@narnia.plutotech.com> To: shimon@simon-shapiro.org cc: scsi@FreeBSD.ORG Subject: Re: RAID performance/benchmarking Newsgroups: pluto.freebsd.scsi In-Reply-To: User-Agent: tin/pre-1.4-971204 (UNIX) (FreeBSD/3.0-CURRENT (i386)) Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In article you wrote: > > Depends on array size, type of controller, amount of cache, type of access. > RAID arrays are not a good benefit for sequential access. This really depends. For Pluto's application, using RAID 3 not only gives us reliability, but also the ability to have one of the drives in a stripe "return late", but still maintain low latency by replacing the data through parity reconstruction. Since we are a realtime system where being even a little late is unacceptable, the use of RAID gives us a big advantage. Almost all of our accesses are sequential. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message