Я монтирую удаленный сервер по ssh (используя sshfs). Я хочу скопировать большое количество файлов с удаленного сервера на локальный:
cp -rnv /mounted_path/source/* /local_path/destination
Команда запускает рекурсивное копирование, которое не перезаписывает существующие файлы. Но процесс копирования довольно медленный. Замечу, что он не копирует файлы по порядку. Итак, мой вопрос: могу ли я ускорить процесс копирования, открыв несколько терминалов и выполнив ту же команду выше? Достаточно ли умен процесс копирования, чтобы не перезаписывать файлы, скопированные другими процессами?
… Чтобы ответить на исходный вопрос, как указано…
Здесь нужно обсудить две вещи.
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
между ними, чтобы увидеть, как все идет, если вам нужна интерактивность) по сравнению с SSHFS
(и SFTP
), который выполняет много циклов обмена между сервером и клиентом.
Решающим моментом здесь является то, что SSH - это не просто «удаленный вход в систему», как многие люди предполагают, а скорее о запуске любая команда удаленно при подключении своих стандартных потоков ввода-вывода к локальному экземпляру клиента SSH.
Обратите внимание: если это происходит в защищенной локальной сети или другой контролируемой среде, лучше отказаться от SSH и использовать пару nc
или socat
экземпляры - прослушивающий на сервере и отправляющий на клиенте. Этот подход не требует затрат ЦП на шифрование данных, поэтому вы, скорее всего, будете ограничены вводом-выводом для любого из трех компонентов: исходной FS, сети и целевой FS.
Нет, в процессе копирования неразумно не перезаписывать файлы, скопированные другими процессами. Не рекомендуется выполнять несколько команд для копирования одних и тех же файлов / папок.
Иногда вы мало что можете сделать, когда исходная и целевая машины находятся слишком далеко, а сеть работает медленно. Вот Почта чтобы обсудить, почему SSHFS медленный.
Я предлагаю вам использовать rsync
с участием avP
флаги. Пример:
rsync -avP <Source> <Destination>