>1/1.260 = 1.206

У тебя калькулятор сломался.

KRoN73 (26.01.2010 13:21:36)

>архиватор (компрессор)

>md5

А распаковываешь c помощью John the Ripper? :)

AX (26.01.2010 13:22:20)

В действительности, as33 прав.

Практически во всех файлообменных сетях файлы и фрагменты файлов на некотором этапе подменяются хешами.

Некоторые файловые системы объединяют фрагменты файлов на том основании, что совпали хеш-суммы этих фраментов (без побайтового сравнения!!!).

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

Можно смотреть на эти дела как на передачу/сравнение в "сжатом виде".

Manhunt (26.01.2010 13:31:05)

и в самом деле сломался, но не калькулятор, а моя упрощалка в голове. исходно это было так: 1 - 1/1.260 = 0.206 а потом мне его упростить захотелось :D

beastie (26.01.2010 13:38:36)

> Вероятность коллизии якобы исчезающе мала

Хотя моя фольгированная шапочка подсказывает, что это мина замедленного действия. Рано или поздо нароют способ порождать коллизии по заданному фрагменту файла, и начнется жуткий повсеместный poisoning.

Например, коллизии к md4 при желании можно отыскивать в рилтайме. Коллизию к md5 на кластере можно найти за час.

Manhunt (26.01.2010 13:45:16)

> Некоторые файловые системы объединяют фрагменты файлов на том основании, что совпали хеш-суммы этих фраментов (без побайтового сравнения!!!).

venti

есть ли кстати другие fs с подобной фичей?

beastie (26.01.2010 13:45:38)

> есть ли кстати другие fs с подобной фичей?

http://www.linux.org.ru/view-message.jsp?msgid=4197974

Manhunt (26.01.2010 13:49:15)

lessfs

Sylvia (26.01.2010 13:49:23)

bzip2, zip, потом xz и lzma, потом 7zip и rar

Hokum (26.01.2010 14:20:52)

видать мне совсем делать нечего, решил устроить маленький banchmark.

итак, на старте имеем 7zr, tar+lzma, tar+bzip2, tar+gzip, tar.

задача: запаковать файлы, передать по сети, распаковать файлы.

для упрощения принимаем, что сеть у нас сферическая и в вакууме на 6Mbit/s (не знаю как по россии, но на западе практически уже у всех домохозяек как минимум 16Mbit/s). изходя из этого постулата и будем расчитывать время передачи по сети.

так же замеряем время паковки/распаковки и складываем результаты с временем передачи.

тестовая машинка: Intel(R) Pentium(R) M processor 1.70GHz

тестовые файлы: солянка из исходников, бинарников, архивов и х.з. чего ещё на 595MB

замер:

        create          extract         size    c/rate  send@6Mbit/s    create+send+extract
tar.lz  11m34.559s      4m6.356s        210M    35.3%   280s            1221s
7z      11m41.908s      3m25.416s       214M    35.9%   285s            1192s
tar.bz2 10m25.881s      3m30.285s       352M    42.5%   469s            1305s
tar.gz  2m1.734s        2m7.100s        406M    68.2%   514s            763s
tar     1m41.555s       2m11.992s       554M    93.1%   739s            972s

результаты: для tar+bzip2 неутешительные -- долгое время поковки + среднее показатели компрессии выводят его на последнее место.

лучше всех пакуют 7zr и tar+lzma. однако им и времени надо дольше всех, что в результате выталкивает их на последьнии места рядышком с bzip2.

далее на почётном втором месте голый tar. очевидно, что прередача несжатых данных может быть вполне оправдана т.к. при этом не тратится время на паковку/распаковку, которое может быть вполне значительным.

на первом же месте связка tar+gzip. gzip хоть и пакует хуже всех, зато быстро. его время сжатия/расжатия практически не отличается от голого tar'а, зато сжатие данных делают своё дело и время передачи укорачивается почти на 3m30s по сравнению с tar.

вот так вот. выводы делайте сами.

disclaimer: на истину в последней истанции не претендую. замер и расчёты сделаны хохмы ради и без соблюдений методики и санитарных норм. за время экспериметна ни один файл не постродал.

dixi

beastie (26.01.2010 15:34:39)

/dev/shm/ в тесте учавтвует tar-архив ядра линукс 2.6.31

