| |
| |
| 3.4, User294 (ok), 00:15, 06/03/2009 [^] [^^] [^^^] [ответить]
| +/– | |
>помему лучше в squashfs если данных для бэкапа хотябы 500Mb
Смотря что подразумевать под "лучше".Если надо рандомный доступ к данным (для бэкапов это не всегда требуется, а если они на что-то типа стримера сливаются - это еще и технически не прокатит) - да, squashfs может и интересно.А если цель - минимальный размер бэкапа, тут squashfs с его разбивкой на блоки заведомо проиграет, иногда даже в разы - алгоритм сжатия может работать только в пределах блока.А то что соседний блок на 95% совпадает с текущим и можно было бы хранить в 20 раз меньше инфо о нем - ну ой, издержки технологии с разбивкой на блоки.
| | |
|
| 2.3, User294 (ok), 00:10, 06/03/2009 [^] [^^] [^^^] [ответить]
| +/– |
>кто-нибудь пробовал back'апить, сжимая в lzma?
>Оно того стоит?
На больших объемах рыхлых данных LZMA может (если повезет) уделать zlib в разы (мой личный рекорд - один рыхлый бэкап сжатый 7zip оказался в 10 раз меньше чем он же в виде zip и gzip).Просто за счет бОльшего словаря ловится больше совпадающих данных на бОльшем расстоянии, которые deflate не замечает т.к. совпадения отстоят дальше чем размер словарика, который у deflate всего 32 кб что как правило мало для современных файлов(они крупнее и часть совпадений deflate не поймает).Зато LZMA тормознее намного и памяти больше надо при сжатии.И если данные жмутся плохо и среди них мало похожих файлов (например жмем тысячу разных жпегов) - выигрыш если и будет то небольшой а вот затраты времени - подрастут существенно.Соответственно, смотреть надо по конкретной ситуации.Чисто технически LZMA намного более современный и мощный алгоритм сжатия чем deflate, может использовать огромные словари (если памяти хватит :P) с соответствующим ростом эффективности сжатия.
| | |
| |
| |
| Часть нити удалена модератором |
| 4.7, User294 (ok), 05:15, 06/03/2009 [^] [^^] [^^^] [ответить]
| +/– | |
>Феерично! Ыксперт во всём User294 уже жмёт жипеги!
Я их привел как пример.А вот тролль-ламоботы с лора наверное заранее знают что за файлы придется бэкапать.Путем телепатии наверное (хрена себе успехи биомеханики и роботостроения однако!).А так - не вижу вашего более компетентного и менее фееричного мнения.Я так понял что вы только троллить горазды, да?Ну да, это в отличие от дельного ответа не требует знаний и оно проще.Кто бы сомневался ;)
P.S. кстати если пять одинаковых жпегов сложить рядом и пройтись LZMA с достаточно большим словарем - есть шансы прилично сжать все это даже.Сжатие в этом случае выступит де-дупликатором файлов отловив тот факт что они идентичные.Изврат, но именно поэтому порой LZMA и может порядочно сделать zlib при сжатии. Берем 2 идентичных файла на 4 мега.Жмем zlib.Получаем ... понятно что - по сути сжатые копии файлов запишутся 2 раза (грубоватое приближение для tar но по размеру примерно так).Потому что словарь на 32Кб - не память а склероз, deflate просто забудет о том что повторные данные были к моменту когда они начнутся.Берем LZMA с словарем 4 мега или более. Жмем им.Вуаля.Получаем сжатую копию 1-го экземпляра и компактные ссылки на то что это уже было.Выиграли примерно вдвое.Даже если сам по себе файл жмется крайне погано.
| | |
|
|
| 2.13, Konwin (??), 10:41, 06/03/2009 [^] [^^] [^^^] [ответить]
| +/– |
 Из личного опыта:
- lzma эффективнее zip
- lzma медленее zip
- lzma очень любит память (в случае больших словарей - это могут быть гигабайты, совсем большие словари доступны только в 64х ОС)
- lzma сравним по эффективности с bzip2 и иногда его превосходит
- lzma быстрее bzip2 (во всяком случае в те разы, что я использовал bzip2 получал архив того же размера что и lzma 7Zip, но делалась архивация дольше
| | |
| |
| 3.15, User294 (ok), 15:07, 06/03/2009 [^] [^^] [^^^] [ответить]
| +/– | |
>- lzma медленее zip
При сжатии при том конкретно так медленнее.При распаковке - не на много, распаковка быстрая.
>- lzma очень любит память (в случае больших словарей - это могут быть гигабайты,
Чудес не бывает ;)
>- lzma сравним по эффективности с bzip2 и иногда его превосходит
Я бы сказал, "lzma обычно эффективнее bzip2 и зачастую порядочно его превосходит".Особенно с большими словарями и на повторяющихся данных.Найти набор данных где bzip2 с его ограничением так сказать "словаря" в 900 кило обыграет lzma с более крупным словарем - еще постараться надо.Сколько я ни прогонял экспериментов - типичная ситуация после пережатия из bz2 в lzma - это заметное уменьшение размера.
>- lzma быстрее bzip2 (во всяком случае в те разы, что я
>использовал bzip2 получал архив того же размера что и lzma 7Zip,
>но делалась архивация дольше
Опять же. LZMA тормоз в упаковке (даже наверное более тормоз чем bz2 в зависимости от параметров) но зато быстр в распаковке.У алгоритмов на основе LZ распаковка по жизни сильно быстрее упаковки из-за принципов работы.Bzip2 не такой тормоз в упаковке но и по скорости распаковки - не ахти (он если не ошибаюсь BWT юзает, с совсем иными чем у LZ-based свойствами в плане соотношения скоростей упаковки и распаковки).
| | |
|
|
| 1.10, Аноним (10), 07:29, 06/03/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
А как вы будите решать проблему многотомности? Порой приходится делать backup с кусками определенного размера.
| | |
| |
| 2.12, Ыку (?), 09:08, 06/03/2009 [^] [^^] [^^^] [ответить]
| +/– |
>А как вы будите решать проблему многотомности? Порой приходится делать backup с
>кусками определенного размера.
split'ом
| | |
|
|
