From: Les M. <les...@gm...> - 2012-09-18 16:25:11
|
On Tue, Sep 18, 2012 at 9:53 AM, Timothy J Massey <tm...@ob...> wrote: > > > All of that was clearly outlined at the top of the e-mail: 4 x 2TB > Seagate SATA drives in RAID-5 (using md, which I''m not sure I stated > originally). Raid5 has its own reasons for bad write performance. You sort-of make up for it with 8+ drives in an array, but with 4 you've basically made all the heads wait for the slowest and forced a read-update-write cycle on everything less than a raid block in size. And with md, the parity update is probably going to be clocked as CPU, not device i/o time. Keep this in mind when comparing backuppc vs. native rsync - backuppc is storing metatdata in different places, updating multiple directory entries, etc. That translates to more small writes. For the extreme case, consider a native rsync of an unchanged tree - no writes at all, where backuppc will build a new directory tree and touch the link count in every inode. > > That's fairly bad news for me, then. These are embedded-style > motherboards, and upgrading to a >3GHz Xeon processor is not an option... > :( There is not just a little bit of difference between a dual-core box and the new xeons. I don't have benchmarks, but they are insanely faster. Throwing some more RAM at it might help a little by permitting more read-ahead and write buffering but probably just a little if you aren't seeing much wait time now. > That's my next step. When I upgraded from my old VIA-based servers, I > (accidentally) left compression on, and thought the new, dual-core, faster > and more efficient processor would be OK with this. That may have been my > biggest mistake. (Honestly, I've already found other areas that make me > think that my original distain for compression might have been > well-justified! :) ) I don't think it will matter that much once you have passed the 2 fulls to get cached checksums. After that you'll only be compressing/uncompressing content with changes. -- Les Mikesell les...@gm... |