Ситуация с архиваторами в Линуксе и вообще

Как компрессор xz сейчас лучше, хотя аналога libz/libbz2 нет, но это интересно только тем, кто хочет сразу скомпрессированный поток данных писать/читать.

squashfs рулит сейчас.

tar.gz

tar - убогая скорость

gz не - работает с данными, большими 4GB. 2016 год, на минуточку. См. man gzip «BUGS»

Как оно до сих пор живо, не представляю. Надо везде, где можно, отказываться от tar и gzip и рассказывать друзьям :)

bzip2

А еще bzip2 имеет многопоточный как компрессор, так и декомпрессор, что в некоторых случаях просто киллерфича, и все lzo и xz идут нах, т.к. первый хуже сжимает, а второй не имеет многопоточного декомпрессора

Справедливости ради, "pixz supports parallel decompression". Надо попробовать

tar.gz — ограничение на длину файла в 100 (!) символов

Не уверен, надо проверить

https://www.gnu.org/software/tar/manual/html_chapter/tar_8.html

Проверил, создал файл с именем poooo(o)ooooony.txt (всего 150 символов)

Заархивировал

tar -cvzf

Использовал bsdtar 2.8.3

gz не - работает с данными, большими 4GB.

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

Надо везде, где можно, отказываться от tar и gzip и рассказывать друзьям :)

В принципе отказаться от gzip можно было тогда, когда появился bzip2 (там ещё была драма с нарушением патентов по поводу этой самой двойки, что тоже задержало, скажем так, прогресс), но многие к тому времени уже заценили возможность встраивания libz в программы для чтения/записи скомпрессированного потока данных и аналог для bzip2 появился весьма не сразу и был в какой-то мере хаком. Так что не случилось полной замены тогда и сейчас не случится.

tar - убогая скорость

????? Скорость tar равна де факто скорости чтения/записи на носитель данных. Это фактически просто склейка файлов.

Тут никто не упомянул возможность делать инкрементальные архивы. А это умеет делать только tar / dar. Поправьте, если не так.
Еще dar умеет при создании архива НЕ сжимать определенные типы файлов. P.S. индекс в dar есть

Не существует. В принципе обычно задачи сохранения всех атрибутов не стоит, поэтому хватает zip или 7z. А когда стоит — tar + 7z.

ладно еще сами архиваторы, так ведь и морды нормальной нет, ничего уровня 7-zip под линуксы еще не придумали

Тот же вопрос тебе.

«pixz supports parallel decompression». Надо попробовать

Работает.

Поменял в скрипте 7zip на pixz, проблем нет. Индексы есть, но их похоже никто не читает.
Весь прикладной софт лезет распаковывать, в том числе, например, Ark.

Подтверждаю. Вчера переносил rootfs с харда на хард. tar сказал, что путь к /var/lib/docker/<длинный хеш контейнера>/<длинный путь внутри контейнера> слишком длинный и будет обрезан.

И да, быстрый доступ к файлам архива тебе никто не обещал, так как хоть сколько-нибудь особого смысла в этом нет.

Ага, это же так тяжело кинуть в заголовок архива листинг всех файлов.

А B1 кто нибудь пробовал?

в самой популярной Unix-системе

А при чём тут GNU/Linux?

Вот краткий тест. Потом, может, оформлю

Исходные данные: 65214 файлов, общий размер 6.3ГБ, файлы разные: исходники, бинарники, архивы, большие и маленькие. Обычная такая рабочая директория.

Таблица: формат/компрессор; результирующий размер; время, затраченное на сжатие (минуты:секунды); время, затраченное на вывод списка файлов в архиве (минуты:секунды.сотые_доли).

tar.gz         4.8 GB    6:30 min.    1:26    min.
zip            4.8 GB    6:04 min.    0:00.33 min.
rar            4.5 GB   16:32 min.    0:00.67 min.
pixz           4.5 GB   15:01 min.    0:00.09 min.
squash lzma    4.3 GB   10:03 min.    0:00.19 min.
squash xz      4.2 GB   10:49 min.    0:00.20 min.
squash lzo     4.5 GB    6:23 min.    0:00.11 min.

i7-5600U, HDD, 12GB ram. Опции: дефолт

Смотрим на tar.gz - видим фигу. И это не считая, что gzip -l data.tar.gz показывает ratio -124.3% (как раз тот самый баг из мана). Гнилье, короче, не стоит и юзать.

Squash lzo - очень достойно. К тому же, фичей является нахождение дубликатов, что полезно в случае рабочей директории с пачками распакованных исходников либ и т.п. Отсюда разница в размерах squash xz и pixz.

Pixz - если нужна некая совместимость с tar.

Отсюда разница в размерах squash xz и pixz

Часть разницы будет ещё набегать из-за многопоточности pixz.
Исходные данные нарезаются на число потоков, соответствующее имеющимся ядрам цпу, и каждый работает только в пределах своего куска данных.

Чем лучше удалось распараллелить, тем хуже конечный результат.

P.S. Тоже не ожидал, что lzo покажет такой результат. Всегда воспринимал его в первую очередь как *быстрый* компрессор.

Я только слышал что в НТФС что-то поменяли по поводу длин имени файла и собственно пути.

Угу, в десяточке можно будет вручную отключить ограничение на 256 символов в пути.

Ты не путай архиватор tar с компрессором gzip. Учи матчасть.

Ты не с той ноги встал? Ну можешь продолжать юзать архиватор tar , выводящий список файлов за полторы минуты, вместо других архиваторов, выводящих список файлов за время < секунды. Компрессия тут только иллюстрирует, что gzip так же устарел и убог, как и tar. Их обоих нужно закопать, и как минимум, никакие новые файлы ими не упаковывать.

Учи матчасть.

Это поможет ускорить вывод списка файлов tar.gz ? Может поможешь тогда?

Да не — это просто значит, что ты не очень то и разбираешся в теме. Ситуация с архивацией не исчерпывается только твоими сценариями.

Намекаю на подумать: а) архиваторы, которые не сохраняют информацию о группе и пользователе не нужны; б) кроме дисков существуют ещё такая фигня, как ленты и их ещё весьма долго использовать будут чисто потому, что они сильно дешевле в ряде сценариев; в) есть сценарии, где писать/читать скомпрессированные нужно из программы, так что отсутствие библиотеки по примеру libz/libbz2 весьма расстраивает; г) да и просто компрессия того, что подаётся на stdin весьма удобная вещь; д) расход ЦПУ в ряде случаев определяющ; е) наличие компрессора «из-коробки» везде, включая очень старые инсталляции 10+ лет, тоже имеет преимущество.

Но да, как компрессор, в данный момент bzip2 фактически по всем позициям превосходит gzip, хоть он тоже не фонтан. А вот tar, как архиватору, пока единой замены нет.

Это поможет ускорить вывод списка файлов tar.gz ?

Да, но не так как вы думаете. Это поможет вам: а) не путать компрессор и архиватор б) не заниматься глупостями, а заниматься архивацией

Вы бравируете своим буквоедством «архиватор» - «компрессор», как студент, впервые с этим столкнувшийся и разобравшийся, познав сокральные ззнания. Перестаньте, не всем здесь по 15 лет, не опускайтесь до этого уровня. Вы явно невнимательно читаете, поэтому уточню, я не считаю, что вам 15 лет.

Ленты - это узкая ниша. И для них, так уж и быть, пусть используется tar, или любое другое специальное решение. Но я сомневаюсь, что ленточные решения каких нибудь HP или IBM используют tar. Могу ошибаться, не отказался бы от конкретики.

И отриньте сейчас всякие сжатие потока и stdin\out. Об этом другой разговор.

Меня интересует только архивы файлов и их сжатие. Так же, как и ТС. И это очень распространенный юзкейз. Столкнувшись с большими данными и необходимостью безболезненно сделать tar czf, как привыкли 10-20-30 лет назад, получаем кучу вылезающих косяков: неработающая многопоточность компрессии-декомпрессии, убогость архиватора, кривость формата gzip. А немного поискав решение, понимаешь, что за кучей якобы хорошо отточенных инструментов, использующихся десятилетиями, стоит куча костылей и граблей; а инструментов то и нет. Но объемы растут, сейчас десятками терабайт уже не удивишь и некоторых домашних пользователей.

Надо перестать уже пихать везде этот tar, сжатый компрессорами. Перестать писать статьи и упоминать на форумах. Хочется написать tar c...? Сразу бить себя по рукам. И gzip аналогично.

Да возьмите kernel.org .

# Оригинал
$ /usr/bin/time tar tf linux-4.6.4.tar.xz >/dev/null
6.47user 0.42system 0:06.55elapsed 105%CPU (0avgtext+0avgdata 67836maxresident)k
0inputs+0outputs (0major+16687minor)pagefaults 0swaps

# Перепакованный в squash+xz
$ /usr/bin/time unsquashfs -l linux-4.6.4.squash-xz >/dev/null
0.13user 0.00system 0:00.14elapsed 99%CPU (0avgtext+0avgdata 9724maxresident)k
0inputs+0outputs (0major+2767minor)pagefaults 0swaps

6 сек. vs 0.14 сек.

И не надо говорить, что список файлов в архиве - это неважно. Это - важно, это как раз и есть раздражающие тормоза, когда заходим в архив в файловом менеджере и бац: система в ступоре, нужно ждать десяток секунд, а то и больше, и можно идти покурить. Только что бы посмотреть содержимоей архива. И ради чего это? Ради того, что бы можно было сказать «вот tar, он используется уже полвека, а всё еще не портит борозды?» Да ни стоит это того. И как можно с этим спорить, я не понимаю; как можно отстаивать решение, недостатки которого явно видны в численном виде.

Вам нравится ждать 6 секунд тупки системы на элементарной операции, когда есть работающие решения? Сомневаюсь.

е) наличие компрессора «из-коробки» везде, включая очень старые инсталляции 10+ лет, тоже имеет преимущество.

Отдельным пунктом замечу. Я прихожу к клиенту, там стоит 2008 года сервер с центосом5, массив данных на 40 TB, и нужно срочно отдельные куски посжимать и заархивировать. Принцип «компрессор из коробки» не сработал. Это я про tar и gzip.

С другой стороны, устанавливается из репозитария p7zip, это тоже можно считать искоробочным решением. Но это нифига не tar, а как раз противоположность tar, то, куда надо уйти от тара. Потому что tar не актуален, не универсален, и его высокая упоминаемость и распространность сейчас - историческая ошибка. То же касается и gzip. Да, у них есть свои ниши, но это не коробочное решение, не универсальное.

А универсального решения сейчас нет. Есть приближения к нему, и это далеко не tar.gz

tar.xz мой выбор - под вендой если что есть чем распаковать

Есть новые форматы типа dar или xar.

XAR: https://code.google.com/archive/p/xar/downloads последнее изменение 2007 год

Чтобы прочитать список файлов он фактически распаковывает архив на лету.

Поскольку это разные тулзы, они делают разную работу. gz или xz пофигу что сжимать - просто какой то blob или файл созданный tar из других файлов

XAR: https://code.google.com/archive/p/xar/downloads последнее изменение 2007 год

Справедливости ради: xar-1.6.1 вышел Sep 18, 2012;

https://github.com/mackyle/xar/releases

Другое дело, что с теперешними linux-headers он не скомпилится, но есть патч от Void linux, помогающий.

В тоже время xar — единственное средство открыть на лолитоксе маковский pkg пакетоархив.