quite simply, raid5 syncronizes platters and has a wait for parity writes, which leads to a 1:x-1 performance hit because of that parity compute, wait, write for each block. on smaller arrays such as a 3 device raid5, that is 1:(3-1) or 1:2 which is 1 parity write to 2 data writes or 1/3 of all writes is parity. that is a 1/3 loss in speed by the numbers plus a penalty for synced platters which means slower seeks as all drives must seek together.
in larger raid5 arrays the math gets a bit harder because the 1:x-1 in a 6 drive array is 1:5 or 20% penalty, but now you must consider that 1 out of every 5 blocks of data will stop writes on the entire array until that 1 write finishes(because heads and platters work syncronized), which means that of all 6 drives, on one is writing by itself 20% of the time. that can introduce an additional 20% penalty from that wait.
raid5 is designed so that the write is not complete until the parity is written which is a good thing for reliability but a bad thing for performance.
i would say that the common statement on these forums to say that raid5 is bad might need a little more qualification. raid5 is less bad with increasing spindle count as the parity write penalty will be reduced substantially but other penalties keep raid5 in the slow category.
There are a few filesystems that are capable of doing raid5 like things(advfs and zfs) but they are not readily available on linux. advfs might be soon but it's raid5 is not much different that standard raid5. zfs does solve the problem because each parity write is put in the I/O cache and can be processed in parrallel and the filesystem can move on to the next write while the parity is computed and written seperately. zfs has 3 penalties that still exsist with this method, 1 is that the cached parity write still must be written and written soon which CAN cause a head seek penalty because the head may need to come back to a different part of the spindle to write the parity, 2 is that since the parity is not written immediately, a power outage+drive loss at the same time would certainly loose the parity as it was not written and the data would be lost because there is no parity to repair it, and 3rd is that zfs will use more RAM and CPU time because of this caching and more complicated computation of parity. to offset these penalties zfs has a couple neet tricks. 1 it does not have the raid5 write whole(google it), 2 it is very very easy to manage and repair damage, 3 zfs caches I/O and reorders it so random writes happen much more like continuous writes increasing performance in heavy I/O apps(like backuppc!).
I have done some pretty extensive testing on zfs with raidz2 on freebsd and have to say that zfs+freebsd is likely the fastest platform for backuppc. freebsd also has a better networking stack than linux which will also help backuppc out a little. there is also nexenta-core+backuppc which will give you zfs on an opensolaris kernel with a debian/ubuntu environment. This works well but a lot of stuff needs updated on nexenta to use it with backuppc.
also, I appologize if I seems harsh or to have one of those RTFM attitudes about the highjacking, I ment to simply mention the highjacking and then move on with the advice.
anyone, later
On Fri, Aug 8, 2008 at 4:46 PM, Les Mikesell
<lesmikesell AT gmail DOT com> wrote:
Holger Parplies wrote:
>>> specifically, write speed is less that half
>>> that of a raid1 and way less than a raid0+1.
>
> I would find interesting what kind of setup you get that sort of performance
> with (hardware or software RAID, disk speed, number of spindles, RAM size,
> $Conf{MaxBackups}, ...). I doubt it's an absolute figure as you make it sound.
I'd expect that to be fairly normal for short writes because the time is
going to be consumed by the seek/read/write that is needed to fix up the
parity for the rest of the block.
> And, is it really write speed you are measuring? BackupPC does a lot of pool
> *reads* for comparing transmitted files with pool content.
But a lot of the activity is updating the directories with new hardlinks
which is not only a short write but an atomic operation for the
directory that may block other operations.