pack:

$ time bzip2 linux.tar 

real	1m2.781s
user	1m2.536s
sys	0m0.252s


$ time gzip -c linux.tar > linux.tar.gz

real	0m18.033s
user	0m17.905s
sys	0m0.128s

$ time lzma -k linux.tar

real	5m46.682s
user	5m46.198s
sys	0m0.464s

unpack:

$ time bunzip2 -k linux.tar.bz2 

real	0m12.823s
user	0m12.581s
sys	0m0.240s

$ time gunzip -c linux.tar.gz > linux.tar

real	0m3.089s
user	0m2.828s
sys	0m0.260s

$ time unlzma -k linux.tar.lzma 

real	0m6.230s
user	0m5.908s
sys	0m0.320s

-rw-r--r-- 1 azure users 365711360 Янв 26 14:35 linux.tar
-rw-r--r-- 1 azure users  61494822 Янв 26 14:32 linux.tar.bz2
-rw-r--r-- 1 azure users  79005202 Янв 26 14:37 linux.tar.gz
-rw-r--r-- 1 azure users  52352353 Янв 26 14:35 linux.tar.lzma

Итого:
bzip2: сжал до 16.8% начального размера за 62.5 секунды, разжал за 12.5 секунд
gzip: сжал до 21.6% начального размера за 18 секунд, разжал за 2.8 секунды
lzma: сжал до 14.3% начального размера за 346 секунд, разжал за 5.9 секунд

• lzma в 1.5 раза эффективнее gzip и в 1.17 раз эффективнее чем bzip2 по степени сжатия,
• lzma в ~2 раза хуже, чем gzip, в ~2 раза лучше, чем bzip2 по времени распаковки,
• lzma в 19 раз хуже gzip по времени сжатия и в 5.5 раз хуже bzip2 по времени сжатия

azure (26.01.2010 16:19:36)

gzip по сути может претендовать на realtime компрессию-декомпрессию, на современных процессорах цикл сжатие-запись на диск может оказаться быстрее чем просто запись на диск без сжатия (собственно поэтому gzip используется в reiser4, btrfs, fusecompress как алгоритм по умолчанию)
другой кандидат в realtime - lzop (lzo), этот еще быстрее, хотя lzop -9 возится значительно дольше чем gzip -9, lzo также используется как сжатие для ФС, но еще и применяется в compcache для сжатия страниц памяти.
Это как альтернативы просто tar , в случае хорошо сжимаемых данных они дадут хороший выигрыш, в том числе и при передаче по сети до 100 Mbit

Sylvia (26.01.2010 16:26:42)

ps: да, bzip2 в явных аутсайдерах

Sylvia (26.01.2010 16:28:50)

Фигней вы занимаетесь.

У всех архиваторов есть параметры, которые очень сильно влияют на скорость и степень сжатия.

>У всех архиваторов есть параметры, которые очень сильно влияют на скорость и степень сжатия.

fix: у всех архиваторов есть параметры _по умолчанию_ , которые обычно и используются, в том числе и при вызове через tar (-z , -j , -J , -a )

Sylvia (26.01.2010 16:38:37)

Использовать стандартные настройки это бессмысленно. Может тогда еще изобрести стандартный линукс.

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

> Тар это вообще ерунда из которого распухают архивы.
А что вы предлагаете взамен?

zip, если никаких особых претензий к сжатию нет.

a3 (26.01.2010 19:53:02)

Конечно 7-zip, а lzma это его технология сжатия!

filosof (26.01.2010 20:34:43)

RAR не нужен вообще. Он хуже 7-zipа! А винзип вроде на lzma сжатия перешёл, а он платный! И вообще почти все виндузовые архиваторы умеют разжимать 7z!

filosof (26.01.2010 20:39:30)

> Тар это вообще ерунда из которого распухают архивы. Тар сует в свой контейнер кучу лишних данных. Тар давно уже надо закопать.

Лишних??? Можно поподробней? А то мне казалось что он сует кучу _нужных_ данных. Вплоть до того, что из tar-архива можно линукс систему распаковать и будет работать. И вообще чуть ли не самая юниксвейная программа. Архиватор не должен заниматься хранением владельцев\прав на файл (для этого есть тар), он должен сжимать поток данных. Но люди с виндосом головного мозга этого не понимают.

