abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
dnes 19:00 | Nová verze

Byla vydána verze 18.08.0 KDE Aplikací (KDE Applications). Přehled novinek v kompletním seznamu změn a na stránce s dalšími informacemi.

Ladislav Hagara | Komentářů: 0
dnes 18:44 | Pozvánky

Spolek OpenAlt zve příznivce otevřených řešení a přístupu na 155. brněnský sraz, který proběhne v pátek 17. srpna od 18:00 na zahrádce restaurace Tanganika (Horova 35). V případě nepřízně počasí uvnitř. Tentokrát bude sraz pojat tématicky. Vzhledem k blížícímu se 50. výročí invaze vojsk Varšavské smlouvy do Československa proběhne malá výstava. Kromě literatury budou k vidění též originály novin z 21. srpna 1968, dosud nikde nezveřejněné fotky okupovaného Brna a původní letáky rozdávané v ulicích.

Ladislav Hagara | Komentářů: 0
dnes 01:00 | Komunita

Měsíc po Slackware slaví 25 let také Debian. Přesně před pětadvaceti lety, 16. srpna 1993, oznámil Ian Murdock vydání "Debian Linux Release".

Ladislav Hagara | Komentářů: 9
včera 06:00 | Nová verze

Byla vydána nová verze 1.26 editoru zdrojových kódů Visual Studio Code (Wikipedie). Přehled novinek i s náhledy a animovanými gify v poznámkách k vydání. Představení novinek také na YouTube.

Ladislav Hagara | Komentářů: 22
včera 03:00 | Nová verze

Po více než 3 měsících vývoje od vydání verze 2.12.0 byla vydána nová verze 3.0.0 otevřeného emulátoru procesorů a virtualizačního nástroje QEMU (Wikipedie). Přispělo 169 vývojářů. Provedeno bylo více než 2 300 commitů. Přehled úprav a nových vlastností v seznamu změn. Proč verze 3.0.0 a ne 2.13.0? Není to kvůli triskaidekafobii. QEMU letos v březnu slavilo 15 let od oznámení verze 0.1 a to je dle vývojářů dobrý důvod pro novou major verzi. Vývojáři mají v plánu zvyšovat major verzi jednou ročně, vždy s prvním vydáním v daném roce.

Ladislav Hagara | Komentářů: 3
14.8. 22:11 | Bezpečnostní upozornění

Intel potvrdil (INTEL-SA-00161) další bezpečnostní problém ve svých procesorech. Problém byl pojmenován L1 Terminal Fault aneb L1TF. Popis problému přímo od Intelu na YouTube. Jedná se o CVE-2018-3615 (SGX), CVE-2018-3620 (OS/SMM) a CVE-2018-3646 (VMM). Další informace na stránce Foreshadow nebo přímo v dnešním commitu do Linuxu.

Ladislav Hagara | Komentářů: 18
14.8. 12:33 | IT novinky

Po více než 4 letech bylo vydáno RFC 8446 popisující verzi 1.3 protokolu TLS (Transport Layer Security). Popis novinek i historie TLS například v příspěvku na blogu Cloudflare.

Ladislav Hagara | Komentářů: 0
14.8. 11:11 | Zajímavý software

V roce 1998 uvedla společnost Tiger Electronics na trh elektronickou hračku, malého chlupatého tvora s velkýma ušima, Furby. Furby patřil k nejžádanějším hračkám. Během tří let se jich prodalo více než 40 milionů. Furby již tenkrát reagoval na světlo, zvuk, polohu, doteky a přítomnost dalších Furby. Sám mluvil a pohyboval se. Firmware uvnitř simuloval postupný vývoj a učení. Zdrojový kód tohoto firmwaru byl zveřejněn na Internet Archive [Hacker News].

Ladislav Hagara | Komentářů: 21
14.8. 02:00 | Nová verze

Australská společnost Blackmagic Design oznámila vydání verze 15 svého proprietárního softwaru pro editování videa a korekci barev DaVinci Resolve běžícího také na Linuxu. Představení nových vlastností na YouTube. Základní verze DaVinci Resolve je k dispozici zdarma. Plnou verzi DaVinci Resolve Studio lze koupit za 299 dolarů. Před rokem to bylo 995 dolarů.

