From: Phillip S. <ps...@cf...> - 2011-06-03 15:45:04
|
On 6/2/2011 10:57 AM, Phillip Susi wrote: > I have managed to come up with a test patch to have the slaves use > SIGUSR1 to signal the next slave to start the read phase, and continue > to use SIGUSR2 to start the write phase. This has resulted in double the > throughput in my initial test, taking the time it takes to dump ( to > /dev/zero ) a 6.9/22gb fs with 386988 inodes from 6 minutes 15 seconds > to 3 minutes 3 seconds. That test was done on a duplicated fs. Because it was recently duplicated for testing purposes, it had fairly low fragmentation. I decided to do some further tests, starting with the original aged and fragmented filesystem. All tests done using -b 1024 after dropping cache. Without patch: 18m 48s With patch: 8m 35s When using compression ( -z, old slow single core cpu ) on the duplicate (defragged) fs: Without patch: 8m 51s With patch: 9m 55s When using compression ( -z ) on the original fs: Without patch: 20m 51s ( 8m 5s cpu time ) With patch: 13m 52s ( 9m 12s cpu time ) When using compression and writing the output to an actual file instead of /dev/zero, on the duplicate fs: Without patch: 9m 41s With patch: 10m 12s And on the original fs: Without patch: 23m 22s With patch: 15m 55s Time to duplicate the original fs using dump | restore: Without patch: 34m 50s With patch: 25m 35s I have no idea why the patch seems to cause a slight slow down when using compression on the defragged fs, but a significant speed up otherwise. |