Как скопировать в несколько потоков?

Question

[Виктор Таран]

Задача скопировать 54Млн файлов
занято уже 95% диска
Написал скрипт который по отдельности сжимал папки и копировал на удалённый сервер там распаковывал.
Но проблема в том что даже для 1 папки места нет, а у некоторых и у подкаталогов такая же ситуация.
В общем слишком много исключений в циклах пришлось делать и тд.
Если же копировать в 1 поток то 320 часов
Собственно поскольку при копирование файлов пролемма не в размере а в количестве, то есть идея копировать скажем в 100 потоков, тем самым сократив до 3 часов, что вполне себе уже жизнеспособно I-O nvme дисков это вообще никак не потревожит.
по идее что-то через find (с макс деп3) и xargs
может кто подскажет как лучше сделать, в идеале примерчик.
Все это веселье заправляется работой 24\7 и потом мне нужно будет расхождения отдельно скопировать в общем желательно чтоб если-что то все это было еще и повторяемо.

Comments

[FanatPHP]

вообще-то это rsync

Answer 1

[Saboteur]

Написал скрипт который по отдельности сжимал папки и копировал на удалённый сервер там распаковывал

Так сжимайте сразу на удаленный сервер

tar cvfz - mydirectory|ssh user@remote_server "cd target_directory;tar xvfz -"

Или даже проще будет запустить несколько экземпляров rsync в фоне через xargs или parallel

Comments

[Виктор Таран]

как ни странно этого вполне хватило, скорость передачи под 60мб сек
я так базу забирал с сервера с 100% занятым /
но что-то думал что он темп создает в оперативке.
и сей понт пройдет только с папкой меньше чем места в памяти, однакож нет все работает норм

[TheAthlete]

Нашел еще такой вариант:

tar -czf - /some/file | ssh [e-mail] tar -xzf - -C /destination

т.е. использование -C вместо 'cd destination'

[shurshur]

В наборе опций f должна быть последней, так как у неё есть параметр - файл (в данном случае -, что означает stdin/stdout в зависимости от контекста).

Ничего в "temp" оно не создаёт. Если буфера ввода-вывода везде полные, оно просто подождёт их освобождения.

[Saboteur]

shurshur, нет, tar достаточно умный, чтобы понять что f опция может быть в середине списка опций.
Но да, это так автор tar сделал. Если по POSIX то не должно работать. Просто tar появился раньше, чем стандартизировался POSIX ;)

[shurshur]

Saboteur, это странно, у меня на подобное ругалось, когда я допускал подобные ошибки. Возможно, я тогда сталкивался с tar другой космической системы :)

[Виктор Таран]

shurshur, Saboteur, shurshur,
И того перенос занял 6 часов что вполне в разумных приделах, учитывая что импорт бд идет уже 2 час ;)

[Saboteur]

Виктор Таран,

но что-то думал что он темп создает в оперативке.

ну как так, tar был написан во времена, когда оперативки было меньше чем сейчас кеш даже в сетевушке =)

Answer 2

[Армянское Радио]

Что-то такое, с использованием GNU Parallel

find . -print0 | parallel -0 -j10 cp {} destdir

Источник

Answer 3

[Владимир]

Не совсем понимаю чем мешает недостаток места на источнике.
Что делать - зависит от структуры каталогов и распределения данных в них, например сделать список каталогов 2го или 3его или Нного уровня и на каждый каталог запустить свой rsync.

Answer 4

[hint000]

Просто направление, без примера.
Сформировать текстовый файл (на 54 млн. строк) со списком файлов.
Разделить его на 100 файлов по 540 тыс. строк; грубо, количество строк будет разное, но в данном случае не принципиально: split -n l/10 имя_файла
В цикле (по 100 файлам) запустить фоном процессы копирования, принимающие список из файла.