https://www.opennet.me/openforum/vsluhforumID3/50321.html Вышел (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).<br><br>URL: http://www.gnu.org/software/tar/#releases<br>Новость: http://www.opennet.ru/opennews/art.shtml?num=20622<br> https://www.opennet.me/openforum/vsluhforumID3/50321.html#15 Fri, 06 Mar 2009 12:07:48 GMT &gt;- lzma медленее zip<br><br>При сжатии при том конкретно так медленнее.При распаковке - не на много, распаковка быстрая.<br><br>&gt;- lzma очень любит память (в случае больших словарей - это могут быть гигабайты,<br><br>Чудес не бывает ;)<br><br>&gt;- lzma сравним по эффективности с bzip2 и иногда его превосходит <br><br>Я бы сказал, "lzma обычно эффективнее bzip2 и зачастую порядочно его превосходит".Особенно с большими словарями и на повторяющихся данных.Найти набор данных где bzip2 с его ограничением так сказать "словаря" в 900 кило обыграет lzma с более крупным словарем - еще постараться надо.Сколько я ни прогонял экспериментов - типичная ситуация после пережатия из bz2 в lzma - это заметное уменьшение размера.<br><br>&gt;- lzma быстрее bzip2 (во всяком случае в те разы, что я <br>&gt;использовал bzip2 получал архив того же размера что и lzma 7Zip, <br>&gt;но делалась архивация дольше <br><br>Опять же. LZMA тормоз в упаковке (даже наверное более тормоз чем bz2 в зависимости от параметров) но зато быстр в распаковке.У алгоритмов на основе LZ распаковка по https://www.opennet.me/openforum/vsluhforumID3/50321.html#14 Fri, 06 Mar 2009 11:14:29 GMT ХЗ утилс это сильно<br> https://www.opennet.me/openforum/vsluhforumID3/50321.html#13 Fri, 06 Mar 2009 07:41:14 GMT Из личного опыта:<br>- lzma эффективнее zip<br>- lzma медленее zip<br>- lzma очень любит память (в случае больших словарей - это могут быть гигабайты, совсем большие словари доступны только в 64х ОС)<br>- lzma сравним по эффективности с bzip2 и иногда его превосходит<br>- lzma быстрее bzip2 (во всяком случае в те разы, что я использовал bzip2 получал архив того же размера что и lzma 7Zip, но делалась архивация дольше<br> https://www.opennet.me/openforum/vsluhforumID3/50321.html#12 Fri, 06 Mar 2009 06:08:37 GMT &gt;А как вы будите решать проблему многотомности? Порой приходится делать backup с <br>&gt;кусками определенного размера. <br><br>split'ом<br> https://www.opennet.me/openforum/vsluhforumID3/50321.html#10 Fri, 06 Mar 2009 04:29:02 GMT А как вы будите решать проблему многотомности? Порой приходится делать backup с кусками определенного размера.<br> https://www.opennet.me/openforum/vsluhforumID3/50321.html#7 Fri, 06 Mar 2009 02:15:53 GMT &gt;Феерично! Ыксперт во всём User294 уже жмёт жипеги!<br><br>Я их привел как пример.А вот тролль-ламоботы с лора наверное заранее знают что за файлы придется бэкапать.Путем телепатии наверное (хрена себе успехи биомеханики и роботостроения однако!).А так - не вижу вашего более компетентного и менее фееричного мнения.Я так понял что вы только троллить горазды, да?Ну да, это в отличие от дельного ответа не требует знаний и оно проще.Кто бы сомневался ;)<br><br>P.S. кстати если пять одинаковых жпегов сложить рядом и пройтись LZMA с достаточно большим словарем - есть шансы прилично сжать все это даже.Сжатие в этом случае выступит де-дупликатором файлов отловив тот факт что они идентичные.Изврат, но именно поэтому порой LZMA и может порядочно сделать zlib при сжатии. Берем 2 идентичных файла на 4 мега.Жмем zlib.Получаем ... понятно что - по сути сжатые копии файлов запишутся 2 раза (грубоватое приближение для tar но по размеру примерно так).Потому что словарь на 32Кб - не память а склероз, deflate просто забудет о том что по https://www.opennet.me/openforum/vsluhforumID3/50321.html#4 Thu, 05 Mar 2009 21:15:05 GMT &gt;помему лучше в squashfs если данных для бэкапа хотябы 500Mb <br><br>Смотря что подразумевать под "лучше".Если надо рандомный доступ к данным (для бэкапов это не всегда требуется, а если они на что-то типа стримера сливаются - это еще и технически не прокатит) - да, squashfs может и интересно.А если цель - минимальный размер бэкапа, тут squashfs с его разбивкой на блоки заведомо проиграет, иногда даже в разы - алгоритм сжатия может работать только в пределах блока.А то что соседний блок на 95% совпадает с текущим и можно было бы хранить в 20 раз меньше инфо о нем - ну ой, издержки технологии с разбивкой на блоки.<br> https://www.opennet.me/openforum/vsluhforumID3/50321.html#3 Thu, 05 Mar 2009 21:10:36 GMT &gt;кто-нибудь пробовал back'апить, сжимая в lzma? <br>&gt;Оно того стоит? <br><br>На больших объемах рыхлых данных LZMA может (если повезет) уделать zlib в разы (мой личный рекорд - один рыхлый бэкап сжатый 7zip оказался в 10 раз меньше чем он же в виде zip и gzip).Просто за счет бОльшего словаря ловится больше совпадающих данных на бОльшем расстоянии, которые deflate не замечает т.к. совпадения отстоят дальше чем размер словарика, который у deflate всего 32 кб что как правило мало для современных файлов(они крупнее и часть совпадений deflate не поймает).Зато LZMA тормознее намного и памяти больше надо при сжатии.И если данные жмутся плохо и среди них мало похожих файлов (например жмем тысячу разных жпегов) - выигрыш если и будет то небольшой а вот затраты времени - подрастут существенно.Соответственно, смотреть надо по конкретной ситуации.Чисто технически LZMA намного более современный и мощный алгоритм сжатия чем deflate, может использовать огромные словари (если памяти хватит :P) с соответствующим ростом эффективност https://www.opennet.me/openforum/vsluhforumID3/50321.html#2 Thu, 05 Mar 2009 20:46:47 GMT помему лучше в squashfs если данных для бэкапа хотябы 500Mb<br>