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,851

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,238