Почему *.tar.gz все еще гораздо чаще, чем *.tar.xz?

Ответ 1

"Самый низкий общий знаменатель". Дополнительное свободное пространство редко стоит интероперабельности. Большинство встроенных систем Linux имеют gzip, но не xz. Много старой системы. Gnu Tar, который является отраслевым стандартом, поддерживает флагов -z для обработки через gzip, и -j для обработки через bzip2, но некоторые старые системы не поддерживают -j для xz, то есть для этого требуется двухэтапная операция (и много дополнительного дискового пространства для несжатого .tar, если вы не используете синтаксис |tar xf -), о котором многие люди не знают Кроме того, разжатие полной файловой системы размером около 10 МБ от tar.gz на встроенной ARM занимает около 2 минут и на самом деле не проблема. Никакая подсказка о xz, а bzip2 занимает около 10-15 минут. с сохраненной полосой.

В любом случае, нынешняя "современная альтернатива", в которой вы жертвуете мощью процессора в пользу дискового пространства (... которая по-прежнему редко приветствуется, - пропускная способность и дисковое пространство дешевы, и люди ненавидят, когда системы останавливаются из-за некоторые обновления работают в фоновом режиме) - это bzip2.

Ответ 2

Конечным ответом является доступность со вторичным ответом цели. Причины, по которым XZ не обязательно подходят для Gzip:

• Встраиваемые и устаревшие системы с большей вероятностью не имеют достаточной доступной памяти для распаковки архивов LZMA/LZMA2, таких как XZ. В качестве примера, если XZ может сэкономить 400 KiB (против Gzip) пакета, предназначенного для маршрутизатора OpenWrt, что хорошего в экономии места, если у маршрутизатора 16 Мбайт ОЗУ? Аналогичная ситуация возникает и с очень старыми компьютерными системами. Можно было бы насмехаться над мыслью о загрузке и компиляции последней версии Bash на старом SparcStation LX с 32 МБ ОЗУ, но это происходит.

• Такие системы обычно имеют медленные процессоры, а время нарастания декомпрессии может быть очень высоким. Три секунды для декомпрессии на вашем Core i5 могут быть сильно длинными на 200 МГц ARM-сердечнике или 50 МГц microSPARC. Сжатие Gzip чрезвычайно быстро работает на таких процессорах по сравнению со всеми лучшими методами сжатия, такими как XZ или даже Bzip2.

• Gzip почти повсеместно поддерживается каждой UNIX-подобной системой (и почти каждой не-UNIX-подобной системой), созданной за последние два десятилетия. Доступность XZ намного ограничена. Сжатие бесполезно без возможности его распаковать.

• Более высокое сжатие занимает много времени. Если время сжатия более важно, чем степень сжатия, Gzip превосходит XZ. Честно говоря, lzop намного быстрее, чем Gzip, и все еще сжимает все в порядке, поэтому приложения, которые требуют максимально возможного сжатия, и не требуют повсеместности Gzip, должны смотреть на это. Я регулярно перетасовываю папки по доверенному соединению LAN с такими командами, как "tar -c * | lzop -1 | socat -u-tcp-connect: 192.168.0.101: 4444", а Gzip можно использовать аналогично по гораздо более медленной ссылке ( т.е. делать то же самое, что я только что описал через туннель SSH через Интернет).

Теперь, с другой стороны, бывают ситуации, когда сжатие XZ значительно превосходит:

• Отправка данных по медленным ссылкам. Исходный код ядра Linux 3.7 на 32 Мбайт меньше в формате 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 мегабайт/сек), поскольку данные Gzipped будут занимать 55 минут, но сжатие XZ сделает резервное копирование на 20 минут меньше. Предполагая, что вы будете работать с этими резервными копиями на современной настольной системе с большим количеством мощности процессора, а одноразовая скорость сжатия не является серьезной проблемой, использование сжатия XZ обычно имеет больше смысла. Зачем перетаскивать дополнительные данные, если вам это не нужно?

• Распространение больших объемов данных, которые могут быть сильно сжимаемыми. Как уже упоминалось, исходный код Linux 3.7 - 67 MiB для .tar.xz и 101 MiB для .tar.gz; несжатый исходный код составляет около 542 мегабайт и почти полностью текст. Исходный код (и текст в целом), как правило, сильно сжимаются из-за избыточности содержимого, но компрессоры, такие как Gzip, которые работают с гораздо меньшим словарем, не могут использовать избыточность, выходящую за пределы их размера словаря.

В конечном итоге все возвращается к четырехстороннему компромиссу: сжатый размер, скорость сжатия/декомпрессии, скорость копирования/передачи (чтение данных с диска/сети) и доступность компрессора/декомпрессора. Выбор сильно зависит от вопроса "что вы планируете делать с этими данными?"

Также проверить этот связанный пост, из которого я узнал некоторые из вещей, которые я повторяю здесь.

Ответ 3

Я сделал свой собственный бенчмарк по установке Linux vmdk 1.1GB Linux:

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 с помощью файла-ролика или tar с параметрами -z или -J вместе с -preserve для сжатия с помощью tar и сохранения разрешений (также альтернативно .tar.7z или .tar.rar можно использовать)

