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

684
sudosnake

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

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

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

3
Я бы просто пошел с rsync Arkadiusz Drabczyk 7 лет назад 3
@ArkadiuszDrabczyk Спасибо за отзыв, почему вы выбрали `rsync`? sudosnake 7 лет назад 0
1. У меня плохой опыт работы с `scp` для копирования большого количества данных - я пробовал один раз, и он вылетел. 2. если соединение было остановлено, rsync не будет копировать все с самого начала, а только файлы, которые еще не были скопированы. 3. rsync работает как локально, так и поверх ssh, так что вы можете использовать один инструмент с тем же опции Arkadiusz Drabczyk 7 лет назад 1
«Я не уверен, является ли это оптимальным решением для копирования такого большого количества файлов». Я думаю, что «оптимальные» результаты для максимальной скорости зависят от некоторых факторов. Например, Reiserfs, как известно, довольно хорошо поддерживал множество маленьких файлов. Таким образом, вы можете получить разные результаты в зависимости от того, какую файловую систему (или ОС) вы используете. Лучшим вариантом может быть: прекратить попытки переноса большого количества маленьких файлов, но поместить их в 1 архивный файл, вероятно, tar наиболее совместим и поддерживает метаданные Unix, а затем передать один файл. Использование Unix трубопроводов может быть гладким, но надоедливым, если возникают проблемы.) TOOGAM 7 лет назад 0

1 ответ на вопрос

1
styrofoam fly

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

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

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

Похожие вопросы