It's not worth doing hardware RAID over 32 bit 33MHz PCI - which is all a typical desktop system has. The bandwidth limitation of PCI becomes apparent all too soon. Workstation and server machines used PCI-X (64 bit PCI running at either 100 or 133MHz) for high bandwidth cards like RAID and gigabit networking before PCI-e came along. Typical desktop machines only have a single PCI bus, which makes things worse, particularly if you want to put a Gigabit Ethernet card on that same bus.
My main machine is an ageing dual Xeon 2.66GHz workstation. There's two PCI-X buses (one of which has a U320 SCSI controller on it, the other a Gigabit Ethernet controller on it, then both have slots) and a separate 32 bit 33MHz PCI bus, which has a Firewire controller and a slot. This helps prevent I/O bottlenecks. In fact, the real bottleneck in this system, like many Intel systems, is between the processor(s) and the memory.
The IDE and SATA ports you find on your motherboard are typically provided by the southbridge, and go nowhere near the PCI / PCI-X / PCI-e buses. This helps avoid bottlenecks.
I wouldn't bother buying a PCI-X RAID card now, unless you can get a decent one second hand at a reasonable price. PCI-X is disappearing from the latest motherboards, and within a year or two will be very rare on new hardware. You could finish up with a board that you can't easily take forward to a newer machine. You can use a PCI-X card in a PCI slot - but you'll soon hit the bandwidth window.
If you find a second hand RAID card, the battery may be dead, and they can be far from cheap to replace.
I suspect that the Dell in question is a very early P4 machine that uses RDRAM. To be honest, because of the use of expensive RDRAM, and the relative age of the machine, I wouldn't bother with it - the limitations are very apparent and spending a lot of money on a machine that is around five years old seems crazy, especially as I expect that the ultimate limit on RAM is probably somewhere around 1GB (check the manual, which will be available on support.euro.dell.com
). I'd try to pick up something else more suited to the task; a newer P4 machine which will take at least 2GB of much cheaper RAM shouldn't be that expensive.
At the moment, my server is an old PIII-733 which uses conventional SDRAM - but, unfortunately, the motherboard won't take more than 512MB of RAM. It's fine for what I have been using it for, but it looks as if I'm about to outgrow it. There's more about my current position and thinking ahead here
- this was maybe a better thread for it, but I'd already posted there.
Most if not all of the inexpensive RAID NASes (Thecus, Buffalo Terastation and their ilk) use software RAID, as does FreeNAS (which is based around FreeBSD; the RAID 5 module plugs into the GEOM layer between the filesystems and the disks but hasn't yet been officially accepted into the FreeBSD kernel). Software RAID 5 often works well, but can go disastrously wrong - it's not as robust as you may think. The big problem is the 'write hole', especially on a 'partial stripe write'.
RAID 5 works via a simple mathematical relationship between the various drives. If you need to update part of a stripe (for example, you swap two letters over in a text file stored in a particular stripe), you have to read the entire stripe into memory, update it, then write the updated stripe back to all the disks. That's a partial stripe write. There's more steps to a partial stripe write than writing a complete stripe - so it can be a performance issue when you make lots of small changes, as well as it having more potential for it to go wrong than a full stripe write.
There is a time window for any stripe write - partial or otherwise - in which the disks are inconsistent with each other; if you have a power failure or software crash at that instant, the stripe can't be recovered because the mathematical relationship is broken. It will always be corrupt until it is overwritten with entirely new contents and the mathematical relationship is restored.
Worse still, the overlying file system has no idea about the underlying corruption of the stripe. FreeNAS is FreeBSD based, and I believe it uses FreeBSD's UFS2 filesystem, which doesn't have a journal, which by itself can lead to filesystem corruption on an unexpected power outage. This means that you can have a corrupt filesystem on top of a corrupt RAID - double trouble, and more potential for data loss.
One particularly nasty scenario is silent data corruption; the filesystem checks out OK when you restart the system, but you have corrupt stripes mixed into your data and no way of recovering that data other than a backup from before the corruption happened.
Hardware RAID uses various performance and robustness enhancing tricks. Amongst these is RAM on the RAID controller dedicated to holding stripes that are being updated or that have been updated and are waiting to be written back to the disks - which can be battery backed, so that if the machine loses power, the stripes will be retained in that memory and written to the disks when power is available again (write ahead is not safe without battery backed memory on the RAID card). However, there's no inherent guarantee that the battery backed RAM will save you; the overlying filesystem may still have problems, and there's always the possibility of the RAID controller or its battery malfunctioning.
I believe it's vital to understand that especially the higher RAID levels are not all gain. On the face of it, RAID 5 (and, especially these days, RAID 6) are a dream solution to data integrity for our ever growing data storage needs. RAID will prevent some problems - after all, who can dispute the wonder of ripping one disk out of the server and everything staying working. However, it introduces whole new ways to lose and corrupt data, which often aren't understood well. Further, many tune these systems for performance - there are people out there who seem benchmark obsessed - not realising that they're compromising the integrity of their data.
I know someone that runs a hosting provider pretty well; I know that most of the machines he has scrapped over the years have been down to RAID related flakiness, and many of the outages are down to RAID related snafus. Increasingly he's moving to using iSCSI and blades, with the storage on expensive proprietary iSCSI servers that aims to provide high reliability. Even such expensive setups don't always save you - some outsourced servers he uses failed this week due to an air conditioning failure, which left the iSCSI system wrecked. The last I heard, they were couriering over drives to fit into local RAID controllers on the servers so that they could restore backups and get things back online.
An intriguing way out of much of this mess of RAID as it stands today is ZFS. It's still being developed, and is only seen at its most mature in Solaris and, to a large extent, OpenSolaris - it was, after all, a Sun innovation. I'm not going to go through the advantages of ZFS here, but it offers raidz and raidz2 which have no 'write hole' and mitigates against the 'expense' of partial stripe writes using variable stripe sizes (which reduces the computational burden and increases the robustness of writing to the array). ZFS also offers various data integrity and self healing capabilities. Even better is that it doesn't need a hardware RAID controller - in fact, you're better off not using such a controller with ZFS.
ZFS is in the upcoming FreeBSD 7.0, but it's experimental in 7.0. It's likely to be marked stable in 7.1, hopefully by around next summer - whether it will be possible to boot FreeBSD from ZFS by that time is uncertain. The person responsible for porting ZFS to FreeBSD has suggested that you really want a minimum of 1GB of RAM, and ideally a 64 bit machine - this isn't something that's going to run well on very old hardware.
What FreeBSD 7.0 does have is journal capabilities at the GEOM layer (which sits between the filesystems and the disk hardware). Journalling means that losing the power shouldn't corrupt the filesystem. For robustness on FreeBSD 7.0, I'd use UFS2 with gjournal on a gmirror pair (in other words, a journalled filesystem on RAID 1). In fact, it may be possible to do it the other way round - gmirrored UFS2 on a pair of gjournalled drives - I'm not sure which is more robust; I'd have to think about it.
Either way round, this may not be as 'sexy' as software RAID 5, but it is likely rather more robust and may well perform better. I would never run anything I was serious about the data on without a good quality UPS, either; all the machines here are on a UPS apart from the laptop, which effectively has a UPS by having its battery installed.
FreeBSD 7 will soon be at release candidate stage; you could maybe do worse than put a drive or two in the Dell, install 7.0-BETA2, and play. The FreeBSD Handbook is being updated to cover 7.0 as we speak - indeed, it's pretty much there now, though you may have to hunt around for instructions on things like getting gjournalled UFS2 going (I can walk you through if necessary). Really, you shouldn't use a non -RELEASE version of FreeBSD for production purposes unless you know what you're doing, but 7.0-BETA2 has already had a long shake-down period, and things are getting better for it all the time whilst upgrading isn't too awkward
The RAID 5 module FreeNAS uses may make it into FreeBSD 8, or just possibly into a 7.x release from 7.1 onwards, but the effort to get it officially included in the kernel may be decided as not worthwhile with ZFS hopefully becoming stable. There again, if you want it, there's nothing stopping you building it on a 'stock' FreeBSD machine.