[Pc_Support] Re: WinXP 64-Bit Software Raid Setup Howto? -- How Linux DeviceMapper handles FRAID ...

[Bryan J. Smith]

carter at carter.cc wrote:
> Wow.... I haven't even bothered with trying to mix on-board stuff
> with Linux ever since I was burnt by it (my own fault) a long time
> ago on a BX-133 board.
> As a matter of fact, that's when I started figuring out what Linux
> software RAID was all about... and haven't looked back since. 
> It's nice to know there are supported FRAID systems 'out of the
> box'... maybe I need to give this a look again :)

There have been several approaches to software RAID in Linux,
including FRAID card support.

1.  MultiDisk (MD) in 2.4/2.6
2.  ATARAID (w/HPTRAID, PDCRAID, SILRAID) in 2.4
3.  DeviceMapper in 2.6

#3 is what Red Hat is using.

#1 is still commonly used for Linux Software RAID, but _not_ with
FRAID cards.  Atop of basic BIOS/DOS Disk Labels, you'll have the
same problems as NT 4.0 did -- "sudden loss" of the volume/boot-time
issues.  Why?  Because there is no reservation of parts of the disk
for meta-data -- although at least the newer mdadm tools can
"re-scan" and find MD volumes (although that doesn't help you at
boot-time ;-).  Putting MD volumes in LVM (2.4) and LVM2 (2.6) disk
labels solves the latter problem, just like Logical Disk Manager
(LDM) Disk Labels (Dynamic Discs) is now Microsoft does in NT 5.0
(2000+).

#2 was a stop-gap attempt to build a common FRAID Logic in a single
driver (ATARAID), and then have vendor-specific interface drivers
(HPTRAID for HighPoint Technologies, PDCRAID for Promise Data Corp
and SILRAID for Silicon Image) for their cards.  It was largely an
utter disaster and major PITA.

#3 is the new DeviceMapper component of the Linux 2.6 kernel and also
works with the LVM2 subsystem.  DeviceMapper is extremely flexible,
although portions of it are _not_ in the stock kernel -- at least not
yet.  It was really an ambitious attempt by Red Hat/Sistina, so not
everything is perfected yet -- e.g., Snapshots (which was in the
older 2.4/LVM implementation).  Striping (RAID-0) and spanning
(concatting) went in stock 2.6 and Mirroring (RAID-1) went in later,
including more recent Fedora Core releases.

The great thing about _true_ volume management and DeviceMapper is
that it's not just a "slap atop" approach -- unlike MD.  It addresses
the _full_ spectrum of hardware to firmware to kernel (including
_full_ hotplug support) to the device/user-space detail.  That means
that DeviceMapper can work with the GRUB boot loader perfectly,
including boot/root being on a DeviceMapper volume.  That also means
DeviceMapper can "understand" many common firmware disk organizations
-- including FRAID cards.

Apparently, from my experience, the Fedora Core 5 Anaconda installer
can recognize (possibly via the nv_sata driver) that the nVidia
firmware is set to "RAID" mode (instead of non-RAID/BIOS
compatibility).  So it knows how to map the drives -- devices, kernel
and GRUB boot-time support.  And that's exactly what it did -- at
least for my Mirrored (RAID-1) volume.  Once the devices are
transparently mapped -- including their data organization -- the
kernel's native (via LVM2/DeviceMapper) mirroring/RAID-1 logic is
used -- instead of the vendor driver, but fully emulating it (again,
via DeviceMapper's transparent mapping to the kernel RAID-1 logic).

So I'm getting the full kernel RAID-1 support, and not the vendor's
limited capability.  As long as DeviceMapper handles the organization
correctly, I shouldn't have any data loss.  We'll see.


-- 
Bryan J. Smith   Professional, Technical Annoyance
b.j.smith at ieee.org    http://thebs413.blogspot.com
--------------------------------------------------
     Fission Power:  An Inconvenient Solution