azure (27.01.2010 0:01:16)

paq8 наше все

zip

waker (27.01.2010 0:55:01)

Для мелких объемов gzip/bzip2 часто, для больших xz и 7z редко.

holka (27.01.2010 12:56:10)

> да, bzip2 в явных аутсайдерах

bzip2 хорош там, где нужен псевдослучайный доступ к данным. bzip2 по своей природе блочный, и максимальный рамер неупакованного блока - 900000 байт. Если нарезать файл на такие (или более мелкие) блоки и упаковать их по отдельности, то bzip2 выйграет у lzma по степени сжатия.

Впрочем, это уже мало относится к end-user утилитам...

Вот упаковка, которую я подразумеваю:

split -b 99000 -d Efremova.dsl -a3 part- && for name in part*; do bzip2 -1 $name; done && cat *.bz2 > bz2-1 && rm *.bz2 

split -b 199000 -d Efremova.dsl -a3 part- && for name in part*; do bzip2 -2 $name; done && cat *.bz2 > bz2-2 && rm *.bz2 

split -b 299000 -d Efremova.dsl -a3 part- && for name in part*; do bzip2 -3 $name; done && cat *.bz2 > bz2-3 && rm *.bz2 

split -b 399000 -d Efremova.dsl -a3 part- && for name in part*; do bzip2 -4 $name; done && cat *.bz2 > bz2-4 && rm *.bz2 

split -b 499000 -d Efremova.dsl -a3 part- && for name in part*; do bzip2 -5 $name; done && cat *.bz2 > bz2-5 && rm *.bz2 

split -b 599000 -d Efremova.dsl -a3 part- && for name in part*; do bzip2 -6 $name; done && cat *.bz2 > bz2-6 && rm *.bz2 

split -b 699000 -d Efremova.dsl -a3 part- && for name in part*; do bzip2 -7 $name; done && cat *.bz2 > bz2-7 && rm *.bz2 

split -b 799000 -d Efremova.dsl -a3 part- && for name in part*; do bzip2 -8 $name; done && cat *.bz2 > bz2-8 && rm *.bz2 

split -b 899000 -d Efremova.dsl -a3 part- && for name in part*; do bzip2 -9 $name; done && cat *.bz2 > bz2-9 && rm *.bz2 

split -b 99000 -d Efremova.dsl -a3 part- && for name in part*; do xz -9 -e $name; done && cat *.xz > xz-1 && rm *.xz 

split -b 199000 -d Efremova.dsl -a3 part- && for name in part*; do xz -9 -e $name; done && cat *.xz > xz-2 && rm *.xz 

split -b 299000 -d Efremova.dsl -a3 part- && for name in part*; do xz -9 -e $name; done && cat *.xz > xz-3 && rm *.xz 

split -b 399000 -d Efremova.dsl -a3 part- && for name in part*; do xz -9 -e $name; done && cat *.xz > xz-4 && rm *.xz 

split -b 499000 -d Efremova.dsl -a3 part- && for name in part*; do xz -9 -e $name; done && cat *.xz > xz-5 && rm *.xz 

split -b 599000 -d Efremova.dsl -a3 part- && for name in part*; do xz -9 -e $name; done && cat *.xz > xz-6 && rm *.xz 

split -b 699000 -d Efremova.dsl -a3 part- && for name in part*; do xz -9 -e $name; done && cat *.xz > xz-7 && rm *.xz 

split -b 799000 -d Efremova.dsl -a3 part- && for name in part*; do xz -9 -e $name; done && cat *.xz > xz-8 && rm *.xz 

split -b 899000 -d Efremova.dsl -a3 part- && for name in part*; do xz -9 -e $name; done && cat *.xz > xz-9 && rm *.xz 

bzip2 -k -9 Efremova.dsl && mv Efremova.dsl.bz2 bz2-whole 

xz -k -9 -e Efremova.dsl && mv Efremova.dsl.xz xz-whole 

ls -1 -s --block-size=1 *

И вот какие получаются размеры файлов:

 5009408 bz2-1
 4521984 bz2-2
 4300800 bz2-3
 4161536 bz2-4
 4067328 bz2-5
 3997696 bz2-6
 3940352 bz2-7
 3891200 bz2-8
 3850240 bz2-9
 3854336 bz2-whole
 5656576 xz-1
 5210112 xz-2
 4997120 xz-3
 4870144 xz-4
 4771840 xz-5
 4698112 xz-6
 4640768 xz-7
 4591616 xz-8
 4550656 xz-9
 3534848 xz-whole
