Nice looking 'disk array'

[D. Hugh Redelmeier]

| From: Lennart Sorensen <lsorense-1wCw9BSqJbv44Nm34jS7GywD8/FfD2ys at public.gmane.org>

| > That's one the things I loved about the cpqarray (or wtf they were
| > called) type cards. Battery backed up cache like you mentioned, saved
| > our arses a couple times.
| > 
| > I'm also fundamentally opposed to any device that cheaps out by using
| > the host CPU. To me the idea reeks just like a winmodem. I don't care if
| > there's cycles to spare; the idea just flat out bothers me. It's wrong
| > like Windows is wrong. IMO it kinda goes against part of the Unix
| > philosophy too: do one thing and do it well.
| 
| But what if your 3GHz CPU does XOR better than the dedicated chip on the
| card?  Now if you are running a database server which has things to do
| with the CPU, then sure offload the XOR to a dedicated chip, but
| otherwise, if you are running a fileserver only, perhaps you would
| rather have faster performance.

How one "feels" about these solutions ought to be analyzed.  Here are
some of my thoughts.

Specialized hardware has often proven to be on the wrong curve
compared with general-purpose hardware.  The design cycles of Raid
controllers seem to be longer than CPU design cycles.  So you end up
with dedicated hardware being slower than general purpose hardware.
And being able to handle less memory.  And having memory cost more.
the economies of scale favour the general purpose most times.

In fact, that logic is what inspired the development of RAID in the
first place:  taking a collection of Inexpensive (mass-market, small,
cheap) Disks and making a Reliable system from them.

An ARM on a controller board may well cost the same as a x86 CPU in
your main computer.  There is no question which provides more crunch
per dollar.


Winmodems were a bad idea (I think) for a few reasons:

- real-time is really needed for a modem.  General purpose OSes are
  bad are true real-time.  (Note: realtime does not mean fast average
  response, it requires guaranteed low latency.)

- the interface to the winmodem hardware was never documented in
  public documents.  So no open source drivers were developed.
  (If I'm wrong, I'm not wrong about the vast majority of the
  winmodems.)

- Even if the hardware were open, I suspect that each modem might
  expose a wildly different interface.  This makes it unrewarding
  to write open-source drivers

None of these reasons apply in the case of RAID.


On the other hand, Linux has a monolithic kernel -- no internal
firewalls.  Problems in one part of the kernel can cause other parts
to break.  Hardware RAID *may* provide a useful firewall between the
RAID implementation and the rest of the OS.

Linux's development is somewhat chaotic.  Perhaps a stable hardware
RAID controller makes an important part of the system more stable.  I'd
feel surer of that if the interface between raid and the OS were
file-based, not block based.

Linux's IDE stack has a bad reputation.  So bad, that SATA uses a new
stack, as I understand it.  SCSI is different too.  I have heard lots
of stories that give me doubts about this stuff.  One long-term
problem is that error conditions don't flow up the stack properly.
Maybe a BSD system would be a safer choice.  I don't know -- I'm
talking about reputation.


Dedicated hardware allows some mechanisms that are not widely
available in the mass market.  Stable memory with-RAM-like
characteristics has been proposed for a long time but isn't widely
available.  RAID-board stable cache can be done unilaterally by the
board maker.  Perhaps MS's new support for "hybrid disks" will fill
this gap (but flash probably doesn't allow enough write cycles to
do this).

UPS is good, but perhaps not good enough.  A kernel crash for any
reason, not just a disk driver failure, puts the integrity at risk.


So-called hardware RAID controllers are actually software too.  Just
the other side of the interface.  That software can be buggy.  And
very hard to debug.  And with no user-serviceable parts.


I'm a perfectionist.  I'm not satisfied with the quality of Linux
software.  But I've been less impressed by much commercial software
and firmware.  I cannot speak to the quality of RAID firmware.

Case in point: I bought a Linksys WRV200 VPN router perhaps six months
ago.  Horrible bugs are being worked through with new firmware
releases.  The router is getting close to useful now, in my
estimation.  Recently an awesomely bad security bug was revealed in
this as well as all other Linksys products with QuickVPN(TM): all use
the same private key to authenticate administration, a key that can be
easily extracted from the distributed firmware.  How many other
bone-headed things are in the firmware?  (Apparently QuickVPN cannot
be turned off.)
--
The Toronto Linux Users Group.      Meetings: http://gtalug.org/
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://gtalug.org/wiki/Mailing_lists