Context: copying large volumes of small and large files over a gigabit switch. rsync is preferred over other commands because it provides excellent feedback and sync capability.

In the past I have used rsync but it was limited to 12MB/sec. I suspect that the encryption is the bottleneck.

date > TicToc_Bloggie.txt
rsync -avxu --progress --delete-after --exclude "RECYCLER/" \
      --exclude "System Volume Information/" \ 
      /SOURCE/Public/Video/Bloggie\ Sony\ Dad/ /DESTINATION/MEDIA/Bloggie\ Sony\Dad/ \
    | tee ~/rsync_log_Bloggie.txt;
date >> TicToc_Bloggie.txt

The source is typically another network device that mounted via CIFS.

What is the syntax that needs to be add to the statement above to disable encryption? Examples are appreciated.

  • 1
    See: unix.stackexchange.com/questions/233856/…
    – BowlOfRed
    Aug 30, 2016 at 21:42
  • 1
    Measure, don't speculate. Is rsync using 100% CPU time on either end while it's working? If it is the encryption is the bottleneck. If it isn't then encryption is not the bottleneck and you won't gain anything by sacrificing convenience and security. Aug 31, 2016 at 0:25
  • @Gilles: Good call. CPU load is under 40% (not pegged out at 100%), so maybe BillThor's CIFS bottleneck (see below) is the culprit. Wondering if there's a clever litmus test for a CIFS bottleneck?
    – gatorback
    Aug 31, 2016 at 1:09

2 Answers 2


Run rsync as daemon: rsync --daemon Then you can connect to it from a client with rsync -a blabla rsync://host/dir without any encryption. You can use usernames, default directories, etc... For further details: man rsync

  • Oooh! Intriguing. Is there a URL with a good detailed step-by-step example? Thanks @Ipor Sircer
    – gatorback
    Aug 30, 2016 at 20:20

Try man rsync to get details on various ways to use the tool. There is an extensive set of examples.

I've often had rsync appear to be quite slow, but it generally avoids sending data that does not need to be transferred. It can spend extensive amounts of wall time skipping files that don't need to be transferred.

I've often seen CIFS be a bottleneck. It adds extra overhead on accessing files. It may be better to access the files from the system exporting the files via CIFS. There is an rsync server available for Windows if that is where the file systems reside.

On a gigabit switch, it is quite possible you can't read or write data fast enough to saturate the connection. On older equipment, the system bus may not even be able to transfer data fast enough to saturate the connection.

  • Thanks for the helpful response. I should have mentioned that the source / destination are both Western Digital NAS products and that rsync does not have a man page. Wondering if there is quick easy test to determine if CIFS is the bottleneck: I did not stop to think that it was a bottleneck and appreciate that you mentioned it.
    – gatorback
    Aug 31, 2016 at 1:05
  • @gatorback If you don't have a local man page, Search for man rsync in your favorite seach engine. You can test CIFS access speed, by doing a recursive copy to /dev/null. Write speeds are more difficult to test.
    – BillThor
    Aug 31, 2016 at 1:12
  • @gatorback Unless the CIFS file systems are connected on a different network, you have files coming in and out on the same interface. This will reduce the maximum attainable speed to 50% of the interface speed.
    – BillThor
    Sep 1, 2016 at 12:35

You must log in to answer this question.

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