58273792 Efremova.dsl

То есть при нарезке на блоки, bzip2 выигравет по размеру сжатого файла на 13-18% . Не смотря на то, что при сжатии файла целиком выигрыш по размеру за lzma, порядка 9%.

PS файликом Efremova.dsl можно разжиться тут: http://traduko.lib.ru/efremova_lingvo.html

Manhunt (27.01.2010 13:37:58)

Сохрани в контейнере Тар файл размером 100 байт.

А затем сохрани тот же 100 байтовый файл в архиве 7zip с нулевым сжатием (то есть без сжатия).

А потом сравни размеры.

Тар описывает в своем контейнеры файлы используя слишком много избыточных данных. В результате при сжатии (десятков) тысяч файлов архив распухает на много.

Кроме того у Тара нет индекса. И распаковка из архива отдельных файлов, папок очень очень долгая.

> Тар описывает в своем контейнеры файлы используя слишком много избыточных данных.

Огласите весь список, пожалуйста. Для Ъ.

Manhunt (27.01.2010 17:48:26)

xz

nixtrian (27.01.2010 17:50:47)

bzip2, gzip, zip, xz

ip1981 (27.01.2010 20:25:49)

tar+bz2 и в винду тоже :)

Slackware_user (28.01.2010 22:13:14)

gzip

edigaryev (28.01.2010 22:24:09)

bzip2 по привычке. А если что то сжимается долго то gzip.

Lucky1 (28.01.2010 22:34:02)

Там есть поддержка сжатых образов, так что с натяжкой поканает.

По теме другое BetterZip 1.8.1

Dominus (03.02.2010 10:18:51)

lzma, zip

seed_stil (05.02.2010 17:05:39)

xz и bzip2 в основном.

Cooler (08.02.2010 10:28:18)

Для себя сжимаю gzip'ом, иногда просто голый tar. Но rar в сети попадается постоянно.

dogbert (08.02.2010 11:02:30)

Я по старинке использую gzip. Хотя обьем бэкапа у меня маленький довольно. P.S Вроде бы обсуждение,а некоторые интересные моменты насчет того же bzip2 узнаешь.

pinachet (08.02.2010 11:09:16)

tar cfj <file>.tz file

WARNING (08.02.2010 11:14:57)

> 7z/LZMA (или без сжатия) — для многотомных архивов (файлов с фильмами), которые >4GB, для переноса на флэшке с FAT32

Сжимать фильмы? Безумие! split для этого больше подходит.

anonymoos (08.02.2010 11:23:44)

dmg ака darwin image внутри может быть несжатой, zip-сжатой, и bzip2 сжатой. Архивы которые создаёт Stuffit по умолчанию имеют расширение sitx (в новых версиях) и sit - в старых.

Пропущены всякие извращения типа ace и uha, но то таке ;)

nikitos (08.02.2010 11:26:24)

> Winrar под виртуальной машиной. Долго, но зато качественно и безопасно.

Уйди отсюда.

pevzi (08.02.2010 11:30:03)

Чаще всего использую архивы в gzip, канешна. А вот когда сам что-то сжимал — уже забыл (:

pevzi (08.02.2010 11:31:16)

.... tar.gz

Зачем Вам в Windows виртуальная машина? WinRAR и так хорошо работает.

Oleaster (08.02.2010 12:12:16)

> разве 7z и lzma не одно и то же?

7z - архиватор, lzma - компрессор (и одноимённый алгоритм компрессии)

matimatik (08.02.2010 12:41:16)

По сабжу: хз, то есть xz :)

matimatik (08.02.2010 12:53:57)

zip, tar.gz. 7zip слишком прожорливый при запаковке.

Mystra_x64 (08.02.2010 13:05:22)

>WinRAR и так хорошо работает.

а нативный рар плохо работает?

madcore (08.02.2010 13:39:57)

По привычке использую bzip2. Пора уже перейти на gzip

unnamed (08.02.2010 13:51:40)

чаще всего zip для большей совместимости с виндовс, ибо в xp это искаропки.