Можно ли сделать эту команду поиска и копирования быстрее?

Question

В настоящее время я использую следующую команду для копирования подмножества лог-файлов сотрудника в другое место для моих собственных записей и дальнейшего анализа.

find . -name '*somestring*' -type f -exec cp -v --update -i {} '//anetworkdrive/logfiles/'  \;

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

Если я бегу time find . -name '*somestring*' -type f в папках источника и назначения, он находит <1000 файлов в каждом месте, и это занимает около 0,2 с (реальное).

В сценарии, где ничего не изменилось ни с одного конца с момента последнего запуска, я бы подумал, что приведенная выше команда копирования не займет намного больше времени, чем одна только находка. find возвращает список файлов за <1 с, и я подумал, что cp --update тогда очень быстро проверит дату изменения обоих файлов (src, dest) и пропустит, если они совпадают.

Тем не менее, моя команда полного копирования теперь занимает почти целую минуту, задаваясь вопросом, делает ли она более подробное сравнение, чем просто дата модификации, например, полный diff или что-то еще.

Может кто-нибудь объяснить мне, почему приведенная выше команда занимает так много времени, даже когда ничего не изменилось?

И есть ли более быстрый способ сделать это? Будет ли быстрее передать результаты поиска в cp?

Благодарю.

Answer 1

Итак, основываясь на комментарии Даниэля Б. выше, я протестировал три метода.

Я проверил это на локальном диске для передачи локального диска, в котором find . -name '*somestring*' нашла 495 файлов, в среднем 5,8 МБ и 2,82 ГБ. Первый результат синхронизации для каждого метода - пустой каталог назначения, поэтому копируются все 495 файлов. Второй результат синхронизации - это место назначения, уже совпадающее с источником, поэтому файлы не копируются.

1 - Использование exec из команды find:

time find . -name '*somestring*' -type f -exec cp -v --update -i {} -t '../dst/'  \;
real    2m2.037s
real    0m35.043s

2 - Передача списка файлов напрямую в cp:

time find . -name '*somestring*' -type f -print0 | xargs -0 cp -v --update -t '../dst/'
real    1m42.354s
real    0m3.463s

3 - Использование rsync

time rsync -vh --update *somestring* '../dst/'
real    1m53.605s
real    0m2.300s

Так что в этой ситуации rsync основном связан с cp . Однако когда я вернулся к своему реальному приложению копирования из одного сетевого расположения в другое, я обнаружил, что rsync взял на себя инициативу. В моем реальном сценарии find по cp занял около 15 секунд, когда каталог dst уже соответствовал src, а rsync около 7 секунд.

Так rsync это!