Re: [OT] 19"/2U Cases

On Wednesday 29 August 2007 13:45, Michael Loftis wrote:
> MDRAID certainly isn't reliable in a huge number of failure cases. It
> causes the machine to OOPS/lock up. Or even lose data. MDRAID is also
> very difficult to administer, offering only (depending on your version)
> mdadm or raid* tools. mdadm is rather arcane. simple operations are not
> well documented, like, how do i replace a failed drive? or start a
> rebuild? there's no 'rebuild drive' it's completely NON automated either.
> meaning it always takes user intervention to recover from any failure. a
> single I/O error causes MDRAID to mark the element as failed. it does not
> even bother to retry. MDRAID is also incapable of performing background
> patrolling reads, something i think even 3Ware does. MDRAID RAID5 sets are
> non-bootable. Something you get from any hardware raid, evne 3Ware. My
> money lately has been on LSI's cards. 3Ware is a good second choice too.
> the newer ICP* modelled ICP controllers are shit (as opposed to the pre
> intel/adaptec GDT* series which are rock solid).

Software RAID has been reliable for many years. We use software RAID in Etch on dozens of systems ranging from small workstations to terrabyte arrays. When two drives fail in a RAID 5 you'll lose your data - under software RAID yes but also under hardware RAID. There's no need for a 'rebuild drive' because the rebuild starts when the new drive is added with a command such as "mdadm -a /dev/md0 /dev/sda". Simple and fast.

Hardware RAID can only manage entire drives. For flexibility and efficiency software RAID manages partitions. As you gain experience with RAID, you'll want different filesystems with different RAID characteristics within a single system. As a complex but real-world example: one can have four drives with /boot 4-way mirrored, swap consisting of two 2-way mirrors, most of the filesystems in RAID-5, and a large cache (e.g. squid or netflow) in RAID-0 or LVM PVs. Hardware RAID is much more expensive, and you have to keep a spare controller (or motherboard) to recover your data when the original controller (or motherboard) dies.

> I can never recommend any software RAID for anything other than simple
> mirrors, and then, always, with the caveat that it will be a bitch to fix
> if things go wrong, you probably won't lose data, but getting a software
> raid running again is often arcane, especially with MDRAID and it's
> frequent inability to correctly identify a failed drive (sometimes the
> fault of the SATA controller mind you). BSDs vinum is little better in
> these regards. And god forbid you lose your boot drive and have forgotten
> to keep all the boot blocks on your spare properly updated. you also have
> to manually intervene and reorder drives in that case, something hardware
> raid, any hardware raid, will transparently cover.

There are many people who know how to manage software RAID systems without unnecessarily losing data. Such people will most likely have actually used software RAID such as MD with persistent superblocks and will know that there is nothing to the above FUD unless they deliberately sabotage the default configurations. It sounds like you're trying to hand assemble RAIDs from lists of drive partitions rather than using UUIDs. LILO automatically updates mirrors. With the current Grub one should grub-install each mirror.

--Mike Bird

-- 
To UNSUBSCRIBE, email to debian-isp-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org