Praktický test komprese ZPAQ v programu lrzip (diskuse)

[petr_p]

lrzip bohužel není udržovaný a obsahuje nepříjemné množství bezpečnostních chyb. Značný podíl na tom má zadrátovaná historická verze ZPAQu, s jejíž aktualizací si neví rady ani Kolivas. (ZPAQ změnil vnitřní API a lrzip samozřejmě používá jeho vnitřnosti.) Samozřejmě testy neexistují. Ostatně i ZPAQ je kapitola sama pro sebe (dynamická knihovna je zde sprosté slovo.) Osobně radím nestavět na této technologii nic. Proto jsem lrzip odstranil z Fedory.

[Tibor]

V článku nesedia čísla. GiB je 2³⁰ B. 12836904960 B je 11,96 GiB, 4036546560 B je 3,76 GiB.

[Bystroushaak]

Jo, to bude chyba, má to být GB, ne GiB.

[🇵🇸]

OK, opraveno.

[Aleš Kapica]

Osobně se snažím dělat pravidelné inkrementální zálohy pomocí rsync. … V tuto chvíli je pro mě velikost výsledného souboru podstatná, zatímco čas na kompresi mě v podstatě nezajímá a může trvat klidně celý den.

Všechno je to pouze o objemu dat. Pokud ti objem komprimovaných dat naroste do takové míry, že ti přestane na kompresi 24 hodin stačit – máš problém.

[Andrej]

jedine ak "pravidelné" znamena "kazdych 24 hodin"...

[Ilfirin]

A to jsem myslel, že ZPAQ je můj tajný nástroj, který nikdo nezná... Nicméně skončil jsem také ve fázi pokusů. Ano, komprimuje to jako ďábel, ale v reálném nasazení nemám na tu komprimaci čas (reálný, i procesorový) a fallbacknul k lzma. Ale furt ho mám jako hračku pro srovnání, o kolik víc by to šlo ještě zkomprimovat oproti lzma.

[x14]

Děkuji za test, o existenci něčeho takového jsem neměl tušení.

[Cejvik]

škoda že v testu nebyl použit 7zip/LZMA

[Cejvik]

beru zpet

[Petr]

Krom toho, ze lrzip je neudrzovan, mozna bych ti doporucil podivat se na lzma2 treba v 7zipu (u me p7zip na freebsd). Tech prepinacu, hlavne co se tyce ram a velikosti ruznych slovniku je tam x a s dostatkem ram se dostanes dal nez s lrzip. 16gb ram je pro max kompresi nedostatecnych.

[Andrej]

16gb ram je pro max kompresi nedostatecnych?

[Petr]

Ano. U 1gb archivu samozrejme ne, ale pokud komprimujes treba x desitek/stovek gb nebo v mem pripade tb dat, tak ty pametove naroky jsou jinde. Vychazi to z velikosti slovniku, predikcnich algoritmu atd.

[Bystroushaak]

Krom toho, ze lrzip je neudrzovan, mozna bych ti doporucil podivat se na lzma2 treba v 7zipu (u me p7zip na freebsd). Tech prepinacu, hlavne co se tyce ram a velikosti ruznych slovniku je tam x a s dostatkem ram se dostanes dal nez s lrzip. 16gb ram je pro max kompresi nedostatecnych.

A umí to deduplikaci? Protože to je pro mě docela killer feature.

[Peter Golis]

Aký je prosím rozdiel medzi slovníkovou kompresiou a deduplikáciou s použitím nekonečne veľkého slovníka a pevnej dĺžky slova? Nejako som si žiaden nevšimol.

[Bystroushaak]

A konkrétně? Jaký program, jaké parametry, jak ti vyšel benchmark?

[Peter Golis]

Vedel by si povedať ako chceš programom definovať rozdiel v definícii dvoch technológií?

[Bystroushaak]

Vedel by si povedať ako chceš programom definovať rozdiel v definícii dvoch technológií?

Zajímá mě konkrétní řešení, pokud to chceš brát hypoteticko-filosoficky, tak na to nemám ani čas, ani náladu.

[Peter Golis]

Pretože deduplikácia je slovníková kompresia, s pevnou dĺžkou slova a nekonečne dlhým slovníkom.

A ak urgentne potrebuješ funkčné riešenie, tak skús povedať cenovú hladinu. Hotových riešení pre deduplikáciu je plno. BSD s ZFS, Linux s BTRFS, OpenDedup, alebo komerčné Quantum DXi, či HPE StoreOnce.

[marbu]

Pretože deduplikácia je slovníková kompresia, s pevnou dĺžkou slova a nekonečne dlhým slovníkom.

Z praktického hlediska bych viděl menší zádrhel v tom nekonečném slovníku.

A ak urgentne potrebuješ funkčné riešenie, tak skús povedať cenovú hladinu. Hotových riešení pre deduplikáciu je plno. BSD s ZFS, Linux s BTRFS ...

Tak jednoduché to zase není. Filesystém (např. btrfs) nebo blokové vrstva (např. vdo) s deduplikací je přece jiný use case než deduplikace při kompresi tarballu.

[Peter Golis]

Pretože deduplikácia je slovníková kompresia, s pevnou dĺžkou slova a nekonečne dlhým slovníkom.

Z praktického hlediska bych viděl menší zádrhel v tom nekonečném slovníku.

Ja nie, slovník sa nemusí alokovať na počiatku sveta.

A ak urgentne potrebuješ funkčné riešenie, tak skús povedať cenovú hladinu. Hotových riešení pre deduplikáciu je plno. BSD s ZFS, Linux s BTRFS ...

Tak jednoduché to zase není. Filesystém (např. btrfs) nebo blokové vrstva (např. vdo) s deduplikací je přece jiný use case než deduplikace při kompresi tarballu.

Áno. Pri deduplikácii na úrovni FS nepotrebuješ používať TAR.

[pc2005]

To jsem nepochopil. Rzip má jen o 0.1GB menší soubor, ale dekomprese trvá skoro o řád déle než u bzipu2 ? Na co to je pak dobrý. Ten ~4% rozdíl ve velikosti je příliš malý, aby převážil dobu, kdy se čeká na dekompresi (a podobně dlouhou kompresi). A pokud by při bzip2 už nestačila velikost disku, tak to je špatně zvolená rezerva. Dokonce bych během rozdílu času komprese mezi bzip2 a lrzip byl schopen dojít koupit náhradní disk do města a zpět .

[Petr]

Tak ono je obcas usecase, ze tech dat mas proste hodne a neocekava se ze je nekdy budes cist a kazde usetrene procento znamena treba 1x 1tb disk. Ja treba komprimuji do sejfu data ktera nepredpokladam ze nekdy budu chtit cist, presto maji pro me urcitou cenu. Tech dat co takhle odlozim je nekolik tb mesicne (po maximalni lzma2 kompresi v p7zip).

[V.]

Co to znamená, že data neplánujete číst? U záloh neověřujete jejich použitelnost?

[Petr]

Odtestovat integritu archivnich souboru neni problem, kvuli tomu ale nemusim rozbalovat cely archiv.

[pc2005]

Pokud každé 1 procento znamená jeden 1TB disk, tak je celkej zanedbatelný rozdíl mezi 109 kKč (100x 1TB) a 112 kKč (103x 1TB).

[Petr]

Vy zalohujete dulezite data na 1 disk? Ja mam dulezite data na ruznych datovych mediich celkove v 6 kopiich na ruznych mistech. Takze to usetrene procento znamena vetsi usporu nakladu. Ale ano, chapu to, ze ty naklady jsou v celkovem meritku zanedbatelne.

[pc2005]

U soukromých dat proč by ne. Ale i v případě kopií by 1% nákladů bylo pořád 1% . Jinak kdybych měl úkol zazálohovat profesionální data, tak bych stejně použil bzip2 a to kvůli dlouhému času dekomprese lrzip (ztráta zisku při delším downtime).

[Bystroushaak]

To jsem nepochopil. Rzip má jen o 0.1GB menší soubor, ale dekomprese trvá skoro o řád déle než u bzipu2 ?

Záleží. Například u toho syncthing_delta.tar je to menší o 1.6GB než LZMA, což není zanedbatelné. Konkrétně to pálím na 25GB bluray, kde se každý volný gigabajt hodí.

[pc2005]

No je to víc než 10%, dejme tomu. Já bych ale těch 10% oželel. Rezerva by měla být pořád větší než těch 10%. Zvlášť pokud bych ukládal inkrementální zálohy na násobně větší disk (nehledě na to, že na tvůj bluray se stejně nevejde víc jak dvě kopie v libovolném kompresním algoritmu - záleží samozřejmě na fluktuaci velikosti při každé záloze).

[lertimir]

A jak to vyjde s cenou elektřiny? Tedy jestli to znamená plný výkon 100W procesoru (plus běžící zbytek kompu a disky) po 1 hodinu na to abych ušetřil 1,5GB tak je to cca 0,5 Kč za elktřinu proti cca 1,2 Kč za cenu media (na rotačním disku). Před časem jsem kompresoval nějaké filmy do x265, ale postupně to oželím, protože i když film stisknu na cca 30'% původní velikosti, tak rychlost je někde kolem uspory 0,8 GB za hodinu výpočtu a to mi připadá málo efektivní.

[Bystroushaak]

A jak to vyjde s cenou elektřiny? Tedy jestli to znamená plný výkon 100W procesoru (plus běžící zbytek kompu a disky) po 1 hodinu na to abych ušetřil 1,5GB tak je to cca 0,5 Kč za elktřinu proti cca 1,2 Kč za cenu media (na rotačním disku). Před časem jsem kompresoval nějaké filmy do x265, ale postupně to oželím, protože i když film stisknu na cca 30'% původní velikosti, tak rychlost je někde kolem uspory 0,8 GB za hodinu výpočtu a to mi připadá málo efektivní.

Elektřinu zanedbávám. Stojí tak málo, že se mi to v podstatě nevyplatí řešit. Počítač by stejně běžel tak jako tak, teď jen běží CPU na plný výkon. Šlo mi o to, že jinak bych musel pálit další bluray, trvalo by to další hodinu a byl by to další opruz, to dávat do vypalovačky, katalogizovat, nadepisovat a pak skladovat. Takhle se mi tam vešlo co jsem potřeboval. Na zálohování mám napsaný script, co všechno zkomprimuje, zašifruje, vytvoří md5sum a tak podobně, takže tam prostě přepíšu lrzip místo gzipu a tím to pro mě hasne.

[Kkt1]

Az budu doma, udelam nejaky test s p7zip a lzma2 vs lrzip. Ram mam dostatek, mozna si udelam i graf kolik to zere ram v case. Prosim o napady na referencni data, idealne desitky/stovky gigabajtu, jinak pouziji svuj mix nekolika tb dat.

[Bystroushaak]

Zkus použít nějaké dumpy z SQL / Mongo. Pak taky text, třeba wikipedii (dá se stahnout oficiálně celá).

[Kkt1]

Takze specificke baliky dat? Zadny mix? Ok, neco postaguhi o vikendu a pustim na to kompresi. 100gb pro input? Nebo vice?

[Bystroushaak]

Mix taky, ale tohle by mě konkrétně zajímalo. Mix ti neporadím kde vzít.

[petr]

Mix dat mam, vyslovene SQL dumpy nemam. Respektive nepracovni mnozstvi je v radu desitek MB a pracovni DB jsou zase oracle v praci a to domu nemohu. Nejaky napad kde sehnat treba 100GB SQL dumpu?

[Andrej]

ten backup script by niekde nebol?

[Bystroushaak]

Mám ho na domácím PC, ale tohle zvládne napsat kde kdo za pár minut. Je to prostě jen pár funkcí v bashi a pár řádek s umístěními, které se mají sebrat a „zpracovat“ (zatarovat a zašifrovat s progress barem pv a pak zmd5sumovat) do konkrétní složky. Celé to má asi 20 řádek.

[Bystroushaak]

#! /usr/bin/env bash
#
export ADDRESS="bystrousak@kitakitsune.org"
export GPG_PARAMS="--recipient $ADDRESS --compress-level 0 -e --yes --output"

function md5it {
    pv "$1" | md5sum - > "$1.md5sum";
}

function pack_to_gpg {
    echo "Packing $2 .. "
    # tar -czO "$1" 2>/dev/null | gpg $GPG_PARAMS "$2";
    tar -cO "$1" 2>/dev/null | pv -s $(du -sb "$1" | awk '{print $1}') | pbzip2 -5 -p3 -c | gpg $GPG_PARAMS "$2";
    md5it $2;
    echo "done"
}


if [ -d bluray ]; then
    rm -fr bluray;
fi

mkdir bluray
cd bluray

pack_to_gpg /media/bystrousak/Internal/Backup/delta/xlit_delta xlit_delta.tar.bz2.gpg
pack_to_gpg /media/bystrousak/Internal/Backup/delta/syncthing_delta syncthing_delta.tar.bz2.gpg
pack_to_gpg /media/bystrousak/Internal/Backup/delta/dropbox_delta dropbox_delta.tar.bz2.gpg
pack_to_gpg /media/bystrousak/Internal/Backup/delta/pocketbook_delta pocketbook_delta.tar.bz2.gpg

cp /home/bystrousak/Plocha/scanny .
md5it scanny

[Halis]

Pokud by ses spokojil s deduplikací na úrovni souborů, tak doporučuji technologii z BackupPC.

[Kkt1]

Well... po delsi dobe, kterou jsem vyuzil k porovnani 7zip a lrzip (a par dalsich), k memu obrovskemu prekvapeni 7zip neni kralem, a to ani s lzma2, ale vyhral u naproste vetsiny mych testu lrzip. Jak u 7zip tak u lrzip jsem pouzival maximalni moznou kompresi bez ohledu na ram nebo dopad na performance (stroje s 1tb ram, xeony, rychly storage), slo mi ciste jenom o kompresni pomer. Zdrojove data byli ruzne a komprimoval jsem je oddelene tak i mix. Vysledky byli u nekterych dat podobne (treba binarni bloby) ale u nekterych byli naprosto odlisne (treba komprese nekolik desitek vmware masin vcetne snapshotu kde lrzip dokazal vyprodukovat asi 20% velikost toho co vyprodukoval 7zip). Pro me nevyhody ve srovnani s 7zip - absence komprese adresaru (nejdrive musite udelat tar ktery treba pres pipe sypete do lrzip, tady ale ztratite optimalizaci dle obsahu jednotlivych souboru), nemoznost delit vystup na treba 50gb baliky, nekomu muze chybet sifrovani. Pro predstavu nejvetsi set komprimovanych dat mel neco pres 2tb, vetsina byla kolem 50-100gb.

[Bystroushaak]

tady ale ztratite optimalizaci dle obsahu jednotlivych souboru

Je to jen pocit, nebo to tak fakt je? Já myslel, že by na tom nemělo záležet, ale netestoval jsem to.

[petr]

U malych archivu je to vicemene jedno, u archivu v radech stovek GB/TB je IMHO rozdil jestli je milion textaku/exe/bmp/cehokoliv za sebou, nebo jestli je to random sorted. Nevejde se to do RAM/slovniku. Vyslovene test na tohle jsem nedelal, protoze problem je takovy sorted tar vyrobit a lrzip bez taru nefunguje, zatimco 7zip si proste ty files zkontroluje a dle toho obsahu je komprimuje. Zkusim ale neco vymyslet jak to rozumne odtestovat (napada me x ruznych taru dle obsahu vlozenych do dalsiho taru pro lrzip). Jeste jsem se koukal na zpaq ktery by mel byt konkurenci lrzipu, zkusim prohnat testovaci data jeste nim v max nastaveni a dam vedet.

[Bystroushaak]

Asi je otázka, jak rychle se to přizpůsobí datům.

protoze problem je takovy sorted tar vyrobit

Čistě jen pro inspiraci: python má tarfile. Tím si to můžeš namixovat.

Jeste jsem se koukal na zpaq ktery by mel byt konkurenci lrzipu, zkusim prohnat testovaci data jeste nim v max nastaveni a dam vedet.

Počkat, já psal ten článek právě o lrzipu s -z, což zapíná zpaq. Pokud myslíš zpaq jako program, tak to bude imho jen jiný frontend. Nebo ne?

[petr]

pokud jsem to pochopil spravne, tak lrzip i zpaq pouzivaji stejny algoritmus, implementace bude ale patrne jina. Zpaq ma x dalsich moznosti, zkusil jsem ted -method 5 -threads 1 a uvidime. Vice vlaken zhorsuje kompresni pomer a to i v 7zipu.

[petr]

tak zpaq v maximalni kompresi odhaduje cas ke kompresi 20GB dat na nejakych 30hodin... tim padem bych rekl, ze implementace bude jina nez lrzip. Dam vedet az to dokomprimuje i vysledek z lrzipu i s casem.

[petr]

Takze lrzip ma s nejvetsi pravdepodobnosti svou implementaci nez zpaq. Zpaq ma lepsi kompresni pomer ale ten cas je sileny. Testovaci tar byl 20443942400B lrzipem skomprimovany pres lrzip -T -L 9 -z Archive.tar na 7810518281B za 03:20:48. Zpaq na jednom vlakne to skomprimoval na 7489268634B za 23:53:31. Neumim si predstavit nechat komprimovat pres zpaq treba svych obvyklych 2TB, ale treba po roce by to dobehlo... Nasel jsem v ramci tech ruznych implementaci jeste rzip, ktery by mel mit moznost nejakych dalsich levelu, tudiz jdu to testnout.

[petr]

tak rzip po 12ti hodinach skomprimoval tech 20GB na 8307926621B. Z pohledu kompresniho pomeru je tedy zpaq vitez, z pohledu rychlost a kompresni pomer je lrzip vitez.

[Bystroushaak]

Díky za info!