Назад | Перейти на главную страницу

копировать большое количество файлов по ssh

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

cp -rnv /mounted_path/source/* /local_path/destination

Команда запускает рекурсивное копирование, которое не перезаписывает существующие файлы. Но процесс копирования довольно медленный. Замечу, что он не копирует файлы по порядку. Итак, мой вопрос: могу ли я ускорить процесс копирования, открыв несколько терминалов и выполнив ту же команду выше? Достаточно ли умен процесс копирования, чтобы не перезаписывать файлы, скопированные другими процессами?

… Чтобы ответить на исходный вопрос, как указано…

Здесь нужно обсудить две вещи.

Использование SSHFS

SSHFS использует «подсистему» ​​SFTP протокола SSH, чтобы удаленная файловая система выглядела так, как если бы она была смонтирована локально.

Важно отметить, что SSHFS переводит низкий уровень системные вызовы в команды SFTP относительно высокого уровня, которые затем преобразуются в системные вызовы, выполняемые на сервере сервером SFTP, а затем их результаты отправляются обратно клиенту и переводятся в обратном направлении.

Этот процесс замедляется по нескольким причинам:

  • Существуют отдельные системные вызовы для различных операций с файлами, и они выполняются в том порядке, в котором их отправляет клиент. Скажем, клиент stat(2)-с информацией о файле, тогда open(2)-s этот файл затем считывает свои данные - выполняя несколько read(2) звонит подряд и, наконец, close(2)-в файле, все эти системные вызовы должны быть преобразованы в команды SFTP, отправлены на сервер и обработаны там, а их результаты отправлены обратно клиенту, переведены обратно.
  • Даже несмотря на то, что SSHFS, похоже, реализует определенные хитрые приемы, такие как «упреждающее чтение» (предположительно считывает больше данных, чем запрашивает клиент), тем не менее, каждый системный вызов приводит к циклическому обращению к серверу и обратно. То есть мы отправляем данные на сервер, затем ждем его ответа, а затем обрабатываем его ответ. IIUC, SFTP не реализует «конвейерную обработку» - режим работы, при котором мы отправляем команды до их завершения, то есть каждый системный вызов. Пока это технически возможно иметь такую ​​обработку до определенной степени, sshfs похоже, не реализует его.

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

Множественный cp -n процессы работают параллельно

Ответ на вопрос, можно ли нанять несколько cp -n параллельное копирование файлов зависит от нескольких факторов.

Во-первых, если они все переедут тот же самый SSHFS, очевидно, не будет ускорения, так как все системные вызовы, отправленные несколькими cp в конечном итоге попадет в то же соединение клиента SFTP и будет им сериализован по причинам, описанным выше.

Во-вторых, запуск нескольких экземпляров cp -n переезжать отчетливый Точки монтирования SSHFS могут быть полезными - до пределов, обеспечиваемых пропускной способностью сети и пропускной способностью ввода-вывода на носителе / ​​носителе в целевой файловой системе. В этом случае важно понимать, что, поскольку SSHFS не будет использовать блокировку на сервере, различные экземпляры cp -n должны работать в разных иерархиях каталогов - просто чтобы не наступать друг другу на пятки.

Разные / более разумные подходы

Во-первых, конвейерный поток данных, созданный tar, cpio или другой потоковый архиватор и его удаленная обработка имеет то преимущество, что исключаются все циклы обработки операций файловой системы: локальный архиватор создает поток с такой скоростью, которую позволяет пропускная способность ввода-вывода в исходной файловой системе, и отправляет его так быстро, как сеть позволяет; Архиватор remove извлекает данные из потока и обновляет свою локальную файловую систему настолько быстро, насколько это позволяет. Никаких циклических обходов для выполнения элементарных «команд» не требуется: вы просто выполняете работу настолько быстро, насколько позволяет самая медленная точка ввода-вывода в этом конвейере; Быстрее ехать просто невозможно.

Во-вторых, другой ответ предлагал использовать rsync и вы отклонили это предложение на основании

rsync работает медленно, так как ему приходится вычислять контрольную сумму файлов.

Это просто неправильно. Процитировать rsync страница руководства:

-c, --checksum

Это изменяет способ, которым rsync проверяет, были ли файлы изменены и нуждаются ли в передаче. Без этой опции rsync использует «быструю проверку», которая (по умолчанию) проверяет, совпадают ли размер каждого файла и время последней модификации между отправителем и получателем. Эта опция изменяет это для сравнения 128-битной контрольной суммы для каждого файла, имеющего соответствующий размер.

и

-I, --ignore-times

Обычно rsync пропускает любые файлы, которые уже имеют одинаковый размер и имеют одинаковую метку времени модификации. Эта опция отключает эту «быструю проверку», вызывая обновление всех файлов.

--size-only

Это изменяет алгоритм «быстрой проверки» rsync для поиска файлов, которые необходимо передать, изменяя его по умолчанию для передачи файлов с измененным размером или измененным временем последнего изменения на простой поиск файлов, размер которых изменился. Это полезно при запуске использования rsync после использования другой системы зеркалирования, которая может не сохранять точные метки времени.

и наконец

--existing пропустить создание новых файлов на приемнике

--ignore-existing пропустить обновление файлов, существующих на приемнике

То есть,

  • По умолчанию rsync не хеширует содержимое файла, чтобы узнать, изменился ли файл.
  • Вы можете сказать ему вести себя точно так же, как cp -n, то есть пропустить обновление файла, если он просто существует на удаленном компьютере.

Я бы рекомендовал использовать два экземпляра tar или cpio передается по каналу SSH, как в

$ tar -C src/path -cf - . | ssh user@server tar -C dst/path -xf -

Этот подход имеет то преимущество, что он использует «полный канал» с одним потоком данных (вы также можете | pv между ними, чтобы увидеть, как все идет, если вам нужна интерактивность) по сравнению с SSHFSSFTP), который выполняет много циклов обмена между сервером и клиентом.

Решающим моментом здесь является то, что SSH - это не просто «удаленный вход в систему», как многие люди предполагают, а скорее о запуске любая команда удаленно при подключении своих стандартных потоков ввода-вывода к локальному экземпляру клиента SSH.


Обратите внимание: если это происходит в защищенной локальной сети или другой контролируемой среде, лучше отказаться от SSH и использовать пару nc или socat экземпляры - прослушивающий на сервере и отправляющий на клиенте. Этот подход не требует затрат ЦП на шифрование данных, поэтому вы, скорее всего, будете ограничены вводом-выводом для любого из трех компонентов: исходной FS, сети и целевой FS.

Нет, в процессе копирования неразумно не перезаписывать файлы, скопированные другими процессами. Не рекомендуется выполнять несколько команд для копирования одних и тех же файлов / папок.

Иногда вы мало что можете сделать, когда исходная и целевая машины находятся слишком далеко, а сеть работает медленно. Вот Почта чтобы обсудить, почему SSHFS медленный.

Я предлагаю вам использовать rsync с участием avP флаги. Пример:

rsync -avP <Source>  <Destination>