Оптимальная команда Linux для копирования большого количества файлов

Это тема, на которую я не смог найти однозначного ответа, или, по крайней мере, один с хорошим объяснением того, почему одно решение лучше другого. Допустим, у меня есть два локальных диска, один с файлами для копирования, один пустой. Обратная связь не обязательна, но оптимальная производительность с несколькими оговорками.

Структура файла с одной точки вниз должна быть согласованной. Например, файлы могут храниться в каталоге, в xкотором xон находится /my_drive_a/to_copy/files/x/- однако, когда я копирую его /my_drive_b/, я бы хотел, чтобы он был структурирован только /files/снизу. Так что результат может выглядеть примерно так /my_drive_b/files/x/.
Передача файлов не будет одинаковой каждый раз, поэтому подобная функция rsyncможет не иметь преимуществ перед подобной функцией cp.
Количество файлов будет в тысячах, хотя все они небольшие.
Данные должны быть скопированы и сохранены my_drive_a.

Моя первоначальная мысль будет просто делать cp -R /my_drive_a/to_copy/files/x/ /my_drive_b/files/x/. Опять же, имея ограниченный опыт работы с функциями копирования в Linux, я не уверен, является ли это оптимальным решением для копирования такого большого количества файлов.

— sudosnake
источник

Я бы просто пошел сrsync

— Аркадиуш Драбчик

@ArkadiuszDrabczyk Спасибо за отзыв, почему бы вы выбрали rsync?

— Судоснейка

1. У меня плохой опыт scpкопирования большого количества данных - я пробовал один раз, и он потерпел крах. 2. если соединение было прервано rsync, не будет копироваться все с самого начала, а только файлы, которые еще не были скопированы 3. rsyncработает как локально, так и более, sshпоэтому вы можете использовать один инструмент с одинаковыми параметрами

— Arkadiusz Drabczyk

«Я не уверен, является ли это оптимальным решением для копирования такого большого количества файлов». Я думаю, что «оптимальные» результаты для максимальной скорости зависят от некоторых факторов. Например, Reiserfs, как известно, довольно хорошо поддерживал множество маленьких файлов. Таким образом, вы можете получить разные результаты в зависимости от того, какую файловую систему (или ОС) вы используете. Лучшим вариантом может быть: прекратить попытки переноса большого количества маленьких файлов, но поместить их в 1 архивный файл, вероятно, tar наиболее совместим и поддерживает метаданные Unix, а затем передать один файл. Использование Unix трубопроводов может быть гладким, но надоедливым, если возникают проблемы.)

— TOOGAM

Просто иди с cp. coreutilsхорошо оптимизированы и будут работать отлично. За исключением --archiveфлага, рассмотрите возможность использования --sparse=never, если вы прогнозируете, что нет редких файлов. Это затмит cpи сэкономит время.

Почему нет rsync? Он попытается проанализировать файлы, отсортировать их (см. «ПОРЯДОК СОРТИРОВКИ ПЕРЕДАЧИ» man rsync), и будет очень сложно распечатать полезную информацию о ходе работы, не создавая серьезных препятствий для всего процесса. Хотя некоторые из его параметров могут быть отключены, некоторые являются обязательными и приведут к замедлению времени выполнения.

В зависимости от размера ваших данных может быть быстрее скопировать весь диск (например /dev/sda) с помощью программ, таких как ddили ddrescue, но трудно сказать, когда эта опция будет быстрее.

— пенополистирол летать
источник