From owner-freebsd-hackers Tue Mar 3 20:05:23 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA12908 for freebsd-hackers-outgoing; Tue, 3 Mar 1998 20:05:23 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from allegro.lemis.com (allegro.lemis.com [192.109.197.134]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA12802 for ; Tue, 3 Mar 1998 20:05:08 -0800 (PST) (envelope-from grog@lemis.com) Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by allegro.lemis.com (8.8.7/8.8.5) with ESMTP id OAA10494; Wed, 4 Mar 1998 14:34:51 +1030 (CST) Received: (from grog@localhost) by freebie.lemis.com (8.8.8/8.8.7) id OAA21722; Wed, 4 Mar 1998 14:34:48 +1030 (CST) (envelope-from grog) Message-ID: <19980304143448.27241@freebie.lemis.com> Date: Wed, 4 Mar 1998 14:34:48 +1030 From: Greg Lehey To: shimon@simon-shapiro.org Cc: hackers@FreeBSD.ORG, blkirk@float.eli.net, jdn@acp.qiv.com, tlambert@primenet.com, sbabkin@dcn.att.com, Wilko Bulte Subject: Re: SCSI Bus redundancy... References: <19980303191755.14264@freebie.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89i In-Reply-To: ; from Simon Shapiro on Tue, Mar 03, 1998 at 12:10:08PM -0800 WWW-Home-Page: http://www.lemis.com/~grog Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 3 March 1998 at 12:10:08 -0800, Simon Shapiro wrote: > > On 03-Mar-98 Greg Lehey wrote: > > ... > >> Obviously there are a number of problems. But in fact it's not as >> difficult as it sounds. There's a problem with RAID 5 anyway if >> there's, say, a power failure during a write. After bringing it back >> up again, you can recognize that there's a parity error, but where? > > This sounds like an uncomitted transaction. Quite easy to arrange for a > rollback at boot time. You keep such gems in NVRAM, for example, or in a > known place on the disks, or you implement a journal, or... Sure, if you're doing it in hardware. >> Does that make sense? I'll try to formulate it more clearly if >> anybody has difficulty with the concepts. > > The only problem I have here, is the assumption that the O/S will do all > that. Not only it consumes much CPU, I/O bus, memory bandwidth, etc., but > O/S crashes are the number one cause of failure in any modern > computer. Sure. > Putting all this logic there is asking for it to crash frequently, > and run under load all the time. I don't think you can assume that. The load depends on the input. The reliability depends on the quality of the code. > I think that the RAID logic should be outside the VPU/O/S proper, > just like CRC checking is not done in the CPU anymode, and since > SCSI and IDE, so is data separation, PLL detection loops, etc. If > your data is so important to you, spend few dollars to get it done > in a predictable and reliable manner. You've made the point: spend a few dollars. It's a tradeoff between speed and cost. > BTW, Since 1984 or so, I NEVER lost data due to disk failure. I have. > I lost a LOT of data due to O/S failures, and some data due to bugs > in RAID logic. That, too, but *much* less. Maybe you've been using different operating systems? > Although I do not belive Seagate's claim for 1,000,000 hours MTBF, I > think the realized MTBF will far exceed any FreeBSD uptime. Especially not when it comes from Seagate :-) Greg To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message