On 12/7/2012 5:48 PM, Aaron Toponce wrote: > A RAID-1 will outperform > a parity-based RAID using the same disks every time, due to calculating the > parity.
This hasn't been true for almost a decade. Even the slowest of modern single core x86 CPUs have plenty of excess horsepower for soft RAID parity, as do ASICs on hardware RAID solutions. There are two big problems today with parity arrays. The first is the IO load and latency of read-modify-write cycles which occur when partial stripes are updated. Most write IO is small and random, typically comprising over 95% of writes for most typically workloads, mail, file, LDAP, SQL servers for example. Streaming applications such as video are an exception as they write full stripes. Thus for every random write, you first must, at a minimum, read two disks (data chunk/strip and parity chunk/strip) and write back to both with the new data chunk and parity chunk. This is with an optimized algorithm. The md/RAID driver has some optimizations to cut down on RMW penalties. Many hardware RAID solutions read then write the entire stripe for scrubbing purposes (i.e. write all disks frequently so media errors are caught sooner rather than later). This is a data integrity feature of higher end controllers. This implementation is much slower due to all the extra IO and head movement, but more reliable. The second is that failed drive rebuilds take FOREVER as all disks are being read in parallel and parity calculated for every stripe, just to rebuild one disk. Even a small count 2TB drive RAID6 array can take 12-24 hours to rebuild. The recommended max array drive count for RAID5/6 are 4 and 8 drives respectively. One of the reasons for this BCP is rebuild time. With RAID10 rebuild time is a constant, as you're simply copying all the sectors from one drive to another. A 60x2TB drive RAID10 rebuild will take about 5 hours with low normal workload IO hitting the array. > Further, striping across two mirrors will give increased > performance that parity-based RAID cannot achieve. A parity array actually has superior read speed vs a RAID10 array of the same total spindle count because there are more data spindles. An 8 drive RAID6 has 6 data spindles, whereas an 8 drive RAID10 only has 4. Write performance, however, as I mentioned, is an order of magnitude slower due to RMW. > Lastly, you can suffer > any sort of disk failures, provided all mirrors in the stripe remains in > tact. You mean any "number" not "sort". Yes, with RAID10 you can lose half the drives in the array as long as no two are in the same mirror pair. I wouldn't bank on this though. Many drive dropouts are not due to problems with the drives, but with the backplanes and cabling. When that happens, if you've not staggered your mirrors across HBAs, cables, and cabinets (which isn't possible with RAID HBAs), you may very well lose two drives in the same mirror. > 1: http://zfsonlinux.org > Just my $.02. And that sums up the value of your ZFS on Linux recommendation, quite well. Being a fanboy is fine. Run it yourself. But please don't recommend unsupported, out of tree, difficult for the average Debian user to install, software, for a general purpose storage solution. Good hardware RAID is relatively cheap, Linux has md/RAID which isn't horrible for most workloads, and there are plenty of high quality Linux filesystems to meet most needs, with EXT4 for casual stuff, JFS and XFS for heavy duty, though XFS is a much better choice for many reasons; the big one being that it's actively developed, whereas JFS is mostly in maintenance only mode. -- Stan -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/50c30205.2050...@hardwarefreak.com