0

Example scenario:
- Linux machine (I think Operating System doesn't bother).
- OpenSSH Server.
- Source big file in hard disk, about 2GB (I think SSD or classic HD doesn't bother, neither).
- Destination for the file: a (moderately fast 2.0) USB pendrive (I think 3.0 or even 1.0 wouldn't bother, neither).

I am going to order a simple:

cp MyBigFile.iso /media/pendrive

The pendrive is plugged onto the same machine.
Two cases:

  1. Local shell (I sit on the machine, and do cp) execution ordered copy of the big file.
  2. SSH shell (I go to another computer on the same LAN and log via SSH client) remotely ordered copy of the big file.

Does it have any sense to expect any difference in speed? Why?

I think that, in fact, when the copy includes many small files, the communication (for the SSH shell) between server and client could add many small delays (feel free to correct this logic too, if you think I am wrong), but I am not sure about big ones.

(Feel free to opinate about my "doesn't bother" scenarios above, too.)

Sopalajo de Arrierez
  • 6,603
  • 11
  • 63
  • 97
  • 1
    I suspect if you are copying files from the local machine onto a pen drive plugged into said machine the only difference in speed would be the time it takes the machine to receive the copy command (ssh being slower). I may be wrong (hence just a comment) and would find the answer interesting. – Matthew Williams Mar 24 '14 at 16:10
  • Same computer, @MatthewWilliams. I have edited the question to show it, thanks. – Sopalajo de Arrierez Mar 24 '14 at 16:18
  • Yes I was assuming this to be the case. Thanks for the clarification though. – Matthew Williams Mar 24 '14 at 16:19

1 Answers1

2

When you ssh into a machine and run cp fromFile toFile, that copy runs completely on the remote machine. It does not communicate over ssh to do the copy. In fact, without any arguments, cp won't even report progress to the ssh session, it will only complete and then you'll see the prompt.

If you are copying a lot of small files, and use cp -v, cp will print the name of each file as it copies it. Printing the name will cause communication over the ssh connection. It's possible that if you have a slow connection, the cp command will print filenames faster than ssh can transmit them over the wire, and it seems possible that after printing enough filenames, cp could block trying to write to stdout.

I've never actually seen this happen, and disk speed has always been the limiting factor, but I think it's theoretically possible.

Alan Shutko
  • 4,168
  • 1
  • 19
  • 24
  • shouldn't the `cp`command **report progress** to the *SSH session* even for a long size file copy? If yes, this progress report, when done often, will not slow down anything the transfer? – Sopalajo de Arrierez Mar 24 '14 at 22:16
  • 1
    If you run `cp` with no flags, it reports no progress whatsoever. It simply runs silently, and eventually ends. If you run `cp -v`, it will report the filenames of each file it copies, but filenames are small. The way things work, `cp` will be writing to a buffer and `ssh` will be reading from the buffer. The only way that `cp` will slow down is if that buffer gets filled before `ssh` can send the info over the network. – Alan Shutko Mar 25 '14 at 01:54