Comments 22
Канонично через пайпы с указанием желаемой степени компрессии для файлов
tar cvf - файлы | gzip -9c > my.tar.gz
Или с указанием ленточного устройства, если без
tar cfv /dev/st0 файлы
Или nst0 если надо без перемотки
На aix mksysb делал загрузочные ленточки...
Не раскрыта тема tar cf | tar xf для копирования директорий с сохранением владельцев (хотя часто в таких ситуациях лучше rsync).
современные версии tar распознают алгоритм компрессии автоматически. Иными словами, достаточно tar xf имя.tar.gz.
Век живи век учись...
Да, tarpipe иногда полезен. В чистом виде не часто используется, т.к. команда cp позволяет как сохранять атрибуты файлов, так и корректно обрабатывать специальные файлы (в зависимости от реализации, конечно). К тому же для сохранения владельцев нужно запускать tar от root-а.
Чаще, на мой взгляд, tarpipe применяется при передаче по сети, например, при помощи netcat. Создаётся сетевой канал и с одной стороны распаковывается поток, а с другой запаковывать tar-ом.
Не раскрыта тема tar cf | tar xf для копирования директорий с сохранением владельцев (хотя часто в таких ситуациях лучше rsync).
А так же грабли, по этому и близким вопросам. Например, если подать на вход tar просто список имен файлов, но не подать каталоги, в которых эти файлы содержатся (такое получается, скажем по 'find . -type f') -- то в получившемся архиве какой-то информации, которую обычно связывают с файлами (дата и время создания/изменения что ли) -- не будет. Что приводит к некоторому удивлению при распаковке.
«Нет, ты не понял. Ты эту команду запомнил? Мне приходится «гуглить» каждый раз, когда требуется сделать архив.»
Вспоминаю твитерский мнемонический лайфхак для запоминания флагов: голосом немца
Compres Ze File
eXtract Ze File
«Нет, ты не понял. Ты эту команду запомнил? Мне приходится «гуглить» каждый раз, когда требуется сделать архив.»
Вот и выросло поколение, которое гуглит мануалы в интернете, вместо локального "man tar".
Мне кажется, у XKCD есть более удачный, чем приведённый в статье, комикс на эту тему :)
Но да, по-моему man и правда неплохо компенсирует чудаковатый синтаксис архаичного tar...
А теперь забудьте про это старье, и откройте для себя zstd.
С опцией -O
И еще: указывая после тара или самостоятельно зстд без доп. ключей вы используете по-умолчанию два потока и одно ядро, и теряете в скорости сжатия очень сильно, потому что он сверхэффективно распараллеливается. Обязательно добавляйте -Tx где х - максимальное количество ядер ЦП которое вы можете ему отдать без ущерба для работы системы.
Спасибо, что напомнили про zstd. В заметке, кстати, его отметил. Опцию -O не нахожу в документации на установленную у меня версию zstd.
Что касается количества потоков, которые создаёт zstd при своей работе. Если действительно часто приходится сжимать большие объёмы данных, то вместо явного указания опций zstd удобнее установить переменные окружения ZSTD_NBTHREADS и ZSTD_CLEVEL, например, в пользовательском профиле. По умолчанию, кстати, zstd работает не в 2 потока, а в в зависимости от количества процессорных ядер от 1 до 4.
На мой взгляд, важность опций zstd для указания количества потоков и коэффициента сжатия переоценена. Провёл небольшой эксперимент эксперимент (измерения проводил несколько раз):
❯ sudo du -sh /usr
2,1G /usr
❯ =time -p sudo tar -C / --zstd -cf /dev/shm/1.tar.zst usr
real 5.54
user 0.00
sys 0.00
❯ ll /dev/shm/1.tar.zst
-rw-r--r-- 1 root root 917M апр 8 21:38 /dev/shm/1.tar.zst
❯ =time -p sudo ZSTD_NBTHREADS=8 tar -C / --zstd -cf /dev/shm/1.tar.zst usr
real 5.47
user 0.00
sys 0.00
❯ =time -p sudo ZSTD_CLEVEL=19 ZSTD_NBTHREADS=8 tar -C / --zstd -cf /dev/shm/1.tar.zst usr
real 167.41
user 0.00
sys 0.00
❯ ll /dev/shm/1.tar.zst
-rw-r--r-- 1 root root 810M апр 8 21:44 /dev/shm/1.tar.zstС маленьким коэффициентом сжатия количество потоков zstd не оказывают существенного влияния на общую скорость работы. С высоким коэффициентом сжатия архив становится меньше примерно на 11%, но время сжатия возрастает прям существенно, более чем в 30 раз. На маленьких объёмах данных практической разницы не будет. На больших объёмах данных надо будет подбирать параметры компрессии, это займёт значительно больше времени, чем само сжатие. И в любом случае нет гарантии, что удастся существенно увеличить коэффициент сжатия. Обычному пользователю редко это всё может понадобиться.
Если у Вас другие экспериментальные данные, то поделитесь, пожалуйста.
По умолчанию, кстати, zstd работает не в 2 потока, а в зависимости от количества процессорных ядер от 1 до 4.
Это откуда и где? Согласно мануалу по умолчанию используется 2 потока — один для собственно [де]компрессии, другой для I/O. Если указать --single-thread, то всё будет в одном потоке. А если указано -T0, то задействуются все физические ядра.
Это согласно мануалу:
ZSTD_NBTHREADS can be used to set the number of threads zstd will attempt to use during compression. If the value of ZSTD_NBTHREADS is not a valid unsigned integer, it will be ignored with a warning message. ZSTD_NBTHREADS has a default value of max(1, min(4, nbCores/4)),
А ещё я посмотрел htop. На четырёхядерной системе zstd активно работает в один поток, а на восьмиядерной — в два. Наверное, активно работающие потоки это как раз те потоки, которые используются для компрессии. Что соответствует приведённой формуле.
Так и я сверху сослался на мануал :) Вот этот же пункт из zstd 1.5.2:
ZSTD_NBTHREADS can be used to set the number of threads zstd will
attempt to use during compression. If the value of ZSTD_NBTHREADS is
not a valid unsigned integer, it will be ignored with a warning
message. ZSTD_NBTHREADS has a default value of (1), and is capped at
ZSTDMT_NBWORKERS_MAX==200. zstd must be compiled with multithread
support for this to have any effect.
А ещё ZSTD_NBTHREADS не обязана существовать.
А ещё вот это:
На четырёхядерной системе zstd активно работает в один поток
если zstd запускался без --single-thread, противоречит тому, что сказано в доступных мне мануалах:
--single-thread: Does not spawn a thread for compression, use a
single thread for both I/O and compression. In this mode,
compression is serialized with I/O, which is slightly slower.
Из описания как бы вполне очевидно следует, что без этого ключа (и без -T#) zstd взлетает двумя тредами.
В версии 1.5.5 всё точно так же. Никакого подобия приведённой тобой формуле. Что у тебя за zstd, на какой платформе?
Прямо цифры замеров я не сохранил, но могу точно сказать, что гоняя копирование через интернет-канал на неполные 100mbit 120 гб Mysql базы, с предварительным сжатием tar+gzip я понял, что не укладываюсь ни в какое разумное время, с zstd и параметрами по-умолчанию только-только влезаю в maintanance window, и наконец с zstd на 8 ядер xeon gold 6242 из 10 доступных системе и сжатием 9 архив получается гораздо компактнее, а время сжатия уменьшилось в разы и в окно обслуживания все действия влезают с хорошим запасом. Насчет опции -o я возможно ошибся с регистром, в убунтовой версии она просто указывает выходной файл и вроде бы позволяет несколько исходных файлов упаковать в один архив и обойтись вообще без tar, но это не точно.
На файлах меньше гига конечно не особо важно, что там за компрессор и с какими опциями. Если только вам не надо его потом прокачать через неустойчивый 3g канал со скоростью меньше мегабита. И обратите внимание, на чем у вас лежат исходные файлы и целевой архив, скорее всено у вас узкое место это дисковая подсистема, и там никакие опции почти ничего не изменят. В моем случае это массивы из корпоративных ssd уровня samsung 1643a read-optimized raid10 sas24 или, как минимум, 15000 rpm enterprise hdd raid10 в самых старых системах.
по-умолчанию два потока и одно ядро
Это откуда? Про одно ядро.
zstd не занимается планированием cores, там нет ни строчки кода, хоть как-то влияющего на CPU affinity mask.
Ну на практике-то эти потоки видимо ложатся на одно ядро планировщиком ОС. Я не знаю, каковы предпочтения операционок в этом смысле, использую только Linux, и лет 20 не работаю с вариациями unix, bsd-like и т. П. Но на debian-based & redhat-based при запуске zstd одно ядро в htop занято на 100%, остальные расслабляются и почти ничего не делают. Куда там какой поток ушел, я не смотрел.
tar --exclude={'*/ненужная_папка1,'*/ненужная_папка2','*~','*/Trash'} -cJf /path_for_archive/username_archive-$(date +%Y%m%d).tar.xz /home/username/При первом использовании долго не мог понять, почему не работает. Аргумент f должен быть в конце. Оказывается.
Ещё одна заметка про tar