Ladislav Hagara | Komentářů: 0
13.8. 21:00 | Zajímavý projekt

Cílem projektu DXVK bylo vytvořit vrstvu kompatibility mezi Direct3D 11 a Vulkanem a začlenění této vrstvy do Wine. Direct3D 10 nad Vulkanem bylo možné řešit mezikrokem pomocí vrstvy DXUP překládající Direct3D 10 na Direct3D 11. Vývojáři DXVK se rozhodli přímo podporovat Direct3D 10. Podpora byla začleněna do hlavní větve na GitHubu.

Ladislav Hagara | Komentářů: 4
Používáte zařízení („chromebook“, „chromebox“ či tablet) s ChromeOS?
 (6%)
 (4%)
 (12%)
 (78%)
Celkem 194 hlasů
 Komentářů: 9, poslední 14.8. 21:03
    Rozcestník

    Praktický test komprese ZPAQ v programu lrzip

    24.4. | Bystroushaak | Tipy a triky | 2811×

    Poslední dobou mě velmi zaujal komprimační nástroj lrzip (Long Range ZIP). Dosahuji s ním lepších komprimačních poměrů, než s čímkoliv jiným, a to ne o pár procent, ale často o celé desítky.

    lrzip je poměrně pomalý (s parametrem -z pro kompresi ZPAQ) a vyžaduje velké množství paměti. U mě na počítači se však průměrná rychlost komprese pohybuje okolo 3 MB/s, což není zas až tak špatné, je to lepší než například lzma (0,7 až 2 MB/s).

    Osobně se snažím dělat pravidelné inkrementální zálohy pomocí rsync. Tyto zálohy pak jednou za čas šifrované pomocí GPG vypaluji a kopíruji mj. na různá internetová úložiště. 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.

    Příklady

    Všechny příklady probíhaly na stroji vybaveném Intel Core i5-4590S (3,0 GHz), 16GB RAM a SSD.

    Rsync delta složka

    Mám adresář syncthing_delta, kam se pravidelně kopírují inkrementální zálohy. Velikost zatarovaného adresáře je 12,8 GB (12836904960 bajtů). V adresáři se nacházejí textová data, gitové repozitáře, obrázky, PDF soubory a celkově takový různý mix běžných uživatelských dat. Gzipovaných souborů je tam hodně, protože jsou interně používány rsyncem.

    Tento tarovaný soubor potřebuji něčím následně zmenšit. K tomu jsem historicky využíval gzip, bzip2 a lzma. Zde je tabulka výsledných velikostí a času, který to zabralo:

    Program Čas Výsledná velikost (GB) Rychlost komprese (MB/s) Komprese o (%) Čas dekomprese Rychlost dekomprese (MB/s)
    lrzip -z 58m  4s 9,5 3,51 25,78 67m 37s 3.01
    bzip2 -9 27m  7s 11,4 7,52 10,93 12m 16s 14,77
    gzip -9 9m  6s 11,4 22,42 10,93 2m 29s 72,97
    lzma -9 90m 58s 11,1 2,24 13,28 11m 28s 15,43

    Samotná složka Syncthing

    Předchozí příklad je lehce zkreslený, neboť komprimovaný soubor obsahuje velký počet souborů gzip, které si do ní ukládá rsync. Zde je ukázka benchmarku na zatarované složce Syncthing. Vstupní soubor tar má velikost 4,0 GB (4036546560 bajtů).

    Ve složce se nachází 29 592 souborů. Četnost některých zajímavějších typů souborů je následující:

    py 3471
    txt 1315
    png 1034
    jpg 932
    pyc 919
    sample 894
    self 858
    log 589
    hh 434
    cache 385
    cpp 362
    html 354
    js 344
    java 294
    md 285
    gif 232
    json 221
    css 208
    rst 190
    gz 148
    sh 113
    pyo 103
    pdf 102
    zip 94
    xcf 85
    pym 80
    yml 70
    dat 52
    st 48
    z 42
    c 34
    rar 34
    xml 30
    doc 27
    lzma 26

    Benchmark tentokrát vyšel takto:

    Program Čas Výsledná velikost (GB) Rychlost komprese (MB/s) Komprese o (%) Čas dekomprese Rychlost dekomprese (MB/s)
    lrzip -z 23m 12s 3,2 2,76 20,24 25m 10s 2,54
    bzip2 -9 7m 52s 3,3 8,15 15,65 3m 49s 14,17
    gzip -9 2m 52s 3,4 22,3 14,69 0m 48s 72,53
    lzma -9 30m 18s 3,3 2,11 17,34 3m 50s 13,83

    Textový soubor

    Čas od času potřebuji provést zálohy různých databází, což jsou více či méně strukturované textové soubory. Někdy se jedná o JSON, jindy jde o SQL dumpy.

    Vstupem byl soubor csfd.tar o velikosti 771,2 MB (771184640 bajtů), obsahující export z MongoDB v podobě souborů JSON.

    Program Čas Výsledná velikost (MB) Rychlost komprese (MB/s) Komprese o (%) Čas dekomprese Rychlost dekomprese (MB/s)
    lrzip -z 4m 15s 122,6 2,88 84,10 3m  7s 3,91
    bzip2 -9 1m  4s 142,3 11,4 81,54 0m 21s 6,77
    gzip -9 3m 26s 207,6 3,57 73,08 0m  4s 51,9
    lzma -9 12m 52s 140,3 0,17 81,80 0m  7s 20,04

    Grafy komprese

    Redukce velikosti Čas komprese Rychlost komprese

    Nevýhody

    Trochu nevýhodou jsou nestandardní přepínače a poněkud ukecanější výstup, než bývá běžně zvykem:

    Output filename is: /home/bystrousak/Plocha/syncthing_delta.tar.lrz
    /home/bystrousak/Plocha/syncthing_delta.tar - Compression Ratio: 1.351. Average Compression Speed:  3.514MB/s.
    Total time: 00:58:04.10

    Rychlost dekomprese

    Větší nevýhodou je pak nízká rychlost, a to nikoliv jen komprese, ale také dekomprese. To nebývá tak úplně zvykem. Například dekomprese pomocí gzipu je o řád rychlejší než komprese (3,57 MB/s komprese, 51,6 MB/s dekomprese).

    Tohle nevadí v některých konkrétních aplikacích, kdy nepotřebujete výsledné soubory často rozbalovat a jejich použití je spíše 1:1 (jednou zabaleno, jednou rozbaleno) než 1:N (jednou zabaleno, Nkrát rozbaleno). Typicky jde například o zálohování. Naopak pro distribuci software se program moc nehodí, neboť každý uživatel by na tom spálil mnoho výkonu.

    Čas dekomprese Rychlost dekomprese

    Zajímavosti

    Parametr -z specifikuje algoritmus ZPAQ. Ten je poměrně zajímavý mimo jiné tím, že provádí deduplikaci dat a jejich částečnou analýzu, na základě které pak vybírá různé pod-algoritmy, které se nejlépe hodí pro kompresi konkrétní části souboru.

    V hlavičkách archivu poněkud netradičně nejsou specifikované samotné algoritmy použité pro kompresi, místo toho je použit formát ZPAQL pro popis dekompresního algoritmu formou bytecode, jenž je možné za běhu přímo překládat na x86 instrukce. Díky tomu je teoreticky možné popsat výstupní data čistě algoritmicky a vygenerovat na tomto základě velké množství výstupu, podobně jako třeba prográmky demoscény generují desetiminutová videa z 64KiB binárky.

    Deduplikace probíhá na základě vyhledávání již zkomprimovaných bloků dat. Tyto bloky dat přitom mají variabilní velikost a jsou děleny a identifikovány na základě svého hashe. Podle mého názoru se jedná o velmi pěkný způsob zajištění deduplikace bez ohledu na to, kde jsou data v souboru uložena a jak moc jsou v něm posunuta.

    Verdikt

    Nejlepší kompresní poměr. Komprese lepší než lzma, dekomprese pomalejší než všechno ostatní mnou testované. Dobré na zálohy, špatné na distribuci software a cokoliv, kde data plánujete často rozbalovat.

           

    Hodnocení: 88 %

            špatnédobré        

    Nástroje: Tisk bez diskuse

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    Komentáře

    Vložit další komentář

    24.4. 07:21 petr_p | skóre: 59 | blog: pb
    Rozbalit Rozbalit vše Re: Praktický test komprese ZPAQ v programu lrzip
    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.
    24.4. 08:48 Tibor
    Rozbalit Rozbalit vše Re: Praktický test komprese ZPAQ v programu lrzip
    V článku nesedia čísla. GiB je 230 B. 12836904960 B je 11,96 GiB, 4036546560 B je 3,76 GiB.
    Bystroushaak avatar 24.4. 12:06 Bystroushaak | skóre: 33 | blog: Bystroushaakův blog | Praha
    Rozbalit Rozbalit vše Re: Praktický test komprese ZPAQ v programu lrzip
    Jo, to bude chyba, má to být GB, ne GiB.
    I differ with myself then agree, like the rock that was broken and cemented together. I change my opinion.
    Fluttershy, yay! avatar 24.4. 12:21 Fluttershy, yay! | skóre: 82 | blog:
    Rozbalit Rozbalit vše Re: Praktický test komprese ZPAQ v programu lrzip
    OK, opraveno.
    24.4. 08:51 Aleš Kapica | skóre: 47 | blog: kenyho_stesky | Ostrava
    Rozbalit Rozbalit vše Re: Praktický test komprese ZPAQ v programu lrzip
    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.
    24.4. 09:18 Andrej | skóre: 8
    Rozbalit Rozbalit vše Re: Praktický test komprese ZPAQ v programu lrzip
    jedine ak "pravidelné" znamena "kazdych 24 hodin"...
    Any sufficiently advanced magic is indistinguishable from technology. --Larry Niven
    Ilfirin avatar 24.4. 11:29 Ilfirin | skóre: 32 | blog: ilfblog | Liberec
    Rozbalit Rozbalit vše Re: Praktický test komprese ZPAQ v programu lrzip
    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.
    24.4. 14:09 x14
    Rozbalit Rozbalit vše Re: Praktický test komprese ZPAQ v programu lrzip
    Děkuji za test, o existenci něčeho takového jsem neměl tušení.
    24.4. 14:42 Cejvik | skóre: 5
    Rozbalit Rozbalit vše Re: Praktický test komprese ZPAQ v programu lrzip
    škoda že v testu nebyl použit 7zip/LZMA
    24.4. 14:44 Cejvik | skóre: 5
    Rozbalit Rozbalit vše Re: Praktický test komprese ZPAQ v programu lrzip
    beru zpet
    24.4. 16:17 Petr
    Rozbalit Rozbalit vše Re: Praktický test komprese ZPAQ v programu lrzip
    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.
    24.4. 23:11 Andrej | skóre: 8
    Rozbalit Rozbalit vše Re: Praktický test komprese ZPAQ v programu lrzip
    16gb ram je pro max kompresi nedostatecnych?
    Any sufficiently advanced magic is indistinguishable from technology. --Larry Niven
    25.4. 07:26 Petr
    Rozbalit Rozbalit vše Re: Praktický test komprese ZPAQ v programu lrzip
    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 avatar 25.4. 11:43 Bystroushaak | skóre: 33 | blog: Bystroushaakův blog | Praha
    Rozbalit Rozbalit vše Re: Praktický test komprese ZPAQ v programu lrzip
    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.
    I differ with myself then agree, like the rock that was broken and cemented together. I change my opinion.
    25.4. 12:20 Peter Golis | skóre: 56 | Bratislava
    Rozbalit Rozbalit vše Re: Praktický test komprese ZPAQ v programu lrzip
    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 avatar 25.4. 13:06 Bystroushaak | skóre: 33 | blog: Bystroushaakův blog | Praha
    Rozbalit Rozbalit vše Re: Praktický test komprese ZPAQ v programu lrzip
    A konkrétně? Jaký program, jaké parametry, jak ti vyšel benchmark?
    I differ with myself then agree, like the rock that was broken and cemented together. I change my opinion.
    25.4. 17:08 Peter Golis | skóre: 56 | Bratislava
    Rozbalit Rozbalit vše Re: Praktický test komprese ZPAQ v programu lrzip
    Vedel by si povedať ako chceš programom definovať rozdiel v definícii dvoch technológií?
    Bystroushaak avatar 25.4. 18:47 Bystroushaak | skóre: 33 | blog: Bystroushaakův blog | Praha
    Rozbalit Rozbalit vše Re: Praktický test komprese ZPAQ v programu lrzip
    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.
    I differ with myself then agree, like the rock that was broken and cemented together. I change my opinion.
    25.4. 18:54 Peter Golis | skóre: 56 | Bratislava
    Rozbalit Rozbalit vše Re: Praktický test komprese ZPAQ v programu lrzip
    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.
    25.4. 21:03 marbu | skóre: 29 | blog: hromada | Brno
    Rozbalit Rozbalit vše Re: Praktický test komprese ZPAQ v programu lrzip
    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.

    I think warning here is a bug. The biggest cloud service provider. There is no point in being so cool in a cold world.
    26.4. 09:28 Peter Golis | skóre: 56 | Bratislava
    Rozbalit Rozbalit vše Re: Praktický test komprese ZPAQ v programu lrzip
    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.
    24.4. 21:58 pc2005 | skóre: 36 | blog: GardenOfEdenConfiguration | liberec
    Rozbalit Rozbalit vše Re: Praktický test komprese ZPAQ v programu lrzip
    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 :-D.
    25.4. 07:31 Petr
    Rozbalit Rozbalit vše Re: Praktický test komprese ZPAQ v programu lrzip
    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).
    25.4. 22:29 V.
    Rozbalit Rozbalit vše Re: Praktický test komprese ZPAQ v programu lrzip
    Co to znamená, že data neplánujete číst? U záloh neověřujete jejich použitelnost?
    26.4. 08:47 Petr
    Rozbalit Rozbalit vše Re: Praktický test komprese ZPAQ v programu lrzip
    Odtestovat integritu archivnich souboru neni problem, kvuli tomu ale nemusim rozbalovat cely archiv.
    25.4. 22:38 pc2005 | skóre: 36 | blog: GardenOfEdenConfiguration | liberec
    Rozbalit Rozbalit vše Re: Praktický test komprese ZPAQ v programu lrzip
    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).
    26.4. 08:49 Petr
    Rozbalit Rozbalit vše Re: Praktický test komprese ZPAQ v programu lrzip
    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.
    26.4. 23:14 pc2005 | skóre: 36 | blog: GardenOfEdenConfiguration | liberec
    Rozbalit Rozbalit vše Re: Praktický test komprese ZPAQ v programu lrzip
    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 avatar 25.4. 11:44 Bystroushaak | skóre: 33 | blog: Bystroushaakův blog | Praha
    Rozbalit Rozbalit vše Re: Praktický test komprese ZPAQ v programu lrzip
    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í.
    I differ with myself then agree, like the rock that was broken and cemented together. I change my opinion.
    25.4. 22:44 pc2005 | skóre: 36 | blog: GardenOfEdenConfiguration | liberec
    Rozbalit Rozbalit vše Re: Praktický test komprese ZPAQ v programu lrzip
    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).

    26.4. 10:51 lertimir | skóre: 61 | blog: Par_slov
    Rozbalit Rozbalit vše Re: Praktický test komprese ZPAQ v programu lrzip
    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 avatar 26.4. 12:34 Bystroushaak | skóre: 33 | blog: Bystroushaakův blog | Praha
    Rozbalit Rozbalit vše Re: Praktický test komprese ZPAQ v programu lrzip
    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.
    I differ with myself then agree, like the rock that was broken and cemented together. I change my opinion.
    25.4. 12:33 Kkt1
    Rozbalit Rozbalit vše Re: Praktický test komprese ZPAQ v programu lrzip
    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 avatar 25.4. 13:07 Bystroushaak | skóre: 33 | blog: Bystroushaakův blog | Praha
    Rozbalit Rozbalit vše Re: Praktický test komprese ZPAQ v programu lrzip
    Zkus použít nějaké dumpy z SQL / Mongo. Pak taky text, třeba wikipedii (dá se stahnout oficiálně celá).
    I differ with myself then agree, like the rock that was broken and cemented together. I change my opinion.
    25.4. 13:12 Kkt1
    Rozbalit Rozbalit vše Re: Praktický test komprese ZPAQ v programu lrzip
    Takze specificke baliky dat? Zadny mix? Ok, neco postaguhi o vikendu a pustim na to kompresi. 100gb pro input? Nebo vice?
    Bystroushaak avatar 25.4. 13:31 Bystroushaak | skóre: 33 | blog: Bystroushaakův blog | Praha
    Rozbalit Rozbalit vše Re: Praktický test komprese ZPAQ v programu lrzip
    Mix taky, ale tohle by mě konkrétně zajímalo. Mix ti neporadím kde vzít.
    I differ with myself then agree, like the rock that was broken and cemented together. I change my opinion.
    28.4. 12:52 petr
    Rozbalit Rozbalit vše Re: Praktický test komprese ZPAQ v programu lrzip
    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?
    27.4. 14:23 Andrej | skóre: 8
    Rozbalit Rozbalit vše Re: Praktický test komprese ZPAQ v programu lrzip
    ten backup script by niekde nebol?
    Any sufficiently advanced magic is indistinguishable from technology. --Larry Niven
    Bystroushaak avatar 27.4. 19:44 Bystroushaak | skóre: 33 | blog: Bystroushaakův blog | Praha
    Rozbalit Rozbalit vše Re: Praktický test komprese ZPAQ v programu lrzip
    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.
    I differ with myself then agree, like the rock that was broken and cemented together. I change my opinion.
    Bystroushaak avatar 29.4. 11:44 Bystroushaak | skóre: 33 | blog: Bystroushaakův blog | Praha
    Rozbalit Rozbalit vše Re: Praktický test komprese ZPAQ v programu lrzip
    #! /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
    I differ with myself then agree, like the rock that was broken and cemented together. I change my opinion.
    29.4. 01:54 Halis | skóre: 5 | blog: capacitor
    Rozbalit Rozbalit vše Re: Praktický test komprese ZPAQ v programu lrzip
    Pokud by ses spokojil s deduplikací na úrovni souborů, tak doporučuji technologii z BackupPC.
    10.5. 14:40 Kkt1
    Rozbalit Rozbalit vše Re: Praktický test komprese ZPAQ v programu lrzip
    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 avatar 10.5. 15:24 Bystroushaak | skóre: 33 | blog: Bystroushaakův blog | Praha
    Rozbalit Rozbalit vše Re: Praktický test komprese ZPAQ v programu lrzip
    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.
    I differ with myself then agree, like the rock that was broken and cemented together. I change my opinion.
    10.5. 16:54 petr
    Rozbalit Rozbalit vše Re: Praktický test komprese ZPAQ v programu lrzip
    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 avatar 10.5. 17:15 Bystroushaak | skóre: 33 | blog: Bystroushaakův blog | Praha
    Rozbalit Rozbalit vše Re: Praktický test komprese ZPAQ v programu lrzip
    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?
    I differ with myself then agree, like the rock that was broken and cemented together. I change my opinion.
    10.5. 17:30 petr
    Rozbalit Rozbalit vše Re: Praktický test komprese ZPAQ v programu lrzip
    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.
    10.5. 17:46 petr
    Rozbalit Rozbalit vše Re: Praktický test komprese ZPAQ v programu lrzip
    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.
    11.5. 21:28 petr
    Rozbalit Rozbalit vše Re: Praktický test komprese ZPAQ v programu lrzip
    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.
    12.5. 09:45 petr
    Rozbalit Rozbalit vše Re: Praktický test komprese ZPAQ v programu lrzip
    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 avatar 12.5. 10:06 Bystroushaak | skóre: 33 | blog: Bystroushaakův blog | Praha
    Rozbalit Rozbalit vše Re: Praktický test komprese ZPAQ v programu lrzip
    Díky za info!
    I differ with myself then agree, like the rock that was broken and cemented together. I change my opinion.

    Založit nové vláknoNahoru

    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.