Nejlepší nastavení komprese v 7zip

[Honza1]

Tahle tabulka je asi nejlepsi. Je tam efektivita komprese (o kolik procent se zmensil objem dat), rychlost rozbalovani i rychlost komprese. Co se tyce minimalizace dat, vyhrava paq8px (za cenu obrovskeho procesoroveho casu).
Mnoho programu jelepsich nez 7zip.
Talbulka je maximalne prehledna.

http://www.maximumcompression.com/data/summary_mf2.php

A na strankach zdrojaku paq8px je taky tabulkapro ruzne verze (divne, ze se tak lisi):
http://dhost.info/paq8/

[Reklama]

[Honza1]

Jinak tech tabulek je pro ruzne typy dat opravdu hodne zde:
http://www.maximumcompression.com

Preheled webu s tematikou:
http://www.maximumcompression.com
http://dhost.info/paq8/
http://www.squeezechart.com/
http://compressionratings.com/
http://mattmahoney.net/dc/
http://mattmahoney.net/dc/index.html
https://cs.fit.edu/~mmahoney/compression/
http://en.wikipedia.org/wiki/PAQ
http://encode.dreamhosters.com/

U paq8px je nevyhodou i to, ze dekomprese zabere skoro stejne casu jako komprese (i kdyz potrebuje mene RAM o cca ctvrtinu-petinu).

[Honza1Ubuntu]

STALE NENI TADY MOC NAVRHU (JEN MUJ) NA ZADANI, JAKE JE NEJLEPSI NASTAVENI KOMPRESE V 7Z

Maly test pro lzma vs. lzma2.

Nastaveni bylo vzdy toto:
7z a -t7z -m0=lzma -mx=9 -mfb=273 -md=64m -ms=on JmenoArchivu.7z
7z a -t7z -m0=lzma2 -mx=9 -mfb=273 -md=64m -ms=on JmenoArchivu.7z

Data c.1 - textove soubory z daty.
Folders: 364
Files: 1272
Size:       482187948 B

Velikost lzma: 64143646 B
Velikost lzma2: 64158311 B

Data c.2 Linuxove skripty v ruznych verzich, hodne cyklu a pod. Data docela podobna.
Folders: 16
Files: 237
Size:       20059298 B

Velikost lzma: 624962 B
Velikost lzma2: 624273 B

Data c. 3 Linuxove skripty v ruznych verzich, hodne cyklu a pod. K tomu navic 2 datove soubory s cisly (real, integer), tyto stejne soubory na nekolika ruznych mistech. Opet dost podobnosti.

Folders: 24
Files: 535
Size:       236838685 B

Velikost lzma: 3184034 B
Velikost lzma2: 3170817 B

Data c. 4 - hodne excelovych souboru ve formatu do r. 2003. Excelove soubory jsou hodne podobne se stejnym formatem, data v nich se lisi. K tomu pod 10% odhaduji tvori samotne textove soubory s daty (cisla) - format TXT, CSV, DAT. Do cca. 2-3 MB, tedy cca 0,1% dat jsou nekomprimovatelne PNG obrazky (barevna hlobka 8 bit, uroven PNG komprese 9 - max). V nazvech souboru jsou mezery, hacky, carky, blbost z minulych let.

Folders: 213
Files: 6444
Size:       2370465554 B

Velikost lzma: 135076665 B
Velikost lzma2: 134751155 B

Data c. 5 - PNG obrazky, schematickeho typu. Barevna hloubka 24 bit, uroven png komprese 9 - maximalni.

Folders: 49
Files: 5867
Size:       634094047 B

Velikost lzma: 598956622 B
Velikost lzma2: 599022977 B

Tedy lzma2 je o neco lepsi vetsinou, radove setiny procenta Rozdil nikdy nepresahl 0,1%. U lzma2 procento dokonceni archivu i kontroly dat skokove pribyvalo, u lzma1 to bylo plynulejsi. Rychlost je vicemene stejna, mozna lzma2 je o neco rychlejsi. Procesorovy cas na slabem Pc byl delsi nez hodinu akorat u velkeho datoveho souboru (cca. 2,3 GB). CPU jeden blok naraz (a s tim okolo 720 MB RAM pri 64 MB slovniku) to vyuziva na 2 vlakna/jadra, pricemz vetsinou vyuziti je 110-195% normalizovano 1 vlakono = 100 %. paq8px vyuziva jedno vlakno jen, vetsinou k 100%, ten ale ted testovan nebyl (trochu to trva). Jak je to u lzma vs. lzma2 s chybovosti archivu, tod otazka. Ale oboji by melo byt OK a u obou je rozbaleni ci kontrola archivu podstatne rychlejsi nez komprese.

