Fórum Root.cz
Hlavní témata => Software => Téma založeno: rado3105 29. 11. 2012, 22:08:47
-
Mam na notebooku stary intel m procesor, 1,5ghz....viete poradit ci ma vyznam zapinat lzo kompresiu btrfs? ci to bude zvladat? nemam v zaujme aby stale siel zbytocne notebookov chladic naplno....
-
Prihreju si polivcicku: Jak moc ucinna je ta komprese? Na NTFS to typicky dela tak 50 % puvodni velikosti souboru u souboru, ktere jdou komprimovat. Jak je na tom btrfs?
-
Muzes vzit lzop a sva data a vyzkouset aniz bys experimentoval s btrfs.
-
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.
-
Otázka je, proč tedy vlastně komprimovat.
Co zabírá nejvíc místa?
Filmy, fotky, hudba, obojí už komprimované.
A co určitě nekomprimovat tak to jsou často měněné soubory.
Proto si nemyslím, že zkomprimování adresáře ETC někoho vytrhne.
Dokonce ani logy není dobré defaultně komprimovat, do zkomprimovaného souboru se je problém jen tak něco připsat a musí se zapsat celý znovu, viděl jsem, jak komprese slušně zabila systém jen protože se pořád znovu a znovu komprimovalo několik souborů.
Co tedy zkomprimovat?
A kolik ušetříme místa?
1GB na 1T disku?
Vyplatí se k vůli tomu ta komprese?
Myslím tedy, že komprese je vhodná pro čistě specifické účely.
Může se hodit například na webserveru, kde je silnější CPU než diskový systém, protože malý soubor se načte rychleji než velký a zpoždění v paměti nehraje roli. Může se hodit na počítači, kam se ukládají nějaké textové logy, například se stahují data z ústředny ve formátu TXT. ....
Hm?
Nebo se pletu?
-
Nie je to celkom k veci, ale určite to má súvis. Mám doma malý server s Intel Atom D525, je na ňom FreeBSD-9.0, na diskoch je zfs a kompresiu mám zapnutú na väčšine oddielov. Používam rôzne kompresie podľa rôznych doporučení a nikdy som sa nestretol s problémami s rýchlosťou diskov. Skôr si myslím, že výkon sa proti tomu, ako keď boli bez komprimácie, dosť zvýšil. Kôli úspore miesta kompresiu naozaj nepotrebujem, disky sú obsadené sotva z pätiny ich kapacity.
-
@KapitánRUM: Pokud je nekdo treba vyvojar webu nebo programator a ma na disku tunovy archiv zdrojaku, tak komprese odpovidajicich adresaru nemusi byt od veci. Archiv .iso souboru by ji take asi uzivil, .iso obvykle docela zkomprimovat jde.
-
nu vono taky zalezi, co v tom iso je
-
-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.
To se mi nezdá, jestli jde o kompresi pomocí vestavěné komprese ve Windows, tak ta funguje tak, že komprimuje po 64KB blocích a bloky ukládá komprimovaně pouze v případě, že se podaří změnšit blok aspoň o jeden sektor/cluster, jinak se uloží nezkomprimovaný, proto se divím, že by to vyšlo komprimovaně větší.
(mimochodem, vývojáři z btrfs jsou v tomhle lameři, protože podle všeho komprimují celý soubor a to při každé změně znova a znova. Stejně funguje fusecompress, což činí tyto chabé pokusy linuxových vývojářů naprosto nepoužitelnými).
-
(mimochodem, vývojáři z btrfs jsou v tomhle lameři, protože podle všeho komprimují celý soubor a to při každé změně znova a znova. Stejně funguje fusecompress, což činí tyto chabé pokusy linuxových vývojářů naprosto nepoužitelnými).
Je možné, že komprese jednotlivých bloků na úrovni filesystému je v USA patentovaná, protože oni si rádi patentují obecné věci, na které přijde šest vývojářů s flaškou rumu za jeden večer. Ale také mám toto podezření, protože zmíněný jeden stroj mi zabilo postupné dopisování řádek do souboru o velikosti 400MB. Než se na něj zapnula komprese, tak byl velký, ale disk si jen tak občas bliknul.
Po zapnutí komprese svítil trvale a se strojem se nedalo dělat.
-
(mimochodem, vývojáři z btrfs jsou v tomhle lameři, protože podle všeho komprimují celý soubor a to při každé změně znova a znova. Stejně funguje fusecompress, což činí tyto chabé pokusy linuxových vývojářů naprosto nepoužitelnými).
Je možné, že komprese jednotlivých bloků na úrovni filesystému je v USA patentovaná, protože oni si rádi patentují obecné věci, na které přijde šest vývojářů s flaškou rumu za jeden večer. Ale také mám toto podezření, protože zmíněný jeden stroj mi zabilo postupné dopisování řádek do souboru o velikosti 400MB. Než se na něj zapnula komprese, tak byl velký, ale disk si jen tak občas bliknul.
Po zapnutí komprese svítil trvale a se strojem se nedalo dělat.
To bude chyba někde jinde, schválně jsem to teď otestoval a BTRFS rozhodně nepřepisuje soubor znovu (BTW: kde jste na to přišli?):
# time cat /mnt/zalohy/main/syslog >> /mnt/zalohy/main/test.img
real 0m0.056s
user 0m0.004s
sys 0m0.024s
# ls -l /mnt/zalohy/main/test.img
-rw-r--r-- 1 root root 80039242259 Dec 3 22:44 /mnt/zalohy/main/test.img
# mount | grep zalohy
/dev/xvdb1 on /mnt/zalohy type btrfs (rw,noatime,nossd,compress-force,subvol=zalohy)
... nemáte zaplý autodefrag?
jinak starý NB je rázem svižnější když byl již nainstalován s kompresí, slušně urychlí čtení z pomalého disku
bohužel však rychlost práce s velkými soubory není zrovna omračující :( (v tomto případě spíše srovnatelná s EXT3, ale naprosto mimo ve srovnání s EXT4, XFS...):
# time rm /mnt/zalohy/main/test.img
real 0m3.015s
user 0m0.000s
sys 0m1.288s
-
-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.
To se mi nezdá, jestli jde o kompresi pomocí vestavěné komprese ve Windows, tak ta funguje tak, že komprimuje po 64KB blocích a bloky ukládá komprimovaně pouze v případě, že se podaří změnšit blok aspoň o jeden sektor/cluster, jinak se uloží nezkomprimovaný, proto se divím, že by to vyšlo komprimovaně větší.
Tohle to delalo na NT 4.0. Od te doby s tim MS snad neco udelal, ale nevim, od ktere verze Widli to veslo v platnost.
-
dam ti radu, odinstaluj btrfs skor nez prides o data
-
bohužel však rychlost práce s velkými soubory není zrovna omračující :( (v tomto případě spíše srovnatelná s EXT3, ale naprosto mimo ve srovnání s EXT4, XFS...):
xfs naopak byva na velkych souborech dost rychly, navic umelo defragmentaci uz v dobe, kdy jeste ani nebylo ext4, ani btrfs, natoz ext4defrag
-
xfs som raz mal, raz sa system vypol natvrdo a uz nenabehol, pretoze xfs nemalo opravu dat...neviem ako teraz.
BTRFS mam asi 3 mesiace na archlinuxovom notebooku, vypnute natvrdo asi 10x - dosla baterka a neuvedomil som si to a system stale funguje ako hodinky.....