Date: Wed, 4 Mar 1998 14:34:48 +1030 From: Greg Lehey <grog@lemis.com> 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 <wilko@yedi.iaf.nl> Subject: Re: SCSI Bus redundancy... Message-ID: <19980304143448.27241@freebie.lemis.com> In-Reply-To: <XFMail.980303121008.shimon@simon-shapiro.org>; from Simon Shapiro on Tue, Mar 03, 1998 at 12:10:08PM -0800 References: <19980303191755.14264@freebie.lemis.com> <XFMail.980303121008.shimon@simon-shapiro.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19980304143448.27241>