Rychlost na slabem PC je okolo 200-600 kB/s, pri paq8px cca 0,5-2 kB/s

[Honza1]

Nedari se mi prijit na to jak udelat archiv cely jako solid archive.
Deafultne je nastavena velikost sold block 4 GB.

Muzu zkusit napr -ms=65536g a tim bude velikost solid block cca 64 TB.

Nekde jsem nasel  -msNg ale to nevim, jak pouzit.

V manualu velikost solid bloku neni.

[ByCzech]

STALE NENI TADY MOC NAVRHU (JEN MUJ) NA ZADANI, JAKE JE NEJLEPSI NASTAVENI KOMPRESE V 7Z

V zadání je taky, že se má zálohovat co 5 min až 150 MB dat.

[Reklama]

[Honza1]

STALE NENI TADY MOC NAVRHU (JEN MUJ) NA ZADANI, JAKE JE NEJLEPSI NASTAVENI KOMPRESE V 7Z

V zadání je taky, že se má zálohovat co 5 min až 150 MB dat.

To sice jo, ale me to zajima pro moje ucely. A v zadani je relatovne neomezene CPU a RAM (staci 8 vlaken a 16 GB RAM v pohode, ale kdovi kde ma autor strop).

[ByCzech]

Tak to by na jiné zadání možná bylo vhodnější udělat jiné vlákno...

[Ovrscout]

Pro textové sobory(plain-text) zkus použít PPMD (místo toho LZMA2), mohlo by ti to dát lepší výsledky.

[Honza1]

Tak to by na jiné zadání možná bylo vhodnější udělat jiné vlákno...

Ono je to vicemenne to same zadani. Jinak zatim to vypada na nejlepe resenou kompresi:

7z a -t7z -m0=lzma2 -mx=9 -mfb=273 -md=1024m -ms=on -ms=65536g -mmt=2 JmenoArchivu.7z

-ms=65536g znamena Solid Archive az do cca 64 TB (deafultne je to 4 GB), -mtt=2 znamena 2 vlakma multi threating (davat jen jedno vlakno je zbytecne, pro kazdy slovnik dokaze 7z vyuzit2 vlakna, pokud dame -mtt=4(nebo 3), 7z si zabere dvojnasobek pameti na 2 slovniky, pro -mtt=5-6 trojnasobek a pod. Pokud mtt nezadame, znamena to automaticky ano, vyuzije vsechny vlakna. Tim padem ale nemusi stacit RAM a zkonci to padem programu). -md=1024m znamena 1024 MB slovnik. To zabere 10,7 GB RAM + filelist. Slovnik lze zadat tusim az do 4096m (4 GB), coz ale zabere 43 GB RAM + filelist (na jeden blok, tedy -mtt=2 nebo 1). Metoda kmprese -m0=lzma2 ale novejsi 7z si pro jiste typy souboru (exe) zvoli jiny typ automaticky, i kdyz to nezadame. Jinak pro vetsinou souboru pouzije lzma2.

Pro autora - velikost slozek do 150 MB, velikost slovniku tedy 256m postaci. Aby byla vetsi rychlost a jistota, ze se to vzdy stihne do 5 m, tak multithreating na 8 vlakem (4 bloky soucasne). To zabere cca 10,6 GB RAM + filelisst.

Tedy:
7z a -t7z -m0=lzma2 -mx=9 -mfb=273 -md=256m -ms=on -ms=65536g -mmt=8 JemenoArchivu.7z

[Honza1Ubuntu]

Opet jeden dalsi test. Jednalo se o 91.72 GiB dat, grafy a texttove soubory. Celkovy pocet souboru je 10 344 588 a pocet slozek 451 319.

Textove soubory tvori priblizne 17-18% dat (okolo 16-17 GiB) textovych souboru je okolo 460 000, zbytek jsou grafy, png obrazky s kompresi quality 95, barevna hloubka 8 bit, rozliseni 1280x960.

Kód: [Vybrat]

p7zip Version 16.02 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,64 bits,16 CPUs x64)