update: поскольку tar в любом случае сохраняет только обычные разрешения, а не ACL, также можно использовать простой .7z плюс резервное копирование и восстановление разрешений и ACL вручную через getfacl и sefacl, что, по-видимому, является лучшим вариантом для архивации файлов или резервного копирования системных файлов, он будет полностью сохранять разрешения и списки ACL, имеет контрольную сумму, проверку целостности и возможности шифрования, только недостатком является то, что p7zip недоступен везде

Ответ 4

Честно говоря, я просто узнаю формат .xz из учебного материала. Поэтому я просто использовал репозиторий git, чтобы выполнить тест. git git://git.free-electron.com/training-materials.git, и я также составил три учебных слайда. Общий размер каталога - 91 М, со смесью текстовых и двоичных данных.

Вот мой быстрый результат. Может быть, люди по-прежнему предпочитают tar.gz просто потому, что гораздо быстрее сжимаются? Я лично даже использую простой tar, когда в сжатии не так много преимуществ.

[02:49:32][email protected] /tmp $ time tar czf test.tgz training-materials/

real    0m3.371s
user    0m3.208s
sys     0m0.128s
[02:49:46][email protected] /tmp $ time tar cJf test.txz training-materials/

real    0m34.557s
user    0m33.930s
sys     0m0.372s
[02:50:31][email protected] /tmp $ time tar cf test.tar training-materials/

real    0m0.117s
user    0m0.020s
sys     0m0.092s
[02:51:03][email protected] /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][email protected] /tmp $ time tar xzf test.tgz

real    0m0.719s
user    0m0.536s
sys     0m0.144s
[02:56:24][email protected] /tmp $ time tar xf test.tar

real    0m0.189s
user    0m0.004s
sys     0m0.108s
[02:56:33][email protected] /tmp $ time tar xJf test.txz

real    0m3.116s
user    0m2.612s
sys     0m0.184s

Ответ 5

От автора утилиты сжатия Lzip:

Xz имеет сложный формат, частично специализированный в сжатии исполняемых файлов и предназначенных для расширения по форматным форматам. Из здесь протестированы четыре компрессора, xz - единственный иностранец Unix концепция "делать одно и делать это хорошо". Это тем меньше подходящих для совместного использования данных, и вообще не подходят для долгосрочных архивирование.

В целом, чем сложнее формат, тем менее вероятно, что он может быть расшифрованы в будущем. Но формат xz, как и его печально известный предшественник lzma-alone, специально плохо разработан. Xz копирует почти все дефекты gzip, а затем добавляет еще несколько, как хрупкие целые числа переменной длины. Только один бит-флип в бит 7 любого байта одно целое целое число переменной и весь поток xz рушится как карточный домик. Использование xz для чего угодно, кроме сжатие недолговечных исполняемых файлов нецелесообразно.

Не интерпретируй меня неправильно. Я очень благодарен Игорю Павлову за изобретать/открывать LZMA, но xz - третья попытка его последователей, чтобы воспользоваться популярностью 7zip и заменить gzip и bzip2 с несоответствующими или плохо разработанными форматами. В частности, постыдно, что поддержка lzma-alone была реализована как в GNU и Linux.

http://www.nongnu.org/lzip/lzip_benchmark.html

Ответ 6

По той же причине люди в Windows (r) используют zip файлы вместо 7zip, а некоторые по-прежнему используют rar вместо других форматов... Или mp3 используется в музыке, а не aac + и т.д.

Каждый формат имеет преимущества, и люди используют, чтобы придерживаться решения, которое они узнали, когда начали использовать компьютер. Добавьте это к обратной совместимости и быстрой пропускной способности + ГБ или ТБ пространства на жестких дисках, а преимущества более высокого сжатия не будут актуальны.

Ответ 7

gz поддерживается везде и хороша для переносимости.

xz является более новым и теперь широко или хорошо поддерживается. Он более сложный, чем gzip с большим количеством параметров сжатия.

Это не единственная причина, по которой люди не всегда могут использовать xz. xz может потребовать очень много времени, чтобы сжать, а не тривиальное количество времени, поэтому, даже если оно может произвести превосходные результаты, оно не всегда может быть выбрано. Еще одна слабость заключается в том, что он может использовать много памяти, особенно для сжатия. Чем больше вы хотите сжать элемент, тем дольше это займет, и это будет экспоненциально с уменьшающейся отдачей.

Однако при уровне сжатия 1 для больших двоичных элементов в моем опыте xz часто может давать гораздо меньшие результаты за меньшее время, чем zlib на уровне 9. Это иногда может быть очень значительной разницей, в то же время, что и zlib, xz может создайте файл размером в половину размера файла zlib.

bzip2 находится в аналогичной ситуации, однако xz имеет гораздо более высокие преимущества и сильное окно, где он работает значительно лучше всех вокруг.

Ответ 8

Также важным для gzip является то, что он совместим с rsync/zsync. Это может быть огромным преимуществом в отношении пропускной способности в случаях. LZMA/bzip2/xz не поддерживает rsync и, вероятно, не будет поддерживать его в ближайшее время.
Одной из характеристик LZMA является то, что он использует тихое большое окно. Чтобы сделать его rsync/zsync удобным, нам, вероятно, нужно будет уменьшить это окно, что ухудшит его производительность сжатия.