Вышел (http://www.gnu.org/software/tar/#releases) релиз GNU Tar 1.22. В новой версии представлено два заметных новшества: - добавлена поддержка формата сжатия XZ (http://tukaani.org/xz/) (опция --xz), реализованным в пакете XZ Utils (http://tukaani.org/xz/), представляющем собой следующий этап развития пакета LZMA Utils (http://tukaani.org/lzma/), известного также как LZMA Utils 5;- действие опции "--no-recursive" (запрещение рекурсивного просмотра поддиректорий) расширено и на режим инкрементального бэкапа (--incremental).URL: http://www.gnu.org/software/tar/#releases
Новость: http://www.opennet.me/opennews/art.shtml?num=20622
кто-нибудь пробовал back'апить, сжимая в lzma?
Оно того стоит?
помему лучше в squashfs если данных для бэкапа хотябы 500Mb
>помему лучше в squashfs если данных для бэкапа хотябы 500MbСмотря что подразумевать под "лучше".Если надо рандомный доступ к данным (для бэкапов это не всегда требуется, а если они на что-то типа стримера сливаются - это еще и технически не прокатит) - да, squashfs может и интересно.А если цель - минимальный размер бэкапа, тут squashfs с его разбивкой на блоки заведомо проиграет, иногда даже в разы - алгоритм сжатия может работать только в пределах блока.А то что соседний блок на 95% совпадает с текущим и можно было бы хранить в 20 раз меньше инфо о нем - ну ой, издержки технологии с разбивкой на блоки.
>кто-нибудь пробовал back'апить, сжимая в lzma?
>Оно того стоит?На больших объемах рыхлых данных LZMA может (если повезет) уделать zlib в разы (мой личный рекорд - один рыхлый бэкап сжатый 7zip оказался в 10 раз меньше чем он же в виде zip и gzip).Просто за счет бОльшего словаря ловится больше совпадающих данных на бОльшем расстоянии, которые deflate не замечает т.к. совпадения отстоят дальше чем размер словарика, который у deflate всего 32 кб что как правило мало для современных файлов(они крупнее и часть совпадений deflate не поймает).Зато LZMA тормознее намного и памяти больше надо при сжатии.И если данные жмутся плохо и среди них мало похожих файлов (например жмем тысячу разных жпегов) - выигрыш если и будет то небольшой а вот затраты времени - подрастут существенно.Соответственно, смотреть надо по конкретной ситуации.Чисто технически LZMA намного более современный и мощный алгоритм сжатия чем deflate, может использовать огромные словари (если памяти хватит :P) с соответствующим ростом эффективности сжатия.
>Феерично! Ыксперт во всём User294 уже жмёт жипеги!Я их привел как пример.А вот тролль-ламоботы с лора наверное заранее знают что за файлы придется бэкапать.Путем телепатии наверное (хрена себе успехи биомеханики и роботостроения однако!).А так - не вижу вашего более компетентного и менее фееричного мнения.Я так понял что вы только троллить горазды, да?Ну да, это в отличие от дельного ответа не требует знаний и оно проще.Кто бы сомневался ;)
P.S. кстати если пять одинаковых жпегов сложить рядом и пройтись LZMA с достаточно большим словарем - есть шансы прилично сжать все это даже.Сжатие в этом случае выступит де-дупликатором файлов отловив тот факт что они идентичные.Изврат, но именно поэтому порой LZMA и может порядочно сделать zlib при сжатии. Берем 2 идентичных файла на 4 мега.Жмем zlib.Получаем ... понятно что - по сути сжатые копии файлов запишутся 2 раза (грубоватое приближение для tar но по размеру примерно так).Потому что словарь на 32Кб - не память а склероз, deflate просто забудет о том что повторные данные были к моменту когда они начнутся.Берем LZMA с словарем 4 мега или более. Жмем им.Вуаля.Получаем сжатую копию 1-го экземпляра и компактные ссылки на то что это уже было.Выиграли примерно вдвое.Даже если сам по себе файл жмется крайне погано.
Из личного опыта:
- lzma эффективнее zip
- lzma медленее zip
- lzma очень любит память (в случае больших словарей - это могут быть гигабайты, совсем большие словари доступны только в 64х ОС)
- lzma сравним по эффективности с bzip2 и иногда его превосходит
- lzma быстрее bzip2 (во всяком случае в те разы, что я использовал bzip2 получал архив того же размера что и lzma 7Zip, но делалась архивация дольше
>- lzma медленее zipПри сжатии при том конкретно так медленнее.При распаковке - не на много, распаковка быстрая.
>- lzma очень любит память (в случае больших словарей - это могут быть гигабайты,
Чудес не бывает ;)
>- lzma сравним по эффективности с bzip2 и иногда его превосходит
Я бы сказал, "lzma обычно эффективнее bzip2 и зачастую порядочно его превосходит".Особенно с большими словарями и на повторяющихся данных.Найти набор данных где bzip2 с его ограничением так сказать "словаря" в 900 кило обыграет lzma с более крупным словарем - еще постараться надо.Сколько я ни прогонял экспериментов - типичная ситуация после пережатия из bz2 в lzma - это заметное уменьшение размера.
>- lzma быстрее bzip2 (во всяком случае в те разы, что я
>использовал bzip2 получал архив того же размера что и lzma 7Zip,
>но делалась архивация дольшеОпять же. LZMA тормоз в упаковке (даже наверное более тормоз чем bz2 в зависимости от параметров) но зато быстр в распаковке.У алгоритмов на основе LZ распаковка по жизни сильно быстрее упаковки из-за принципов работы.Bzip2 не такой тормоз в упаковке но и по скорости распаковки - не ахти (он если не ошибаюсь BWT юзает, с совсем иными чем у LZ-based свойствами в плане соотношения скоростей упаковки и распаковки).
А как вы будите решать проблему многотомности? Порой приходится делать backup с кусками определенного размера.
>А как вы будите решать проблему многотомности? Порой приходится делать backup с
>кусками определенного размера.split'ом
ХЗ утилс это сильно