Nejdriv LZMA1:

Kód: [Vybrat]

7z a -t7z -m0=lzma -mx=9 -mfb=273 -md=1024m -ms=on Archive.7z

Vysledek:

Kód: [Vybrat]

Physical Size = 58343558019
Headers Size = 84804868
Method = LZMA:30
Solid = +
Blocks = 23

Everything is Ok                                                               

Folders: 451319
Files: 10344588
Size:       98566411542
Compressed: 58343558019

Po te jako LZMA2, jako jeden blok (jinak je velikost bloku deafultne 4 GB nebo 4 GiB, jak to bylo v prvnim pripade).

Kód: [Vybrat]

7z a -t7z -m0=lzma2 -mx=9 -mfb=273 -md=1024m -ms=on -ms=65536g -mmt=2 Archive.7z

Vysledek:

Kód: [Vybrat]

Physical Size = 58006341138
Headers Size = 84905891
Method = LZMA2:30
Solid = +
Blocks = 1

Everything is Ok                                                               

Folders: 451319
Files: 10344588
Size:       98566411542
Compressed: 58006341138

Pri velkem poctu souboru je LZMA2 uspornejsi na pamet podle vseho. V pripade LZMA1 to sezralo az 26.5 GB RAM,  v pripade lZMA2 "jen" 20.5 GB RAM, k dispozici je 32 GB.

Zatimco stara verze p7zip do verze 9.20 minimalne radila pri kompresi soubory nejdriv podle pripony, pak podle jmena, pak az podle umisteni v adresari, nova verze radi soubory presne abecedne podle cele cesty (nejdriv podle umisteni v adresari, pak podle jmena abecedne, pak az podle pripony). To ma za vysledek, ze u nove verze je vysledny archiv zbytecne vetsi, u specifickych dat to muze byt obrovsky rozdil.
Snad by tam mel byt nejaky prikaz, jak data radit korektne (tak jako v drivejsich verzich). Zatim nevim jaky.

[Honza1Ubuntu]

Tak nove razeni podle jmena je od verze 15.06 - tam je moznost dvojiho razeni. Deafultne podle jmena abecedne, druha moznost je podle pripony-typu, prepinac -mqs , v graficke verzi pak zaskrtnuti volby qs. Predchozi verze radily vzdy podle pripomy-typu.
Razenim podle pripony-typu je komprese ucinnejsi a vysledny archiv mensi.

Celkovy prikaz pro maximalni kompresy od verze 15.06:

Kód: [Vybrat]

7z a -t7z -m0=lzma2 -mqs -mx=9 -mfb=273 -md=1024m -ms=on -ms=65536g -mmt=2 JmenoArchivu.7z


[Honza1Ubuntu]

Tady jsou vysledky testu 7z vs. paq8px

V pripade lzma2 je pro kazde zapocate vlakna u multi-threading alokovan v ram novy slovnik, proto byly pouzity jen 2 vlakna.
Maximalni velikost slovniku je 1536 MB, misto drivejsich 1024 MB. Maximalni slovnik zabere 16.5 GB RAM plus filelist.

Prikaz pro maximalni moznou kompresi je (co se mi podarilo najit a vyzkouset):
7z a -t7z -m0=lzma2 -mqs -mx=9 -mfb=273 -md=1536m -ms=on -ms=65536g -mmt=2 JmenoArchivu.7z

Pro maximalni kompresi 7z je dulezite uvest prepinac -mqs, jez radi soubory podle typu, jinak jsou razeny abecedne.
Starsi verze 7zip nemaji prepinac -mqs a radi soubory vzdy podle typu.

Rychlost podle typu CPU a dat 500-5000 kB/s, vetsinou 1000-2000 kB/s.
Dekomprese je mnohonasobne rychlejsi.
Drivejsi komprese lzma u starsich verzi 7z mohla byt o par setin lepsi,pri maximalnim 1024 MB slovniku, zato vic to sezralo RAM, pri velkem poctu souboru.
ms je velikost bloku, v GB, takze az do 65.536 TB je archiv z jednoho bloku. Ale nekdy si 7z udela dalsi blok s jinou metodou komprese, kdyz je ta metoda lepsi pro urcity typ dat.

U paq8px je moznost vyuzit jen rizdilnou velikost slovniku. Nejvetsi slovnik (prepinac -8) zabere neco prez 1600 MB RAM a jedno vlakno CPU.
Rychlost v zavislosti na CPU je 2-5 kB/s jen, 1 GB trva nekolik dni, u me okolo tydne.

