Date: Wed, 04 Mar 1998 12:34:56 -0800 (PST) From: Simon Shapiro <shimon@simon-shapiro.org> To: Wilko Bulte <wilko@yedi.iaf.nl> Cc: grog@lemis.com, hackers@FreeBSD.ORG, blkirk@float.eli.net, jdn@acp.qiv.com, tlambert@primenet.com, sbabkin@dcn.att.com Subject: Re: SCSI Bus redundancy... Message-ID: <XFMail.980304123456.shimon@simon-shapiro.org> In-Reply-To: <199803041829.TAA01281@yedi.iaf.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
On 04-Mar-98 Wilko Bulte wrote: ... >> Where does that leave kernel RAID? I like controller level RAID >> because: >> >> a. Much more flexible in packaging; I can use of-the shelf disks in >> off-the-shelf cases if I choose to). > > Assuming *good* drives, with *good* firmware. This is as you know not as > obvious as it sounds ;-) Of course not. But moving the logic into the kernel will not solve it. I have always had good success with dedicated controllers. The CMD box, a DPT controller typically work very well. The only disapointment (at the time) was Mylex. But that probably changed since. >> b. In the case of a DPT, you get better performance and better >> reliability, as I have three busses to spread the I/O across, and >> three >> busses to take fatal failures on. > > Yep. Apart from that customer that had a 3 channel Mylex but used only > one > to attach drives to. Wanted to save on the hot-plug case for the drives. > Well, never mind... You can guess what has happened. 3 channel is the > bare minimum IMO. The numbers are simple, and can be easily derived from the SCSI specs (Justin can correct me where I am off base here), but a SCSI bus is good for 400-600 TPS, a drive is good for about that manym and about 4-6MB/Sec, the BUS is not good for much more. If you play with latencies, you arrive at 4-6 drives per bus. PCI-memory is good for 120MB/Sec on a sunny day, on a P6-200 FreeBSD (UP) is good for about 2,000 interrupts/Sec. The eventual throughput is derived from these numbers. ... > ? I don't quite follow you I think. We *still* do RAID to avoid service > disruption. Yes. But service will be disrupted from O/S and application crashes many times more. Whe disk packs were manually loaded, etc. a RAID actually contributed significantly to uptime. Today we do it to reduce the damage WHEN there is a failure, not as much to prevent the failure. This is where my work in HA comes in. It provides a ``CPU RAID'' at the service level. A Traditional FT does it at the instruction level. FreeBSD is not a good candidate for that. I also think that instruction level redundency is excessive for most applications FreeBSD is fit for. But having the service continually available can be a boon to its popularity in certain circles. I think we need to look in this direction as NT is starting to offer some such functionality, and we compete with NT. Let Linux compete with Win9{5,8}. there is overlap between NT and W95. There is (even more) overlap between Linux and FreeBSD, but the ``market'' differentiation is there nonetheless. >> I think the focus changed from operational feature to insurance policy. > Like going bankrupt or collide in midair in case of an aircraft tracking > system. Yes. These two examples are very good. They are all about recovery time. Computers fail. A true FT will detect and correct it at the instruction level (almost or exactly). This is crucial for the control surfaces in a fly-by-wire airplane. A financial transaction can tolerate a second, or seconds lapse in service during an error detection/correction, as long as the logical database is still coherent. My HA model guarantees the second and does absolutely nothing for the first. Simon 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.980304123456.shimon>