Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I got two drives of the same model which are connected using SATA.

When benchmarking read speeds using hdparm -t /dev/sdX, speeds of about 160MB/s are returned. When benchmarking write-speed using dd if=/dev/zero of=testfile bs=1M count=500 conv=fdatasync, speeds of about 140MB/s are returned.

However, when copying a single 10GB-file using rsync --progress /mnt/hd1/file /mnt/hd2/file, the writespeed is only about 35MB/s.

Why is it so slow? How can I make it faster?

share|improve this question
What model? Are they SSDs? It is common with SSD that the write speed is some if not much lower than the read speed. – Dan D. Jul 1 '13 at 19:02
They are normal HDD's. When benchmarking, write speed is 140mb/s+ also. Seems to be an issue with rsync. – Zulakis Jul 1 '13 at 19:04
Then it is possible that the file is rather fragmented. And the seeking which wasn't covered in your benchmarks is what is restricting the transfer speed. What does filefrag /mnt/hd1/file say when ran as root? – Dan D. Jul 1 '13 at 19:11
"6 extends found". Is this a good or a bad value? – Zulakis Jul 1 '13 at 19:18
That is a good low value and that does eliminate seeking as the cause. – Dan D. Jul 1 '13 at 19:21
up vote 6 down vote accepted

According to many sites I found while researching this issue (for example this one), this is just normal as the bottleneck of rsync usually is CPU-power.

Results with dd and cp were near the speeds I initially had benchmarked. Seems like a 2,2Ghz dual core is just not enough for hdd-speed rsync.

During further research I also found out about this:

Correct, rsync has no option to disable the post-transfer checksum completely. I implemented a patch to rsync 2.6.9 that adds an option --trust-append that limits the post-transfer checksum to the added portion, not the entire file. The patch is attached. That should be good enough, but if you really want to disable the checksum completely, just comment out the remaining sum_update calls in match.c and receiver.c .

Rsync always checksums the whole file which takes alot of time. Using the patch mentioned above I managed to increase rsync speed to about 90MB/s. Still not great, but much better then before. Sadly, the patch has not made it into the rsync-trunk.

share|improve this answer

I had exactly the same issue (on Linux) , ie: 35BM/s.

Turns out rsync is CPU bound AND does not trigger the cpu ondemand governor, so the CPU is stuck on the slowest speed (800MHz in my case vs 3000MHz)

You can test by using:

cat /proc/cpuinfo | grep MHz

The fix is to tune the CPU governor.

echo "70" > /sys/devices/system/cpu/cpufreq/ondemand/up_threshold

To make it permanent, put it in /etc/rc.local

See for explanation:

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.