[LAU] drive bays and hardware RAID

[Niels Mayer]

(1) Use Linux Software Raid and not "FakeRaid" -- marketing and florid prose
might tempted you into thinking FakeRaid was hardware assisted raid, it
isn't; it will cause you a world of woe if you ever need to recover a disk
-- all the recovery tools end up requiring a windows partition had already
been installed....  For details,
https://raid.wiki.kernel.org/index.php/Linux_Raid == LSR.

In fact a dual-boot w/ windows is the only reason to use fakeraid (
https://help.ubuntu.com/community/FakeRaidHowto ):

Why not use a linux software raid?


> If you have arrived here after researching this topic on the Internet, you
> know that a common response to this question is, "I don't know if you can
> actually do that, but why bother -- Linux has built-in softRAID capability."
> Also, it's not clear that there is any performance gain using hardware
> fakeRAID under Linux instead of the built-in softRAID capability; the CPU
> still ends up doing the work. The most common reason for using fakeRAID is
> in a dual-boot environment, where both Linux and Windows must be able to
> read and write to the same RAID partitions.


...

Chances are, if it's cheap, it's fakeraid and closed by virtue of the
closed-ness of your motherboard manufacturer or the manufacturer of the
particular "raid solution in a box."

And also consider that if your special RAID hardware dies some years in the
future, there may be no easy way to get that hardware controller again, and
your disks, written with it's own special protocol, will be useless. With
LSR that
won't be a problem -- chances are there'll still be some still-working
branch of the open-source code that'll work with your old data on your old
drives, far into the future. As long as there's SATA ports on motherboards
and drives, you'll be able to recover and read your LSR-created drives, even
between distros.

<https://raid.wiki.kernel.org/index.php/Linux_Raid>(2) seems like many
motherboards have at least two e-sata ports (one internal and one external)
which
could be routed into an external drive-bay container like this:
http://www.directron.com/ms2tplus.html

(3) Although I'm using fixed disks, i've been using Linux Sofware Raid 1 on
Fedora 11&12 -- and it works great -- as protection against disk failure.
Don't use Raid 0... buy a faster or bigger disk instead. LSR's performance
impact on modern desktop processors seems negligible. For situations where
you're really pounding the disks (internet server, database server, video
server, or multichannel 192k audio) plug in a hardware PCI or PCIe Raid
controller card and don't use LSR.

(4) The only thing that I could see as dangerous w/ an external setup --
make sure there's no way of "unpairing" Raid-1 sets, including having one
drive not powered on, or properly plugged in, etc... Because your system
will happily come up using only one disk of a raid-set. Then you get to
spend some time syncing disks, and hoping (or furiously reading manual
pages) you can figure out a way to make sure it syncs the newer disk over
the old one, and not vice-versa.

By the way, LSR is very nice, even while rebuilding... you'll notice your
load higher and your disk IO up... but otherwise, you can continue working
(maybe not enough i/o leftover for heavy video or audio editing, but enough
that you'll still be able to use your computer). The amount of bandwidth for
disk checking and rebuilding can be adjusted & configured. My cron checks my
disks weekly noting the configured disk-usage bandwidth constraints:

May  2 04:10:01 gnulem kernel: md: data-check of RAID array md1

May  2 04:10:01 gnulem kernel: md: minimum _guaranteed_  speed: 1000
> KB/sec/disk.

May  2 04:10:01 gnulem kernel: md: using maximum available idle IO bandwidth
> (but not more than 200000 KB/sec) for data-check.

May  2 04:10:01 gnulem kernel: md: using 128k window, over a total of
> 485107136 blocks.

May  2 04:10:01 gnulem kernel: md: delaying data-check of md0 until md1 has
> finished (they share one or more physical units)


Niels
http://nielsmayer.com

PS: Fedora 13 is going to have something even cooler -- BTRFS -- you'lll be
able to "roll back" to a the copy of the filesystem before you overwrote the
only copy you had of an original source track...
http://www.phoronix.com/scan.php?page=article&item=fedora_13_btrfs&num=1  ...
   http://www.phoronix.com/scan.php?page=news_item&px=NzcyNA  .... Note a
missing feature/bug from ReiserFS (
http://en.wikipedia.org/w/index.php?title=Comparison_of_file_systems&oldid=220529437#Features
).
 :-/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-user/attachments/20100504/b9b8ffff/attachment.htm>