Tedy zhruba tak:
-Mapa do Garmina (binarni data cca 1.3 GB) spadla zhruba na pulku.
-Openoffice text a tabulka spadly jen malo, coz se dalo cekat, je to jiz komprimovane uvnitr.
-Komprese maleho textoveho souboru (cca 3 kB) je skoro stejne spatna, jako u Openoffice souboru.
-Komprese vetsiho textoveho souboru (cca 40 kB) srazila velikostzhruba na pulku.
-Html jedne vetsi stranky Rootu spadlo na sestinu.
-Komprese 250 kB xml srazila velikost na cca tretinu.
-Komprese Matrosky je zanedbatelna, coz se dalo cekat. Ale to neni tak zle, protoze na NT 4.0 takove soubory zabiraly po kompresi vice mista, nez pred ni.
-Komprese linuxove binarky GIMPu (cca 4 MB) srazila velikost zhruba na pulku.
Cili jak co. Vysledky se zdaji byt docela slusne. Komprese na Atomu se zda byt docela rychla. Rozdil mezi pouhym kopirovanim souboru a jeho kompresi na jine misto asi nebude zavratny, akorat bych tipoval na vyssi zatez procesoru. Pokud je ale pravda to, co pisi v manualu k lzop, tak by zatez pri kompresi nemela byt tragicka, protoze je kompresni pomer omezen v zajmu rychlosti (i kdyz se da navolit vyssi komprese a pak nepochybne klesa rychlost). Pokud se da navolit jiny kompresni pomer i na Btrfs, asi to bude take tak. Rychlost dekomprese by mela byt vzdy vysoka.
Cili kdybych mel Btrfs, asi bych to zkusil. Zejmena pokud se da komprese zapnout selektivne po souborech a adresarich, abych ji mohl zapnout tam, kde to ma smysl. Tedy napriklad ne na adresari s filmy, ale napriklad na adresari s texty, xml, html ano. Take mozna ne na velkych souborech, ktere s maji menit (databaze), kde by to asi dost otravovalo.