Date: Tue, 03 Mar 1998 12:10:08 -0800 (PST) From: Simon Shapiro <shimon@simon-shapiro.org> To: Greg Lehey <grog@lemis.com> 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: <XFMail.980303121008.shimon@simon-shapiro.org> In-Reply-To: <19980303191755.14264@freebie.lemis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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... ... > Vinum offers another alternative: attach a second plex with the same > data, maybe only a few megabytes at a time. During the time this area > of the volume is being updated, the plex supplies a backup in case of > failure. When the region is left, the plex is detached and reattached > at the next point in the array. If anything goes down, the correct > data will be in the auxiliary plex. Concatenation with journaling. Could be done. > 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. Putting all this logic there is asking for it to crash frequently, and run under load all the time. 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. BTW, Since 1984 or so, I NEVER lost data due to disk failure. I lost a LOT of data due to O/S failures, and some data due to bugs in RAID logic. 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. This discussion is very enlightening none the less. ---------- Sincerely Yours, Simon Shapiro Shimon@Simon-Shapiro.ORG Voice: 503.799.2313 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?XFMail.980303121008.shimon>