0

After i was disappointed with the performance of an external USB drive with my Synology DS251j i did some transfer tests on the shell.

Interestingly i found that copying a 1GB test file takes over three times longer using rsync than using a simple cp command.

I could not confirm this behavior on a desktop linux. Has anyone else had a similar experience? Is there something wrong with rsync on the DS?

The testscript:

#!/bin/bash
sync
echo `date +%M:%S`
cp /volume1/a.tmp /volumeUSB1/usbshare
sync
echo `date +%M%S`
rsync /volume1/b.tmp /volumeUSB1/usbshare
sync
echo `date +%M:%S`

The files a.tmp and b.tmp are each of 1GB, volume1 is the mountpoint for the internal drive /volumeUSB1/usbshare is the mountpoint of the USB 3 drive.

Another confirmation for this behaviour is the fact that i could easily backup the whole drive overnight using cp while this was not possible with rsync.

3
  • I assume the same origin and destination points and that you have not done in sequence the operations (to avoid to take the cashed version); can you edit your question adding the command line that you give with rsync? (Even to understand if it was writing or reading from the drive...)
    – Hastur
    Feb 10, 2016 at 9:45
  • How much CPU are you using when you rsync vs a plain cp? IIRC it has a Marvell Armada 375 dual core CPU at 800 MHz).
    – Hennes
    Feb 10, 2016 at 11:58
  • Maybe CPU is the bottleneck here. I did some testing with rsync and large files, and the CPU load provided by the web-interface went over 80%. I also found out that using the option W seems to transfer whole files seems to improve the performance a bit - even if there is just one file which is not present at the target.
    – Bruno
    Feb 11, 2016 at 9:31

1 Answer 1

1

You would expect rsync to be slower than cp for a first copy, because it does a bit more "to"ing and "fro"ing. Perhaps not take 3 times as long though.

You would expect rsync to be slower on subsequent "update" copies if the -c option is used, and read-and-checksum is an expensive operation on the target machine (slow disk, or slow CPU, or insufficient memory). Likewise, it might be slow without -c if there are large files and a lot of them are changed.

If you forgot to use -t on both the initial and subsequent runs then that would also cause rsync to have to read and checksum the whole file.

Basically, any time rsync has to write everything (or nearly so) then cp will win, so you should be careful that you set the options so that it can do as little work as possible.

If an rsync with completely unchanged files doesn't complete in the time it takes to "stat" every file in the tree (on the slower disk), then you've done something wrong.


Other problems with using rsync on slow machines are compression and encryption overheads. You should disable those options (or make them match what you use for cp) in both rsync and SSH, as much as possible. SSH won't completely disable encryption, of course, but you can adjust the cyphers in ~/.ssh/config (on the other machine); here's what I use for my Synology:

Host diskstation
    Ciphers arcfour256
    macs hmac-md5-96

where "diskstation" is the IP address of your NAS.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .