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>