I've run software RAID on Linux servers for nearly a decade now and have never detected a major performance penalty. The kernel code has been pored over for a very long time so I suspect it's pretty efficient. The drawback to software RAID is that you have to execute commands at the OS level if you want to replace a drive on-the-fly. On machines with hardware RAID, especially ones that support hot-swap drives, you can just pop the drive out from under the operating system and replace it. With software RAID you have to use mdadm
to tell the kernel to drop the faulty drive, replace the physical device, then use mdadm to insert the new drive into the array. If you don't mind taking the machine entirely off-line, you can simply shut down, replace the drive, and restart. The OS will notice that the drive needs to be inserted into the array and begin reconstruction.
Most modern Linux distros let you build the array at installation. For servers I use CentOS
, the free repackaging of RedHat Enterprise Linux, because it has long-term support. I use the installer to build the array, then tell the installer to turn the array into a single "physical volume" using something called the "Logical Volume Manager
." With LVM you can divide a physical volume into a number of "logical volumes" that behave equivalently to disk partitions. Unlike partitions, logical volumes can be resized, and you can create backup "snapshots" of the logical volumes.
Regardless of how you set up the array, I'd boot from a separate disk that holds the /boot and / (root) partitions, then mount the array's volume(s) as /home or at a mount point under /media. With this arrangement you can modify the operating system files without touching the files you've stored on the array. A 20-40GB PATA disk works fine as the boot disk. In fact you might want to leave some of it unpartitioned in case you want to install another operating system or test out an upgraded version of your current OS before switching over.Another thread
in this forum discusses the choice of a filesystem to install on the array. For video storage, many of us use Silicon Graphics's "XFS
" or IBM's "JFS
." If you're used to Windows, you might be surprised by the notion that you can choose the filesystem that will be storing your data since Windows offers NTFS and nothing else. If you are sharing these files with Windows machines using Samba, or with *nix machines using NFS, the clients will be entirely unaware of the filesystem that underlies the actual data on the server.
This all assumes you'll be watching the stored material on another device. If you want to watch or listen to the stored files on the machine itself, you'll probably need to install additional software that can't be included in free distributions because of patent or copyright restrictions. If the intent is simply to serve these files to other machines, you won't need anything beyond a plain vanilla distribution like CentOS.