1. archiv - hodne souboru Excel 2003 s grafy, daty, par textovejch souboru, nekolik malo (stovky kB) PNG obrazku.
Type = 7z
Physical Size = 129067144
Headers Size = 79190
Method = LZMA2:1536m
Solid = +
Blocks = 1
Folders: 213
Files: 6444
Size:       2 370 465 554
Compressed: 129 067 144
Doba vytvareni okolo 1.5 hodiny

Velikost paq8px: 126 906 868
Doba vytvoreni okolo 15000 minut. Jen tady vyhrava paq8px.

Druhy archiv - specialni textovy soubor velky presne 1 GiB. V tomto souboru jsou pouze jednicky a znaky noveho radku - aby to slo co nejvic zmensit.
Type = 7z
Physical Size = 156707
Headers Size = 138
Method = LZMA2:30
Solid = -
Blocks = 1
Size:       1 073 741 824
Compressed: 156 707
Doba vytvareni okolo 15 minut

Velikost paq8px: 378 374
Doba vytvoreni okolo 10000 minut

Treti archiv - PNG obrazky s barevnou hloubkou 8 bit, maximalni komprese PNG 9. Zde bude komprese 7z vicemene nulova.
Data maji jen 569 MiB, proto 7z zvoli maximalni mozny slovnik pro cely archiv 768 MB
Type = 7z
Physical Size = 596451652
Headers Size = 70334
Method = LZMA2:768m
Solid = +
Blocks = 1
Folders: 49
Files: 5867
Size:       634 094 047
Compressed: 596 451 652
Doba vytvareni okolo 7 minut

Velikost paq8px - 1 187 866 833 - naprosto necekane nastal narust.
Doba vytvoreni okolo 7000 minut.

Ctvrty archiv - mnoho rozsahlych i malych skriptu bash, jejich ruzne verze v case a par souradnicovych textovych souboru.
Vzhledem k ruznym verzim je podobnost mezi soubory vyskoka.
Type = 7z
Physical Size = 26653854
Headers Size = 101573
Method = LZMA2:1536m LZMA:20 BCJ2
Solid = +
Blocks = 2
Folders: 1208
Files: 13144
Size:       3 287 918 624
Compressed: 26 653 854
Doba vytvareni cca 2 hodiny

Velikost paq8px: 28 693 188
Doba vytvoreni okolo 22000 minut

Paty archiv - skripty a casto rozsahle textove soubory se souradnicemi. Lisi se vice-mene jen nastaveni, podobnost mexi soubory je obrovska.
Type = 7z
Physical Size = 44914889
Headers Size = 17300
Method = LZMA2:1536m
Solid = +
Blocks = 1
Folders: 60
Files: 2298
Size:       3 470 148 572
Compressed: 44 914 889
Doba vytvareni cca 2.5 hodiny

Velikost paq8px: 305 756 083
Doba vytvoreni okolo 28000 minut

Ted archiv s extremnim poctem souboru - vetsinou jsou t grafy - PNG obrazky 256 barev, konverze -quailty 95, rozliseni 1280x960
Krome grafu je asi 18% velikosti a 5% poctu souboru jako textova data.
Slovnik byl pouzit 1024 MB, 2 vlakna (jeden slovnik naraz). lzma si vzala 27 GB RAM, lzma2 20.5 GB RAM. Jen kontrola spotrebuje RAM 4103 MB virt, 3.9 GB RES.
Pri velkem poctu souboru je lzma2 uspornejsi na pamet nez lzma.
paq8px zde samozrejme nezkouseno, asi by to ani nemelo smysl.
Doba vytvareni 7z okolo 30 hodin (cca 3300 minut CPU casu)
Type = 7z
Physical Size = 58605641722
Headers Size = 86105422
Method = LZMA2:30
Solid = +
Blocks = 1
Folders: 451 319
Files: 10 344 588
Size:       98 566 411 542
Compressed: 58 605 641 722

