Пример сценария:
- Linux машина (я думаю, что операционная система не беспокоит).
- Сервер OpenSSH.
- Исходный большой файл на жестком диске, около 2 ГБ (я думаю, SSD или классический HD не беспокоит, ни).
- Назначение для файла: USB-порт (умеренно быстрый 2.0) (я думаю, что 3.0 или даже 1.0 не будут беспокоить, ни то, ни другое).

Я собираюсь заказать простое:

cp MyBigFile.iso /media/pendrive

Pendrive подключен к той же машине.
Два случая:

  1. Локальная оболочка (я сижу на машине и делаю cp) выполнения упорядоченной копии большого файла.
  2. Оболочка SSH (я захожу на другой компьютер в той же локальной сети и захожу через SSH-клиент) удаленно заказала копию большого файла.

Есть ли смысл ожидать разницы в скорости? Зачем?

Я думаю, что на самом деле, когда копия включает в себя много небольших файлов, связь (для оболочки SSH) между сервером и клиентом может добавить много небольших задержек (не стесняйтесь исправлять и эту логику, если вы считаете, что я не прав), но Я не уверен насчет больших.

(Не стесняйтесь высказывать мнение о моих сценариях "не беспокоить" , также выше.)

1 ответ1

2

Когда вы запускаете ssh на компьютере и запускаете cp fromFile toFile , эта копия полностью запускается на удаленном компьютере. Он не связывается через ssh, чтобы сделать копию. Фактически, без каких-либо аргументов, cp даже не будет сообщать о прогрессе в сеанс ssh, он будет только завершен, и вы увидите приглашение.

Если вы копируете много маленьких файлов и используете cp -v , cp напечатает имя каждого файла при копировании. Печать имени вызовет связь через ssh-соединение. Возможно, что если у вас медленное соединение, команда cp напечатает имена файлов быстрее, чем ssh сможет передать их по проводам, и кажется возможным, что после печати достаточного количества имен файлов cp может заблокировать попытку записи в stdout.

Я никогда не видел, чтобы это произошло, и скорость диска всегда была ограничивающим фактором, но я думаю, что это теоретически возможно.

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .