Почему *.tar.gz все еще встречается чаще, чем *.tar.xz?
Всякий раз, когда я вижу некоторые исходные пакеты или двоичные файлы, сжатые с помощью GZip, я задаюсь вопросом, есть ли еще причины отдавать предпочтение gz по сравнению с xz (исключая путешествие во времени до 2000), экономия алгоритма сжатия LZMA значительна, а декомпрессия не намного хуже, чем GZIP.
9 ответов
"Наименьший общий знаменатель". Сохраненное дополнительное пространство редко стоит потери совместимости. Большинство встроенных систем Linux имеют gzip, но не xz. Много старой системы. Gnu Tar, который является отраслевым стандартом, поддерживает флаги -z обрабатывать через gzip, и -j обрабатывать через bzip2, но некоторые старые системы не поддерживают -J флаг для xz, что означает, что он требует двухэтапной операции (и много дополнительного дискового пространства для несжатого .tar если вы не используете синтаксис |tar xf - - о которых многие люди не знают.) Кроме того, распаковка полной файловой системы около 10 МБ из tar.gz на встроенный ARM занимает около 2 минут и не является проблемой. Понятия не имею о xz но bzip2 занимает около 10-15 минут. Определенно не стоит экономить пропускную способность.
Окончательный ответ - доступность, со вторичным ответом цели. Причины, по которым XZ не так подходит, как Gzip:
Встраиваемые и унаследованные системы с гораздо большей вероятностью испытывают недостаток доступной памяти для распаковки архивов LZMA/LZMA2, таких как XZ. Например, если XZ может сбрасывать 400 КиБ (против Gzip) из пакета, предназначенного для маршрутизатора OpenWrt, какая польза от незначительной экономии места, если у маршрутизатора 16 МБ ОЗУ? Похожая ситуация возникает с очень старыми компьютерными системами. Можно было бы посмеяться над мыслью о загрузке и компиляции последней версии Bash на древнем SparcStation LX с 32 МБ оперативной памяти, но это происходит.
Такие системы обычно имеют медленные процессоры, и время декомпрессии может быть очень высоким. Дополнительные три секунды для распаковки вашего Core i5 могут быть очень длинными на ядре ARM 200 МГц или microSPARC 50 МГц. Сжатие Gzip чрезвычайно быстро на таких процессорах по сравнению со всеми лучшими методами сжатия, такими как XZ или даже Bzip2.
Gzip в значительной степени универсально поддерживается каждой UNIX-подобной системой (и почти каждой не-UNIX-подобной системой), созданной за последние два десятилетия. Доступность XZ гораздо более ограничена. Сжатие бесполезно без возможности распаковать его.
Более высокое сжатие занимает много времени. Если время сжатия важнее, чем степень сжатия, Gzip превосходит XZ. Честно говоря, lzop намного быстрее, чем Gzip, и все еще хорошо сжимается, поэтому приложениям, которым необходимо максимально быстрое сжатие и не требующим вездесущности Gzip, следует обратить внимание на это. Я обычно быстро перетасовываю папки через доверенное соединение с локальной сетью с помощью таких команд, как "tar -c * | lzop -1 | socat -u - tcp-connect:192.168.0.101:4444", и Gzip можно использовать аналогичным образом по гораздо более медленной ссылке (т.е. делать то же самое, что я только что описал через туннель SSH через Интернет).
Теперь, с другой стороны, существуют ситуации, когда сжатие XZ значительно превосходит:
Отправка данных по медленным ссылкам. Исходный код ядра Linux 3.7 на 34 МБ меньше в формате XZ, чем в формате Gzip. Если у вас очень быстрое соединение, выбор XZ может означать экономию одной минуты времени загрузки; на дешевом DSL-соединении или сотовом соединении 3G это может сократить время загрузки на час или более.
Сокращение резервных копий. Сжатие исходного кода для Apache httpd-2.4.2 с помощью "gzip-9" против "xz -9e" приводит к архиву XZ, который составляет 62,7% размера архива Gzip. Если такая же сжимаемость существует в наборе данных, который вы в настоящее время храните как архивы.tar.gz стоимостью 100 ГиБ, преобразование в архивы.tar.xz приведет к сокращению колоссальных 37,3 ГиБ резервных копий. Копирование всего этого набора данных резервного копирования на жесткий диск USB 2.0 (максимальная скорость передачи около 30 МБ / с) в виде сжатых данных займет 55 минут, но сжатие XZ сделает резервное копирование на 20 минут меньше. Предполагая, что вы будете работать с этими резервными копиями в современной настольной системе с достаточным количеством ресурсов процессора и единовременной скоростью сжатия, не является серьезной проблемой, поскольку использование XZ-сжатия обычно имеет больше смысла. Зачем копаться в дополнительных данных, если вам не нужно?
Распространение больших объемов данных, которые могут быть сжимаемыми. Как упоминалось ранее, исходный код Linux 3.7 составляет 67 МБ для.tar.xz и 101 МБ для.tar.gz; несжатый исходный код составляет около 542 МБ и является почти полностью текстовым. Исходный код (и текст в целом), как правило, легко сжимаются из-за избыточности содержимого, но компрессоры, такие как Gzip, работающие с гораздо меньшим словарем, не могут воспользоваться преимуществами избыточности, выходящими за рамки их размера словаря.
В конечном итоге все сводится к четырехстороннему компромиссу: сжатый размер, скорость сжатия / распаковки, скорость копирования / передачи (чтение данных с диска / сети) и доступность компрессора / декомпрессора. Выбор в значительной степени зависит от вопроса "что вы планируете делать с этими данными?"
Также проверьте этот связанный пост, из которого я узнал некоторые вещи, которые я повторяю здесь.
От автора утилиты сжатия Lzip:
Xz имеет сложный формат, частично специализированный на сжатии исполняемых файлов и предназначенный для расширения проприетарными форматами. Из четырех протестированных здесь компрессоров xz является единственным чуждым понятию Unix "делать одно и делать это хорошо". Он менее подходит для обмена данными и совсем не подходит для долгосрочного архивирования.
В общем, чем сложнее формат, тем менее вероятно, что он может быть декодирован в будущем. Но формат xz, так же как и его печально известный предшественник lzma-only, специально разработан плохо. Xz копирует почти все недостатки gzip, а затем добавляет еще, например, хрупкие целые числа переменной длины. Всего один переворот в бите 7 любого байта одного целого числа переменной длины, и весь поток xz падает, как карточный домик. Использование xz для чего-либо, кроме сжатия недолговечных исполняемых файлов, не рекомендуется.
Не истолковывай меня неправильно. Я очень благодарен Игорю Павлову за изобретение / открытие LZMA, но xz - это третья попытка его последователей воспользоваться популярностью 7zip и заменить gzip и bzip2 неподходящими или плохо разработанными форматами. В частности, позорно, что поддержка lzma-only была реализована как в GNU, так и в Linux.
Я сделал свой собственный тест для установочного образа Linux на 1.1GB vmdk:
rar =260MB comp= 85s decomp= 5s
7z(p7z)=269MB comp= 98s decomp=15s
tar.xz =288MB comp=400s decomp=30s
tar.bz2=382MB comp= 91s decomp=70s
tar.gz =421MB comp=181s decomp= 5s
все уровни сжатия на макс., процессор Intel I7 3740QM, память 32 ГБ 1600, источник и место назначения на RAM-диске
Обычно я использую rar или 7z для архивирования обычных файлов, таких как документы.
а для архивации системных файлов я использую.tar.gz или.tar.xz с помощью file-roller или tar с параметрами -z или -J вместе с --preserve для непосредственного сжатия с помощью tar и сохранения разрешений (также альтернативно.tar.7z или.tar.rar можно использовать)
Обновление: поскольку tar сохраняет только обычные разрешения, но не ACL, в любом случае также можно использовать обычные разрешения.7z плюс резервное копирование и восстановление, а также ACL вручную через getfacl и sefacl, что представляется наилучшим вариантом как для архивирования файлов, так и для резервного копирования системных файлов, поскольку он будет заполнен сохранить разрешения и ACL, имеет контрольную сумму, проверку целостности и возможность шифрования, только недостатком является то, что p7zip не везде доступен
Честно говоря, я только познакомился с форматом.xz из учебного материала. Поэтому я просто использовал его git-репо для тестирования. Это git://git.free-electrons.com/training-materials.git, и я также составил три обучающих слайда. Общий размер каталога составляет 91M, со смесью текстовых и двоичных данных.
Вот мой быстрый результат. Может быть, люди все еще предпочитают tar.gz просто потому, что он гораздо быстрее сжимается? Лично я даже использую обычную смолу, когда в сжатии не так много преимуществ.
[02:49:32]wujj@WuJJ-PC-Linux /tmp $ time tar czf test.tgz training-materials/
real 0m3.371s
user 0m3.208s
sys 0m0.128s
[02:49:46]wujj@WuJJ-PC-Linux /tmp $ time tar cJf test.txz training-materials/
real 0m34.557s
user 0m33.930s
sys 0m0.372s
[02:50:31]wujj@WuJJ-PC-Linux /tmp $ time tar cf test.tar training-materials/
real 0m0.117s
user 0m0.020s
sys 0m0.092s
[02:51:03]wujj@WuJJ-PC-Linux /tmp $ ll test*
-rw-rw-r-- 1 wujj wujj 91944960 2012-07-09 02:51 test.tar
-rw-rw-r-- 1 wujj wujj 69042586 2012-07-09 02:49 test.tgz
-rw-rw-r-- 1 wujj wujj 60609224 2012-07-09 02:50 test.txz
[02:56:03]wujj@WuJJ-PC-Linux /tmp $ time tar xzf test.tgz
real 0m0.719s
user 0m0.536s
sys 0m0.144s
[02:56:24]wujj@WuJJ-PC-Linux /tmp $ time tar xf test.tar
real 0m0.189s
user 0m0.004s
sys 0m0.108s
[02:56:33]wujj@WuJJ-PC-Linux /tmp $ time tar xJf test.txz
real 0m3.116s
user 0m2.612s
sys 0m0.184s
По той же причине люди в Windows (r) используют zip-файлы вместо 7zip, а некоторые по-прежнему используют rar вместо других форматов... Или mp3 используется в музыке вместо aac+ и так далее.
Каждый формат имеет свои преимущества, и люди используют его, чтобы придерживаться решения, которое они узнали, когда начали использовать компьютер. Добавьте к этому обратную совместимость и высокую пропускную способность + ГБ или ТБ пространства на жестких дисках, и преимущества более высокого сжатия не будут такими уж важными.
gz поддерживается везде и хорош для переносимости.
xz новее и теперь так же широко или хорошо поддерживается. Это сложнее, чем gzip с большим количеством опций сжатия.
Это не единственная причина, по которой люди не всегда используют xz. Сжатие xz может занять очень много времени, а не тривиальное время, поэтому, даже если оно может дать превосходные результаты, его не всегда можно выбрать. Еще одним недостатком является то, что он может использовать много памяти, особенно для сжатия. Чем больше вы хотите сжать элемент, тем дольше это занимает, и это экспоненциально с убывающей отдачей.
Однако на уровне сжатия 1 для больших двоичных элементов в моем опыте xz может давать гораздо меньшие результаты за меньшее время, чем zlib на уровне 9. Иногда это может быть очень существенным отличием, в то же время, как zlib, xz может создать файл это половина размера файла zlib.
bzip2 находится в аналогичной ситуации, однако у xz есть гораздо более высокие преимущества и сильное окно, где он работает значительно лучше со всех сторон.
Да, у меня возникла мысль о том, что в наши дни первоначальный вопрос можно перефразировать как "почему tar.gz более распространен, чем tar.lz" (поскольку lz кажется, сжать немного лучше, чем xz, xz считается плохим выбором для архивирования, хотя и предлагает некоторые приятные функции, такие как произвольный доступ). Я полагаю, что ответом является "импульс", к которому привыкли люди, хорошая поддержка библиотек и т. Д. Введение lz может означать, что xz будет расти не так быстро и сейчас, FWIW...
Однако, как говорится, lz, кажется, распаковывается медленнее, чем xz, и на горизонте появляются новые вещи, такие как Brotli, поэтому неясно, что произойдет с точки зрения популярности... но мне показалось, что несколько файлов.lz в диком FWIW...
Также одним важным моментом для gzip является то, что он совместим с rsync/zsync. Это может быть огромным преимуществом в отношении пропускной способности в случаях. LZMA/bzip2/xz не поддерживает rsync и, вероятно, не будет поддерживать его в ближайшее время.
Одной из характеристик LZMA является то, что он использует тихое большое окно. Чтобы сделать его дружественным к rsync/zsync, нам, вероятно, понадобится уменьшить это окно, что ухудшит его производительность сжатия.