[Pc_Support] Using OS software RAID with FRAID organization, and when not to use it ...

Bryan J. Smith thebs413 at gmail.com
Mon Aug 28 18:21:34 EDT 2006


Damien McKenna wrote:
> In the past you have strongly recommended against using FRAID,
> why the change of heart?

First off, there's been 0 change of heart.  FRAID still _sucks_ for
RAID-10, 3 and 5.  In those configurations, you're talking 3-4+ disks
and it's worth the money for a true hardware RAID card.

Secondly, I _still_ advocate on _servers_ that you get a _real_ $200+
server mainboard with PCI64/-X and put in a $100 3Ware Escalade
8506-2LP card for "piece-of-mind."  If you need hot-swap, there's _no_
other option for less money.

But, third, several months ago, I _admitted_ for _desktops_ that PCIe
x1 SATA channels now make software RAID-1 for 2 discs viable, as the
impact on the rest of I/O is more minimized.  I've played with using
MD RAID-1 atop of LVM for some time now in 2 disc configuration.  I
generally avoid it for desktops because of the dual-boot
considerations.


> Is it just because of the transparent support through devicemapper?

It's more than that.  Again, narrowing the focus to _only_ 2 discs in
RAID-1 for a _desktop_ system ...

1)  First and foremost:  you're using Linux kernel software RAID, not
the FRAID driver
2)  You not only solve the firmware/BIOS boot issue, but the
GRUB/device mapping issue
3)  You can dual-boot and not have issues, as Linux and Windows use
the same organization

Now I typically didn't even bother to try any solution out there.  I
had heard about DeviceMapper supporting the Intel ICH5-7 FRAID
organization and the nVidia MCP4/4x0 FRAID organization more recently,
but didn't want to bother.  But I was putting in a new mainboard for
my wife and the discs these days really overload the 32-bit PCI bus,
all while those SATA channels are attached to their own, dedicated
PCIe x1 channel.

I still would _not_ use this on a server.  I would _not_ trust it to
handle single sector errors/remapping and notifications well either.
You _want_ the "piece of mind" out of a 3Ware Escalade 8506-2LP for
that.

But if you just want something that gives you a mirrored run-time of
your data so if a drive goes down you've still got your data, then it
does that.  Which means it's nice for desktops, where you can be down.

Jason Boxman:
> Okay, I understand what you're talking about now.
> I've been booting with an initrd, so I have mdadm proping drives for me on
> boot.  Otherwise, I see how I'd lose my system when disks get lost or moved
> about and the kernel can't determine what has happened.

mdadm does fine when you haven't moved disks around or your disks
haven't taken issue with organization.  Once they do, it's far more
manual of a process -- especially the manual scan you have to do with
mdadm to re-write a new config file (and you're not always in a state
that offers such ;).

That's why I like to use MD atop of LVM.  LVM stores information that
can be used without a full scale (and not always "automagic") mdadm
scan.  I've yet to have a "lost" volume in MD since using LVM, and
it's well worth it.  Again, 99.9% of the problems you heard of LVM+MD
is due to people putting LVM atop of MD -- which is still MD on a
BIOS/DOS Disk Label (traditional partition table).  *NEVER* do that.

But with LVM2+DeviceMapper, the need for MD is pretty much dying.  And
DeviceMapper lets you leverage the firmware/BIOS boot of FRAID -- all
while being OS software RAID-1 once Linux boots.  It's far from
perfect and I'd _never_ use it on a server -- but for a desktop that
dual-boots, it's fine when I don't have PCI-X slots but a SATA
controller SATA channels on dedicated PCIe x1 channels.



More information about the Pc_support mailing list