Archiv s mnoho malymi soubory TXT. Soubory jsou hodne podobne, jeden tadovy soubor v ruznych verzich je na ruznych mistech.
Z duvodu hodne malych souboru je komprese (cca 40 hod) i rozbaleni (cca 10 hod) o dost pomalejsi.
Type = 7z
Physical Size = 307417835
Headers Size = 13591949
Method = LZMA2:30
Solid = +
Blocks = 1
Folders: 251
Files: 8 808 081
Size:       19 431 833 053
Compressed: 307 417 835
Archiv ma 294 MiB, bez pouziti -mqs okolo 1500 MiB. Pokud se data nejdriv zataruji, ma archiv okolo 1500 MiB. paq8px nezkouseno.

A jeste jeden archiv. Jedna se o slozku s desetitisici datovymi soubory v kazde verzi a tech verzi je 47.
Datove soubory jsou si v jednotlivych verzich dosti podobne. Podobnosti mezi soubory je tu mnoho.
Jeden tadovy soubor v ruznych verzich je na ruznych mistech.
Velikost dat je temer 2 TiB.
Pouzit byl slovnik 1024 MB, vzalo si to RAM 11.5 GB virt 11 GB RES.
Doba vytvareni 7z okolo 36 000 minut CPU casu, 23.3 dni to bezelo, prumerna zatez 106% CPU (2 vlakna na jeden slovnik v RAM)
Type = 7z
Physical Size = 3702993437
Headers Size = 8373990
Method = LZMA2:30
Solid = +
Blocks = 1
Folders: 86
Files: 1388977
Size:       2 022 208 880 899
Compressed: 3 702 993 437


paq8px SE TEDY ANI NEMUSI VYPLATIT, DOBRE NASTAVENY 7Z MUZE CASTO VYHRAVAT - 4 Z 5 PRIPADU VYHRAL 7zip.
Navic u paq8px je rychlost brutalne nizka, velka narocnost CPU. U paq8px je navic cca stejna narocnost rozbaleni jako zabaleni.
7z je pri rozbalovani mnohem rychlejsi - 10-15 MB/s archivu (nikoliv nerozbalenych dat, tam casto limituje disk).
7zip vyhrava tam, kde je velke mnozstvi hodne podobnych souboru, jinak si vede lip spis paq8px
paq8px nema kontrolu dat, rozbaleni i zabaleni trva hodne dlouho, neni mozne uzit multi-threading.

[Spoon]

paq8px nema kontrolu dat, rozbaleni i zabaleni trva hodne dlouho, neni mozne uzit multi-threading.

Tady mas multithreadovy klon zvany zpaq http://mattmahoney.net/dc/zpaq.html dej vedet jestli se rychlost zlepsi.

[Honza1]

paq8px nema kontrolu dat, rozbaleni i zabaleni trva hodne dlouho, neni mozne uzit multi-threading.

Tady mas multithreadovy klon zvany zpaq http://mattmahoney.net/dc/zpaq.html dej vedet jestli se rychlost zlepsi.

Zkusim az bude cas.
zpaq by melo mit i pri jednom vlakne vyssi rychlost, nebot paq8px je delany na absolutne maximalni kompresi, odtud rychlost 1-5 kB/s i na dost silnym CPU.
zpaq bz melo mit s kaydzm vlaknem rzchlost vzssi nez paq8px a multithreading proces jeste urzchli, ale zabere vic RAM. I tak je pro paq procesorovz cas nesrovnatelne vyssi, nez u 7z. Na RAM to tak strasny neni.

[Honza1Ubuntu]

Dalsi mensi test

U kazdeho archivu jsou paeametry nastavei
#########################################################################################################

A) Jedna se o nekolik grafu vytvorenych v Gnuplotu 2000x1000 bodu, par grafu 3000x1000 bodu, barev tam tolik neni, jen cervene body, nebo linie. Proto obrazky 24 Bit i 8 Bit barevne hloubky vypadaji stejne a velikost je skoro stejna.

Puvodni obrazek PNG, prez BMP konvert do 24 Bit a prez GIF konvert do 8 Bit barevne hloubky. Ulozeni PNG: convert quality 95.

