Re: drive bays and hardware RAID

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



(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.

(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 ).  :-/
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@xxxxxxxxxxxxxxxxxxxx
http://lists.linuxaudio.org/listinfo/linux-audio-user

[Index of Archives]     [Linux Sound]     [ALSA Users]     [Pulse Audio]     [ALSA Devel]     [Sox Users]     [Linux Media]     [Kernel]     [Photo Sharing]     [Gimp]     [Yosemite News]     [Linux Media]

  Powered by Linux