| 1 |
The Doctor <drwho@××××××××.net> posted 49DF66D1.50306@××××××××.net, |
| 2 |
excerpted below, on Fri, 10 Apr 2009 11:33:37 -0400: |
| 3 |
|
| 4 |
> Duncan wrote: |
| 5 |
> |
| 6 |
>>> I need initramfs to be able to boot from RAID. Same for LVM. |
| 7 |
>> |
| 8 |
>> Yes, for LVM, no, for RAID, at least md/mdp kernel RAID. DM based |
| 9 |
>> firmware RAID is different, and not something I'd trust /my/ system to. |
| 10 |
> |
| 11 |
> Is there all that much of a difference between setting up the kernel's |
| 12 |
> softRAID drivers to interface with onboard pseudo-RAID and just setting |
| 13 |
> up softRAID? |
| 14 |
|
| 15 |
The main difference is likely to be in the testing of the code-paths. |
| 16 |
The kernel's md/mdp RAID is run by many people in all sorts of scenarios |
| 17 |
worldwide, has been for years, and as a result is HEAVILY tested code |
| 18 |
(with some BIG enterprise money behind it as well). While the DM-based |
| 19 |
RAID gets probably reasonably close equivalent testing on the general DM |
| 20 |
stuff because it's fairly generic and is used for LVM (also BIG |
| 21 |
enterprise money behind it) among other things, the code that reads and |
| 22 |
implements the BIOS/firmware side is going to get MUCH less use and |
| 23 |
testing, and may in some cases be one-off code specific to that |
| 24 |
firmware. There's nothing wrong with that, after all, various other |
| 25 |
drivers are one-off code for various stuff, but the level of testing is |
| 26 |
certainly lower, and we ARE talking about data on devices people have |
| 27 |
presumably invested extra on in ordered to get redundancy and/or speed, |
| 28 |
thus, data they likely value relatively highly. |
| 29 |
|
| 30 |
The DM-RAID also tends to be somewhat less flexible. |
| 31 |
|
| 32 |
But one of the reasons I prefer generic soft-RAID here (either non- |
| 33 |
firmware generic DM-RAID or MD-RAID) is that in a hardware controller/ |
| 34 |
mobo failure situation, the implementation is generic. I can take my |
| 35 |
drives and plug them into any generic SATA controller and read them. |
| 36 |
While the kernels I have are built with the specific SATA chipset drivers |
| 37 |
I need, in a recovery situation I could load a LiveCD or build a kernel |
| 38 |
with the new SATA drivers on other equipment and load it onto a |
| 39 |
thumbdrive to access the disks, then transfer a kernel with the necessary |
| 40 |
new drivers onto the disks, after which I could boot them directly. |
| 41 |
|
| 42 |
The firmware pseudo-RAID configured drives lack that data recovery |
| 43 |
flexibility -- you find a compatible firmware RAID or forget it. (Well, |
| 44 |
you can of course pay big money to the forensic data recovery folks to |
| 45 |
try to get it back.) No plugging the drives into any generic SATA |
| 46 |
chipset to read them. |
| 47 |
|
| 48 |
Actually, one of the BIOS updates on my current Tyan mobo emphasized |
| 49 |
this. It warned that the onboard (firmware) RAID wasn't compatible |
| 50 |
between the two BIOS versions... FOR THE SAME HARDWARE! Those who had |
| 51 |
been using it were warned to backup their data elsewhere and restore it |
| 52 |
after the BIOS upgrade, as the RAID implementation wasn't compatible |
| 53 |
across the upgrade. |
| 54 |
|
| 55 |
OTOH, I believe that in at least some cases, the firmware RAID |
| 56 |
implementation is cross-compatible Windows/Linux, something that the |
| 57 |
generic kernel MD- or DM-RAID will NOT be. It may be that the BSDs have |
| 58 |
firmware compatible RAID implementations as well, tho I wouldn't know. |
| 59 |
Of course, before counting on this, one would be advised to test it. |
| 60 |
|
| 61 |
-- |
| 62 |
Duncan - List replies preferred. No HTML msgs. |
| 63 |
"Every nonfree program has a lord, a master -- |
| 64 |
and if you use the program, he is your master." Richard Stallman |
Archives