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