CentOS - Jun 2005 - Re: Opteron Mobo Suggestions -- the follies of typical tape backup (it's the 21st century)

From: Kirk Bocek <t004 at kbocek.com>
> Another poster (sorry, could find the name, was it Peter?) mentioned the 
> lack of hot-swap support in most of the hardware raid out there. If this 
> is the case, what's the point of raid 1 or 5 if a failed drive will
hang
> the system? What's your experience with the 3Ware cards?
"Hot-swap" is like saying "3D accelerator," there are
different features
and, sometimes, if you don't have them all, they don't work.

#1 is dealing with transient power
#2 is dealing with the hardware ATA disconnect
#3 is dealing with the software ATA disconnect

While many carriers claim to solve #1 for ATA, _only_ SATA with its
staggered data/power (using the 15-pin power, and not the legacy
4-pin Molex) is the _best_ guarantee.  But typically #1 is not that
much of an issue, because the carrier does a decent job at this
(some better than others though).

The big issue with "FRAID" is at #2.  A biggie is when you use the
master/slave and remove one.  But even if you do master-only, how
do you take out a device and replace it -- virtually "resetting" the
ATA-PCI arbitration.  It typically does _not_ work if the ATA controllers
are directly connected to the system's PCI interconnect.

But let's say you get #2 to work, now #3 is the biggie.  How to you
get the OS to "reload" what it thinks is a fixed ATA channel with a
fixed drive.  Sometimes the FRAID driver does a _poor_ job of it.
This is what I see get people all-the-time.

In the case of 3Ware cards, the system _never_ -- let me repeat that --
_never_ sees the ATA channel.  The system, including the PCI
interconnect, _only_ talks to the on-board ASIC.  The ASIC then drives
the ATA channels.

In FRAID, the system, it's CPU and the PCI bus drive and talk _directly_
to the ATA channels.  Intelligent RAID uses its on-board intelligence
instead.  FRAID doesn't have any.
> Okay, okay, you win! You're right and I'm wrong!
Dude, this isn't about "right and wrong."  It's _never_ about
that.
It's about my sincerest wish not to see you with downtime.

It's one thing for me to argue "good" v. "ideal," take
it as you wish.
But that's very, very, _very_ different than this.

In this case, I'm arguing "proper" v. "risky" system
design.
But it's your system.
> I will never consider IEEE-1394 again. You and the other posters
> have convinced me. Every USB cable in my server room will be
> removed and destroyed. Every USB port will be filled with glue.  :)
I don't think we _ever_ said that.

We just said don't use IEEE-1394 or USB for removable storage on
a server.  You can continue to use IEEE-1394 and USB for non-storage
devices, including input and media as necessary.

GOLDEN RULE:
As long as the server doesn't "mount" the IEEE-1394 or USB device,
then you're "safe."  If it "mounts," then you just put
your entire
kernel at the mercy of its availability.  ;->
> What about LVM snapshots? I've been using these for awhile with no 
> problems. Yes, I understand that it will consume disk bandwith but 
> that's not a limitation in my installation.
Snapshots are an "on-line" backup and they only work if your
filesystem
isn't _toast_.  They aren't the same as "near-line."

Again, read the "document" I sent you off-line.  ;-ppp





--
Bryan J. Smith   mailto:b.j.smith at ieee.org