Tell me more ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.
up vote 5 down vote favorite

I hope this does not count as a question without a real answer, as I can't seem to find a good reason to use cp(1) over rsync(1) in virtually all circumstances. Should one typically favour rsync over cp? Is there any good guideline for their use?

  • rsync: Transfers the diffs, it can use compression, it can be used remotely (and securely), it can be restarted despite an interruption, even during the transfer of a single large file. '

  • cp : Perhaps it's just simpler to use? Is it faster than rsync?

share|improve this question
2  
Sometimes the overhead of comparing is far more effort than simply copying the bytes blindly. – bahamat Jul 31 '12 at 17:55

3 Answers

up vote 7 down vote accepted

cp is a part of coreutils, therefore it is present everywhere. furthermore, it primarily was designed to copy files inside one computer.

rsync isn't a part of coreutils, it isn't present even on the default environment. moreover it was primarily designed to transfer files over network. Also rsync has more dependencies comparing to coreutils, however this difference doesn't make a big sense.

ps. By the way the CPU usage is still matters on the embedded systems.

share|improve this answer
up vote 3 down vote

The main reason you don't want to use rsync for every copy operation, is becasue rsync has calulating overhead. Before data transfer actually starts, rsync scans all the files. Then before each file, a comparison is made. This overhead is not insignificant, even with the fast CPU's available in 2012. I do these type of transfers all the time, and on pretty decent sized servers, once you start dealing with gigs of data the overhead can be time consuming.

I'm not saying don't use rsync, not at all, use rsync anytime you can save some transfer time. Just don't use rsync when cp could accomplish the same thing.

What I usually do, first bring over the data using regular copy methods. Then rsync for subsequent changes, which is when those diffs can be leveraged.

share|improve this answer
Is it a large price to pay, given how powerful our processors are today? – Soyuz Jul 31 '12 at 14:45
2  
Large is subjective, and would change depending on the number of files vs size of data vs IO. My main point would be, it's not insignificant regardless of today's processors. One thing to remember today's processors, still must deal with today's data. – TechZilla Jul 31 '12 at 14:53
Agreed. CPUs don't get faster in a vacuum. One of the best reasons we have for GHz CPUs is gigabit networking: a slower CPU simply cannot keep an I/O pipe that big full. Computers tend to be as well balanced as we know how to make them. Take away some CPU power, and some of the I/O capacity goes idle. Increase the I/O demand, and the CPU ends up idling more, waiting on I/O. – Warren Young Jul 31 '12 at 20:32
up vote 3 down vote

I would expect cp to use less CPU when copying locally because it doesn't use diffs whereas rsync can reduce writes when using diffs. Compression should be avoided locally because you have to read and write the whole file/diff anyway and it requires additional computations.

share|improve this answer
So, it all boils down to CPU cost or I/O cost – Soyuz Jul 31 '12 at 14:49
2  
@soyuz, that is true for data which has changed, in reference to other data. The smaller the diff, the more rsync is preferred. But when their is no diff, rsync is only bringing overhead without extra benefit. – TechZilla Jul 31 '12 at 14:56
@TechZilla I think you mean, when there's nothing in common. If there is no diff, rsync will just end early 'cause there's nothing to copy, making it far more preferred. – Izkata Jul 31 '12 at 17:59
@Izkata: There's at least one way for rsync to have twice the I/O overhead for two identical files as compared to blind cp: a changed modification time. You'd have to give --size-only to fix this. The only other way I can see around this would be for rsync to rely on filesystem checksums, but for most filesystems they're not very good statistical predictors of identity. – Warren Young Jul 31 '12 at 20:19

Your Answer

 
discard

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.