Rozliseni 2000x1000 nektere grafy 3000x1000
2 357 771 B SWM08.7z PNG 8 bit PNG
1 249 712 B SWM08_BMP.7z 8 Bit BMP
3 619 839 B SWM1.7z After Gnuplotting original PNG Files
2 358 820 B SWM24.7z PNG 24 Bit PNG
1 560 653 B5 SWM24_BMP.7z BMP 24 Bit BMP
Parametry komprimace u vsech archivu:   7z a -t7z -m0=lzma2 -mqs -mx=9 -mfb=273 -md=64m -ms=on -ms=65536g -mmt=2
#######################
BMP08 data:
Everything is Ok
Folders: 8
Files: 238
Size:       255 048 076 B
Compressed: 1 249 712 B
#######################
PNG08 data:
Everything is Ok
Folders: 8
Files: 238
Size:       3 323 802 B
Compressed: 2 357 771 B
#######################
BMP24 data:
Everything is Ok
Folders: 8
Files: 238
Size:       1 030 208 774 B
Compressed: 1 560 653 B
#######################
PNG24 data:
Everything is Ok
Folders: 8
Files: 238
Size:       3 319 994 B
Compressed: 2 358 820 B
#######################
PNG24 Originalni soubory vytvorene Gnuplotem
Everything is Ok
Folders: 8
Files: 238
Size:       5 294 868 B
Compressed: 3 619 839 B
#######################

#########################################################################################################

B) Podobna vec - automaticke printscreen html stranky pomoci NodeJS. Stranka obsahuje barevnou tabulku, JPG se tedy absolutne nehodi.

Nejmensi velikost archivu ma zkomprimovane BMP v hloubce 24 Bit (mensi nez BMP v houbce 8 Bit). Zato rozbaleni a komprimace BMP je mnoho-nasobne delsi nez PNG, stejne tak, jako objem dat.

400 452 683 B Ogimet_Data_Daily_PrintScreens_Lite_BMP.7z  7z a -t7z -m0=lzma2 -mqs -mx=9 -mfb=273 -md=64m -ms=on -ms=65536g -mmt=2
925 626 546 B Ogimet_Data_Daily_PrintScreens_Lite_PNG08.7z  7z a -t7z -m0=lzma2 -mqs -mx=9 -mfb=273 -md=64m -ms=on -ms=65536g -mmt=2
Nejlepsi komprese pro BMP 24 bit, druha nejlepsi BMP 08 bit, treti nejlepsi pro PNG 08 bit
Archiv z puvodnich PNG24 bez konvertu mel prez 2 GiB
#######################
Uvnitr archivu:
PNG08:
Everything is Ok
Folders: 28
Files: 6048
Size:       941 631 614 B
Compressed: 925 626 546 B
#######################
BMP24:
Everything is Ok
Folders: 28
Files: 6048
Size:       34 063 170 624yl B
Compressed: 400 452 683 B

#########################################################################################################

C) Test datove soubory CSV, oddelovac strednik. Vetsina znaku v souboru jsou cisla.

Byl vytvoren archiv z puvodnich dat (komprimace slozky), tak byl vytvoren nejdriv TAR soubor a pak zkomprimovan.

OGIMET CSV DATA
Vytvoreni archivu z adresare
503 339 454 B Ogimet_CSV_201711_64.7z 7z a -t7z -m0=lzma2 -mqs -mx=9 -mfb=273 -md=64m -ms=on -ms=65536g -mmt=2
485 767 317 B Ogimet_CSV_201711.7z 7z a -t7z -m0=lzma2 -mqs -mx=9 -mfb=273 -md=1536m -ms=on -ms=65536g -mmt=2 Velky slovnik sezere 16.5 GB RAM !!! Nejlepsi vysledek
535 219 878 B Ogimet_Data_CSV_201711.paq8px paq8px_v69 -8 (cca 1.7 GB RAM cca 33000 min CPU Time)

vytvoreni TARu a pak komprese
3 342 653 440 B Ogimet_CSV_201711.tar NORMAL TAR tar -cf file.tar *
555 309 052 B Ogimet_CSV_201711b.tar.xz xz -9 -T 1
554 798 645 B Ogimet_CSV_201711_TAR_64.7z  7z a -t7z -m0=lzma2 -mqs -mx=9 -mfb=273 -md=64m -ms=on -ms=65536g -mmt=2
554 862 908 B Ogimet_CSV_201711.tar.xz xz -9e -T 1
549 644 276 B Ogimet_CSV_201711.tar.xz  xz -9e -T 1 TAR Soubor 3 342 878 720 B Pokus o Sorted TAR, Data uvnitr TARu stejna
#######################
DATA UVNITR ARCHIVU
CSV soubory, hodne cisel
Everything is Ok
Folders: 19
Files: 2983
Size:       3 340 330 625 B
Compressed: 503 339 454 B