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 <[EMAIL PROTECTED]> 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.
>
> --
> Les Mikesell
> [EMAIL PROTECTED]
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> BackupPC-users mailing list
> BackupPC-users@lists.sourceforge.net
> List: https://lists.sourceforge.net/lists/listinfo/backuppc-users
> Wiki: http://backuppc.wiki.sourceforge.net
> Project: http://backuppc.sourceforge.net/
>
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
List: https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki: http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/
