Dotaz: btrfs compress

[chinook]

Mám pár nejasností u komprese na btrfs
Jak udělat compress pouze na subvolume? Jestli jsem to dobře pochopil, je možné komprimovat pouze adresář. Tzn. subvolume nomountuji na nějaký adresář s parametrem compress.
Jaké jsou podmínky, aby mně to fungovalo jen na subvolume? Musím mít nenamauntovaný volume?
Tedy

umount /data
mount -o compress,subvol=vmail /data/vmail

Co když jsem vytvořil BTRFS na / Mohu zkomprimovat pouze adresář? Pokud ne, je možnost bez reinstalace systému vytvořit ze subvolume volume?
A jakou kompresy volit pro maily? Maily mně to moc nekomprimuje :( To je tím, že tam je málo textu? Jestli to dobře chápu, je uspora místa nějakých 10GB
Nejdříve jsem zkusil zlib a pak lzo

/dev/vdb on /data/vmail type btrfs (rw,relatime,compress-force=zlib,space_cache,subvolid=257,subvol=/vmail)
btrfs filesystem df /data/vmail/
Data, single: total=657.01GiB, used=646.47GiB
System, DUP: total=8.00MiB, used=96.00KiB
Metadata, DUP: total=6.00GiB, used=3.41GiB
GlobalReserve, single: total=512.00MiB, used=0.00B
mount | grep mail
/dev/vdb on /data/vmail type btrfs (rw,relatime,compress-force=lzo,space_cache,subvolid=257,subvol=/vmail)
btrfs filesystem defragment -c /data/vmail/
btrfs filesystem df /data/vmail/
Data, single: total=662.01GiB, used=647.68GiB
System, DUP: total=8.00MiB, used=96.00KiB
Metadata, DUP: total=4.50GiB, used=3.20GiB
GlobalReserve, single: total=512.00MiB, used=38.06MiB


---

---

Odpovědi

[Aleš Kapica]

Čti.

Komprimují se extenty, tj. datové bloky a v reálném čase vždy, pokud to procesor stíhá a nemáš to implicitně zakázané. Kompresní poměr se mění v závislosti na tom jak je procesor zatížený. Pokud nestíhá, nebo by byla komprese neefektivní, nekomprimuje vůbec. Vždy můžeš kompresi aplikovat dodatečně.

Já mám kupř. kompresi implicitně zakázanou. Komprimuji extenty jedině v případě že potřebuji nutně uvolnit místo a nevím co smazat. Komprese, i dekomprese extentů snižuje reálný výkon a já si tak tímto způsobem vědomě vytvářím únikový prostor.

[Trubicoid2]

S tím zatíženým CPU to je fakt? Já myslel, že se automaticky vypne komprese pokud první MB nejde komprimovat. Což je blbý, pokud soubor začíná nekomprimovatelně a pak komprimovatelný je.

Jinak aplikovat určitou kompresi jde jen tím defrag? To není zrovna šetrné k ssd. A komprimuje se i soubor, který defragmentovat nepotřebuje?

[Aleš Kapica]

Jak to přesně interně funguje nepovím, protože to pro mne není podstatné. Pokud jde o to CPU, tak je vcelku logické že si komprese a dekomprese něco vezme. Ale jak jsem uvedl. Pokud nestíhá, nekomprimuje.

U ssd ta komprese dává smysl opravdu jen v situaci kdy je třeba získat nějaké místo. Zkomprimovaný extent se nemění. Nový se mi zapíše jako nekomprimovaný.

[petr]

dle jejich wiki pokud pocatek souboru se spatne komprimuje, tak ostatni data nekomprimuji... IMHO zase < ironie >nesporne vyhody tohodle alfa fs< /ironie >.

[Sten]

Tohle dělá i ZFS V Btrfs se ta detekce dá vypnout pomocí „compress-force“.

[petr]

"Komprese, i dekomprese extentů snižuje reálný výkon" - u btrfs je to evidentne pravda, ale treba u ZFS ma komprese, dekomprese mozna negativni vykon na CPU, ale v pripade IO ma spise pozitivni vykon.

[Want]

Ty tomu teda ale fakt rozumíš. Nechceš dělat prezidenta hospodářské komory?

[petr]

Tak evidentne vice nez ty. Kolik mas diskovych poli s vice nez 150TB dat? Ja 6. U zapisu je diky kompresi potrebnych min IO, u cteni dostanes do ram vice dat rychlejc. Kdyby jsi porad mel pochybnosti, zkus pouzit google a hledej treba zfs compression performance impact. Ze to btrfs neumi je jina vec.

[Aleš Kapica]

A na kolika z těch tvých polí máš Btrfs, že jsem tak smělý?

[j]

A to musi fs umet? Skoro bych rek, ze to ja tak nejak vlastnost od prirody - ze se komprimovanych dat zapisuje a cte min. Pokud mas stroj vyhrazenej jako uloziste, tak te asi CPU nepali, ale pokud to ma jeste neco delat, tak by te to palit mohlo, protoze ono trebas komprimovat Gbit onfly uz da kour ledacemus.

[chinook]

Mám tam nastaveno compress-force, takže CPU by na to mít vliv nemělo.

[trubicoid2]

... Jestli to dobře chápu, je uspora místa nějakých 10GB
Nejdříve jsem zkusil zlib a pak lzo

/dev/vdb on /data/vmail type btrfs (rw,relatime,compress-force=zlib,space_cache,subvolid=257,subvol=/vmail)
btrfs filesystem df /data/vmail/
Data, single: total=657.01GiB, used=646.47GiB
System, DUP: total=8.00MiB, used=96.00KiB
Metadata, DUP: total=6.00GiB, used=3.41GiB
GlobalReserve, single: total=512.00MiB, used=0.00B
mount | grep mail
/dev/vdb on /data/vmail type btrfs (rw,relatime,compress-force=lzo,space_cache,subvolid=257,subvol=/vmail)
btrfs filesystem defragment -c /data/vmail/
btrfs filesystem df /data/vmail/
Data, single: total=662.01GiB, used=647.68GiB
System, DUP: total=8.00MiB, used=96.00KiB
Metadata, DUP: total=4.50GiB, used=3.20GiB
GlobalReserve, single: total=512.00MiB, used=38.06MiB


no uspora 10GB oproti cemu? ja vidim, ze lzo zabere o 1GB vic nez zlib (koukej na data used, total je vzdy vic a da se zmensit viz. -duasge), ale asi by to melo byt o vic? je potreba zkusi taky bez komprese a uvedomit si, ze komprese jako mount parametr nezmeni jiz ulozene soubory, jen nove zapsane tedy je potreba bud tam vse dat znovu, nebo pouzit btrfs filesystem defragment -r -v -clzo /data/vmail

[chinook]

Aha, já ten parametr used blbě chápal. Celkově to zabírá:

690G /data/vmail/

Takže nějaká úspora tam je, i když jsem čekal větší.

Díky za vysvětlení.

[trubicoid2]

ja bych myslel, ze neni vsechno komprimovano, bych to jeste prejel tim compress -clzo a pak -czlib a pak by se videlo

[chinook]

Dal jsem:

btrfs filesystem defragment -r -clzo /data/vmail

Výsledek:

btrfs filesystem df /data/vmail/
Data, single: total=639.01GiB, used=634.95GiB
System, DUP: total=8.00MiB, used=96.00KiB
Metadata, DUP: total=4.50GiB, used=3.32GiB
GlobalReserve, single: total=512.00MiB, used=0.00B
root@imap2:/# du -sh /data/vmail
687G    /data/vmail

[trubicoid2]

Tak trochu to pomohlo, ale ne moc. Asi posilaji moc nekomprimovatlenych priloh :)

[Kit]

Určitě by to bylo zajímavější, kdyby se ty přílohy daly deduplikovat. Jenže to je příliš sci-fi.

[chinook]

Evidentně v tomto případě je komprese k ničemu. Jak to tedy rozšifruji?

[trubicoid2]

rozsifrovat jako rozkompresovat? tim defrag to pry neni zatim podporovany, takze smazat a nakopirovat znova, kdyz bude primountovany bez komprese

je potreba kopirovat jakoby z jineho fs, protoze jinak se udela jen reflink a dekomprese neprobehne

a deduplikace by asi sla, zkus duperemove -dr --hashfile=/var/tmp/dupe.sqlite /cesta

[j]

2chinook: Volume nebo subvolume je sumak, chova se to prakticky stejne. Zpusobem primountovani jen rozhodujes o tom, jestli se aktualni mountpoint pro !nove zapisy! bude komprimovat. A samozrejme ze maily s prilohama, ktery sou prevazne uz komprimovany, se moc nezkomprimujou, to je logicky ne?

Pokud bys chtel zkomprimovat to co uz neni, musel bys to v ramci toho disku kopirovat (= ne reflink). Pripadne na to mozna je nejakej tool kterej to vynuti, ale vysledek bude stejnej - komprimuje se jen pri zapisu. Ne pri namountovani. Stejne tak samozrejme prectes veskery data i pokud mount je bez komprese. Ale zase se "samo" nic nedekomprimuje.

[Vantomas]

No ty soubory, které jsou plné base64 docela zkomprimovat půjdou...

[chinook]

Hmmm. Když namountuju volume s compress, tak jsou i subvolume. Ale pokud chci jen subvolume s compress, tak to ten parameter ignoruje. Nebo jak to ověřím? POkud vypíšu mount, tak tam comress nevidím.

[Sten]

Parametry se použijí při prvním namountování pro všechny subvolume a při dalším mountování se ignorují. Pokud chcete komprimovat jen jeden subvolume, tak musíte použít atribut c.

[chinook]

Kde použít atribut c?

[Sten]

Na soubory a adresáře toho subvolume.

[chinook]

Můžeš prosím napsat příkaz? Vůbec nevím co myslíš. Je to volba u mount, nebo defragment nebo kde?

[chinook]

chattr +c -R /mount/point

[Vantomas]

Jak je to u těchto atributů, když se vytvoří podadresář? Zdědí se to z nadřazeného nebo se to ztratí?

mkdir /mount/point/subdir

[Vantomas]

Vyzkoušel jsem si to sám. Ano, zdědí se to.

vantomas@tomova-bedynka ~/tmp $ mkdir test ------------------- ./test vantomas@tomova-bedynka ~/tmp $ chattr +c test vantomas@tomova-bedynka ~/tmp $ lsattr --------c---------- ./test vantomas@tomova-bedynka ~/tmp $ cd test/ vantomas@tomova-bedynka ~/tmp/test $ mkdir test2 vantomas@tomova-bedynka ~/tmp/test $ lsattr --------c---------- ./test2 vantomas@tomova-bedynka ~/tmp/test $ cd test2/ vantomas@tomova-bedynka ~/tmp/test/test2 $ touch testfile vantomas@tomova-bedynka ~/tmp/test/test2 $ lsattr --------c---------- ./testfile vantomas@tomova-bedynka ~/tmp/test/test2 $

[Sten]

A tedy ještě pozor na to, že ani tohle nezmění data již zapsaná na disku, pouze nově zapsané bloky.