From owner-freebsd-hackers Wed Mar 4 14:53:37 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA12195 for freebsd-hackers-outgoing; Wed, 4 Mar 1998 14:53:37 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from uni4nn.gn.iaf.nl (osmium.gn.iaf.nl [193.67.144.12]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id OAA12100 for ; Wed, 4 Mar 1998 14:53:20 -0800 (PST) (envelope-from wilko@yedi.iaf.nl) Received: by uni4nn.gn.iaf.nl with UUCP id AA32018 (5.67b/IDA-1.5 for hackers@FreeBSD.ORG); Wed, 4 Mar 1998 23:52:54 +0100 Received: (from wilko@localhost) by yedi.iaf.nl (8.8.7/8.6.12) id XAA04235; Wed, 4 Mar 1998 23:07:08 +0100 (MET) From: Wilko Bulte Message-Id: <199803042207.XAA04235@yedi.iaf.nl> Subject: Re: SCSI Bus redundancy... In-Reply-To: from Simon Shapiro at "Mar 4, 98 12:34:56 pm" To: shimon@simon-shapiro.org Date: Wed, 4 Mar 1998 23:07:08 +0100 (MET) Cc: grog@lemis.com, hackers@FreeBSD.ORG, blkirk@float.eli.net, jdn@acp.qiv.com, tlambert@primenet.com, sbabkin@dcn.att.com X-Organisation: Private FreeBSD site - Arnhem, The Netherlands X-Pgp-Info: PGP public key at 'finger wilko@freefall.freebsd.org' X-Mailer: ELM [version 2.4ME+ PL32 (25)] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG As Simon Shapiro wrote... > > 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 Believe me, I like RAID boxes, not kernel raid. > 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 For good performance our rule of thumb is 4-5 disks/bus. Matches your's quite nicely. 3 buses minimum is more based on the rule that you don't want to have more than one disk out of each set on a channel. As Murphy has it it is always the bus with >1 disk that somehow gets killed. A RAID5 of 3 disks is pretty minimal (OK, it might be 36 Gb netto cap now) > ... > > > ? 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. Hm. Well it is a matter of terminology I suppose. In my view 'failure' also includes a service disruption. But that's a different angle. > 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. OK, I understand you intend to compete with NT/Wolfpack (OK, MS Cluster Server they call it now I think). What do you call it? 'ChuckPack' ? ;-) > >> 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. You are aiming for second-failover times? How do you distinguish then between a somewhat slow machine and one that is really dead? Wilko _ ______________________________________________________________________ | / o / / _ Bulte email: wilko @ yedi.iaf.nl http://www.tcja.nl/~wilko |/|/ / / /( (_) Arnhem, The Netherlands - Do, or do not. There is no 'try' --------------- Support your local daemons: run [Free,Net,Open]BSD Unix -- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message