Каково различие между различными системами “сжатия”?
Я всегда использовал TAR и ZIP для сжатия, но недавно я услышал о *.Z алгоритм сжатия. Это подняло вопрос для меня:
Со всеми этими системами сжатия, какой является лучшим для общего использования и сжатия?
Запуская несколько тестов, я обнаружил это tar, когда я обнаружил, действительно Едва ли сжимается (если явно не указано). Значение, для чего это хорошо по сравнению с другими методами сжатия?
Я уже знаю, что ZIP является наиболее широко используемой системой сжатия, но если я использую его вместо *.Z, *.7z, .tar, или .tar.<insert ending here>?
Сводка сообщения:
- Если я использую
*.tar,*.Z,*.7z,.tar, или.tar.<insert ending here>для лучшего сжатия? - Если плоскость
*.tarне сжимается, почему мы используем его?
Править: Не все алгоритмы позволяют хранить полномочий Linux (от того, что я изучил). Которые делают, и есть ли своего рода взлом (или сценарий), я мог использовать для хранения полномочий?
6 ответов
tar обозначает ленточный архив. Все, что это делает, упаковать файлы и их метаданные (полномочия, владение, и т.д.) в поток байтов, которые могут быть сохранены на ленточном накопителе (или файл) и восстановлены позже. Сжатие является совершенно отдельным вопросом, что Вы раньше передавали вывод по каналу через внешнюю утилиту для сжатия, если требуется этого. Tar GNU был достаточно хорош добавить переключатели, чтобы сказать ему автоматически пропускать вывод через соответствующую утилиту как ярлык.
Zip и 7z комбинирует архивацию и сжатие вместе в их собственный формат контейнера, и они предназначены для упаковки файлов в системе DOS/Windows, таким образом, они не хранят полномочия Unix и владение. Таким образом, если Вы хотите сохранить полномочия для надлежащих резервных копий, необходимо придерживаться tar. Если Вы планируете обмен файлами с пользователями Windows, то архивируете, или 7z хорошо. Фактическая zip алгоритмов сжатия и 7zip использование может использоваться с tar путем использования gzip и lzma соответственно.
lzma (иначе. *.xz), имеет одну из лучших степеней сжатия и довольно быстр при распаковке, делая его лучшим выбором в эти дни. Это делает однако, требует, чтобы тонна поршня и процессорное время сжалась. Почтенное gzip вполне немного быстрее при сжатии, так может использоваться, если Вы не хотите выделять так много процессорного времени. Это также имеет еще более быстрый вариант, названный lzop. bzip2 все еще довольно популярно, поскольку это в основном заменило gzip какое-то время, прежде чем 7zip/lzma появился, так как это получило лучшие степени сжатия, но впадает в немилость в эти дни, так как 7z/lzma быстрее при распаковке и получает лучшие степени сжатия. compress утилита, которая обычно называет файлы *.Z, является древней и давно забытой.
Одно из других важных различий между zip и tar - то, что zip сжимает данные в маленьких блоках, тогда как при сжатии файла tar Вы сжимаете все это сразу. Последний дает лучшие степени сжатия, но для извлечения единственного файла в конце архива, необходимо распаковать все это для получения до него. Таким образом формат zip лучше в извлечении единственного файла или два из крупного архива. 7z и dar позволяют Вам принимать решение сжать все это (названный "твердым" режимом) или маленькие блоки для легкого постепенного извлечения.
Детали алгоритмов вне темы here1, так как они ни в коем случае не характерны для Linux, уже не говоря о Ubuntu. Вы, однако, найдете некоторую хорошую информацию здесь.
Теперь на tar, поскольку Вы сказали, tar не и никогда не была программа сжатия. Вместо этого это - archiver; его основная цель состоит в том, чтобы сделать один большой файл из большого количества маленьких. Исторически это должно было упростить хранение на ленточных накопителях, отсюда имя: Ленточный архив.
Сегодня, основная причина для использования tar должен сократить число файлов в Вашей системе. Каждый файл в файловой системе Unix поднимает inode, чем больше файлов Вы имеете, тем меньше inodes доступный и когда у Вас заканчивается inodes, Вы больше не можете создавать новые файлы. Для помещения его просто тот же объем данных, сохраненный как, тысячи файлов поднимут больше жесткого диска, чем те те же файлы в единственном архиве tar.
Для иллюстрирования начиная с, это было оспорено в комментариях на моем 68G / раздел, у меня есть следующее количество общего количества, и используемый inodes (примите во внимание, что количество inode зависит от типа файловой системы и размера раздела):
Inode count: 393216
Free inodes: 171421
Если я теперь продолжаю пытаться создать больше файлов, чем у меня есть inodes:
$ touch {1..171422}
touch: cannot touch ‘171388’: No space left on device
touch: cannot touch ‘171389’: No space left on device
touch: cannot touch ‘171390’: No space left on device
touch: cannot touch ‘171391’: No space left on device
touch: cannot touch ‘171392’: No space left on device
touch: cannot touch ‘171393’: No space left on device
touch: cannot touch ‘171394’: No space left on device
touch: cannot touch ‘171395’: No space left on device
touch: cannot touch ‘171396’: No space left on device
touch: cannot touch ‘171397’: No space left on device
Никакое пространство? Но у меня есть загрузки пространства:
$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 5,8G 4,3G 1,2G 79% /
Как Вы видите выше, создание нескольких сотен тысяч пустых файлов быстро истощает мой inodes, и я больше не могу создавать новые. Если я был к tar они я смог бы начать создавать файлы снова.
Наличие меньшего количества файлов также значительно ускоряет файловую систему, ввод-вывод особенно на NFS смонтировал файловые системы. Я всегда смолю свои старые рабочие каталоги, когда проект закончен начиная с меньшего количества файлов я имею, более быстрые программы как find будет работать.
Существует большой ответ на Суперпользователе, который вдается в намного большее количество подробностей, но в дополнение к вышеупомянутому, другие основные причины почему tar все еще популярно, сегодня:
Эффективность: использование
tarпередавать по каналу через программу сжатия какgzipболее эффективно, так как это избегает создания промежуточных файлов.tarидет со всеми видами дополнительных свойств, функции, которые были разработаны по его долгой истории, которые делают ее особенно полезной для *, отклоняют резервные копии (думайте полномочия, принадлежность файла, способность передать данные по каналу прямо к STDOUT и по ссылке SSH...),Инерция. Мы привыкли к
tar. Безопасно предположить, что это будет доступно на любом *, отклоняют Вас, могло бы оказаться, использовал бы, который делает это очень портативным и удобным для исходного кода tarballs.
1 Это абсолютно верно и не имеет никакого отношения к тому, что я не знаю достаточно о них для объяснения :)
Существует две отличных, но связанных задачи. Упаковывание дерева файлов (включая имена файлов, структуру каталогов, полномочия файловой системы, владение и любые другие метаданные) в поток байтов называют, архивируя. Удаление дублирования в потоке байтов для создания меньшего потока байтов называют сжатием.
На Unix эти две операции разделяются с отличными инструментами для каждого. На большинстве других платформ (текущий и исторический) комбинированные инструменты выполняют и архивацию и сжатие.
(gzip и другие программы, которые подражают интерфейсу gzip часто, имеют опцию сохранить исходное имя файла в сжатом выводе, но это, наряду с CRC или другой проверкой для обнаружения повреждения, является единственными метаданными, которые они могут сохранить.)
Существуют преимущества для разделения сжатия от архивации. Архивация является определенной для платформы (сохранение необходимости метаданных файловой системы значительно различается), но реализация проста, в основном I/O-bound, и изменяется мало со временем. Сжатие платформенно независимо, но реализации являются зависящими от ЦП, и алгоритмы постоянно улучшаются для использования в своих интересах дополнительных ресурсов, которые современные аппаратные средства могут принести для влияния на проблему.
Самый популярный Unix archiver tar, хотя там существуют другие такой как cpio и ar. (Пакеты Debian ar архивы, в то время как cpio часто используется для inital электронных дисков.) tar или часто объединялся с инструментами сжатия такой как compress (.Z), gzip (.gz), bzip2 (.bz2) и xz (.xz), от самого старого до самого молодого, и не по совпадению от худшего до лучшего сжатия.
Создание a tar архив и сжатие его являются отличными шагами: компрессор ничего не знает о tar формат файла. Это означает что, извлекая единственный файл из сжатого tar архив требует распаковки всех предыдущих файлов. Это часто называют "солидным" архивом.
Аналогичным образом, так как tar является форматом "потоковой передачи" - требуемый, чтобы это было полезно в конвейере - в архиве tar нет никакого глобального индекса, и список содержания архива tar является столь же дорогим как извлечение его.
В отличие от этого, Zip и RAR и с 7 zip (самый популярный archivers на современных платформах Windows) обычно сжимают каждый файл отдельно и метаданные сжатия слегка если вообще. Это допускает дешевый список файлов в архиве и извлечении отдельных файлов, но означает, что дублирование между несколькими файлами в том же архиве не может быть использовано для увеличения сжатия. В то время как в общем сжатии уже-сжатого-файла не уменьшает размер файла далее, иногда Вы могли бы видеть zip-файл в рамках zip-файла: первое архивирование превратило много маленьких файлов в один большой файл (вероятно, с отключенным сжатием), который второе архивирование, затем сжатое как единственный объект.
Существует перекрестное опыление между отличающимися платформами и основными положениями: gzip по существу zipкомпрессор без его archiver, и xz по существу 7-zipкомпрессор без его archiver.
Существуют другие, специализированные компрессоры. Варианты PPM и их преемник ZPAQ оптимизированы для максимального сжатия без учета к потреблению ресурсов. Они могут легко уничтожить столько ЦП и RAM, сколько можно бросить в них, и распаковка является столь же налоговой как сжатие (для контраста, наиболее широко используемые инструменты сжатия асимметричны: распаковка является более дешевой, чем сжатие).
На другом конце спектра, lzo, snappy и LZ4 "легкие" компрессоры, разработанные для максимальной скорости и минимального потребления ресурсов, за счет сжатия. Они широко используются в файловых системах и других объектно-ориентированных памятях, но меньше как автономные инструменты.
Таким образом, который необходимо выбрать?
Архивация:
Так как Вы находитесь на Ubuntu нет никакой настоящей причины для использования чего-либо кроме tar для архивации, если Вы не пробуете к make-файлам, которые легко читаемы в другом месте.
zip твердо биться для повсеместности, но это не центрально Unix и не сохранит Ваши полномочия файловой системы и информацию о владении, и его испеченное - в сжатии вытеснено. С 7 zip и RAR (и ZPAQ) имеют более современное сжатие, но являются одинаково неподходящими к архивации файловых систем Unix (хотя нет ничего останавливающего Вас использующий их в качестве компрессоров); RAR является также собственным.
Сжатие:
Для максимального сжатия можно взглянуть на сравнительный тест, такой как огромный по http://mattmahoney.net/dc/text.html. Это должно дать Вам лучшее представление о включенных компромиссах.
Вы, вероятно, не хотите максимальное сжатие, все же. Это слишком дорого.
xz самый популярный инструмент сжатия общего назначения в современных системах Unix. Я верю с 7 zip, может считать xz файлы также, поскольку они тесно связаны.
Наконец: при архивации данных для чего-нибудь кроме краткосрочного устройства хранения данных, необходимо выбрать что-то открытый исходный код и предпочтительно широко распространенный, для уменьшения головных болей позже.
lzo, gz, b2, lzma (.lzma2 =.xz) "потоковые" компрессоры: они сжимают поток byes, который не знает и не заботится о файлах, каталогах и метаданных как полномочия. Необходимо использовать archiver как tar для связывания всех этих данных в поток байтов (файл tar) и сжатие это с компрессором. Если это данные из единственного файла, Вы заботитесь о, Вы могли также подать один только тот файл к одному из этих компрессоров.
Tar, cpio and pax archivers: они берут набор файлов и каталогов и кодируют данные и метаданные в единственном файле. tar является самым популярным и самым совместимым, хотя технические достоинства между этими тремя достаточно минимальны, что были религиозные войны об этом в течение рассвета времени.
7z и zip компрессоры И arcihvers: Тогда храните все данные и метаданные и сожмите его. Однако AFAICT, ни один из них не сохраняет полномочия Unix.
Zip использует тот же алгоритм, как gzip названный ВЫКАЧИВАЮТ. 7z использует lzma алгоритм
для чтения единственного файла из tar.gz и т.п., необходимо будет распаковать целый gz поток, пока достаточно файла tar не будет представлено так, можно извлечь его. Zip позволяет Вам сжиматься и вытаскивать каждый файл индивидуально. 7z может иметь любое поведение.
Степени сжатия и скорости: gzip и lzo имеют очень очень быстрые скорости сжатия и распаковки, но низкие степени сжатия. Также не требуется большой памяти для сжатия. gzip немного медленнее и дает немного лучшую степень сжатия, чем lzo.
Это настолько быстро, это может быть быстрее, чтобы считать gz или lzo сжатый файл от диска и распаковать его на лету вместо того, чтобы читать несжатый файл непосредственно из диска.
LZMA (xz) дает превосходное сжатие на общих данных, но берет очень долго, чтобы сжать и распаковать наряду со взятием существенного количества памяти для сжатия.
bz2 раньше был высоким предпочтительным алгоритмом сжатия, но впал в немилость, как это и медленнее, чем lzma и занимает больше времени, чтобы сжать и распаковать. Однако для бесспорный виды данных (последовательности ДНК, файлы с очень большими выполнениями того же байта и т.д.) bzip2 могут победить все остальное без всяких усилий. Как пример, я когда-то должен был сжать файл на 4 ГБ 1's, и b2 уменьшил меня до нескольких 10-х Кбита, в то время как lzma занял несколько 10-х MBS, если я помню правильно.
Для особенно больших файлов можно использовать rzip. Это сначала смотрит на избыточные данные в блоках 900 МБ шириной, кодирует их, и затем передает данные bzip2 (не действительно, но те же алгоритмы используются).
Эффект? Намного быстрее, чем xz, lzma или bzip2, и по моему опыту его конкуренты степени сжатия тот из lzma. Это - пожиратель ресурсов RAM, все же.
gzip долгое время был традиционным наиболее известным и наиболее используемым алгоритмом сжатия. (zlib — это библиотека, которая его реализует.)
bzip2 был изобретен позже и предлагался как алгоритм, который часто может давать лучшие коэффициенты сжатия, чем gzip на обычном данные, однако, он был более медленным (затратным на вычисления) по сравнению с gzip.
bzip2 в качестве альтернативы gzip в последнее время в основном устарел из-за современных алгоритмов.
Например, xz -0 указано на странице руководства (man xz) как «иногда быстрее, чем gzip -9 при гораздо лучшем сжатии». .
Существуют также другие современные алгоритмы, которые хорошо подходят для сжатия и распаковки «на лету» (помимо gzip), поскольку имеют высокую пропускную способность (скорость) и, следовательно, популярны для использования в ядре. для файловой системы, блочного устройства и сжатия памяти (а также для быстрого сжатия обычных файлов). Сравнение
lzo, lz4 и zstd хорошо представлено на https://github.com/lz4/lz4:
| Compressor | Ratio | Compression | Decompression |
| ---------- | ----- | ----------- | ------------- |
| memcpy | 1.000 | 13700 MB/s | 13700 MB/s |
|**LZ4 default (v1.9.0)** |**2.101**| **780 MB/s**| **4970 MB/s** |
| LZO 2.09 | 2.108 | 670 MB/s | 860 MB/s |
| QuickLZ 1.5.0 | 2.238 | 575 MB/s | 780 MB/s |
| Snappy 1.1.4 | 2.091 | 565 MB/s | 1950 MB/s |
| [Zstandard] 1.4.0 -1 | 2.883 | 515 MB/s | 1380 MB/s |
| LZF v3.6 | 2.073 | 415 MB/s | 910 MB/s |
| [zlib] deflate 1.2.11 -1| 2.730 | 100 MB/s | 415 MB/s |
|**LZ4 HC -9 (v1.9.0)** |**2.721**| 41 MB/s | **4900 MB/s** |
| [zlib] deflate 1.2.11 -6| 3.099 | 36 MB/s | 445 MB/s |
[zlib]: http://www.zlib.net/
[Zstandard]: http://www.zstd.net/
So , как отмечено в https://en.wikipedia.org/wiki/LZ4_(compression_algorithm), lz4 "дает немного худшую степень сжатия, чем LZO алгоритм... . Однако скорости сжатия аналогичны LZO..., а скорости декомпрессии могут быть значительно выше, чем у LZO".Также, как видно из таблицы, zstd-1 обычно дает более высокую степень сжатия, чем lz4 и lzo, но более низкую скорость; что касается распаковки, zstd -1 сжатые данные распаковываются быстрее, чем lzo, но медленнее, чем lz4.
Как видно из диаграммы на https://facebook.github.io/zstd/, zstd -3 может быть разумным выбором (если Я не ошибаюсь, это значение по умолчанию при использовании btrfs с zstd): сжимает лучше, чем gzip (zlib) в любом режиме и быстрее.
