Dva měsíce s Btrfs: zkušenosti a postřehy

Zprvu je nutno říci, že mám disk rozdělen na dvě části – malou část /boot s ext2 (protože alespoň v době instalace GRUB stále Btrfs neznal) a na zbytku disku je pak jeden velký oddíl s Btrfs. Protože se jedná o pracovní notebook, který občas tahám i mimo, /home je samozřejmě šifrované (pomocí ecryptfs). Z toho vyplývají některé neduhy (nefungující komprese, nepohodlná obnova těchto dat ze snapshotů), pro účel článku to však není důležité.

Snapshoty – pohodlné cestování v čase vašich dat

Snapshot je mechanismus, jak si zapamatovat stav dat tak, jak v dané chvíli na disku byl. Funguje trochu jako záloha proti vlastní blbosti. V okamžiku, kdy vytvoříte snapshot, si systém řekne „ha, tenhle stav si zapamatuju“, ale nic nikam nekopíruje ani nic moc nezapisuje. Když ale pak dojde třeba k přepsání souboru, řekne si „uživatel chce přepsat tenhle soubor, ale ten je součástí snapshotu. Tak já ten nový obsah zapíšu na jiné fyzické místo na disku, a zapamatuji si obě verze“. V souboru je samozřejmě vidět nový obsah, ale lze se lehce dostat i k původní verzi. Toto přitom nefunguje na úrovni souborů, ale přímo na úrovni jednotlivých bloků, a tedy včetně adresářové struktury a podobně. Důležité je, že snapshot zabírá navíc jen tolik místa, kolik toho po jeho vytvoření nově přepíšete. Když typicky přepisujete jen pár souborů, navíc vzhledem k disku velikostně malé kousky dat, můžete zpětně udržovat mnoho obrazů kompletní adresářové struktury.

K čemu to je? Představte si třeba situaci, kdy si omylem smažete nebo přepíšete nějaké soubory, třeba zdrojáky, dokumenty nebo nastavení programu. Anebo vyzkoušíte nový hudební přehrávač a ten vám „namrší“ celou složku s hudbou. Nebo aktualizujete program, ten přestane fungovat a starší verzi už nemůžete sehnat. Co teď? Jednoduše se podíváte do některého z předchozích snapshotů, a data si zpět zkopírujete.

Možná si teď říkáte, že na tohle existují nejrůznější programy pro správu verzí. Dokonce existují i transparentní verzovací souborové systémy přes FUSE, např. CopyFS. Jenže… o CVS se musí člověk starat, nějak se v tom angažovat, není to „samo“, navíc je to nevhodné a neefektivní pro větší objemy dat. Systémy přes FUSE mají nevýhodu vyplývající z FUSE – rychlost, složitější mountování a správa. Aby nedošlo k nedorozumění, snapshoty rozhodně nejsou náhradou za verzovací systém, ač fungují podobně, a už vůbec nejsou plnohodnotnou zálohou. Jsou však velice jednoduchým a rychlým způsobem, jak vytvořit obraz celého disku přímo na úrovni FS.

Vytvoření snapshotu je velice jednoduché a lze ho připojit kamkoliv; třeba do aktuálního adresáře, jako v následujícím příkladu:

$ pwd
/tmp
$ echo Ahoj > a
$ cat a
Ahoj
$ btrfs subvolume snapshot / prvni
Create a snapshot of '/' in './prvni'
$ echo Nazdar > a
$ cat a
Nazdar
$ cat prvni/tmp/a
Ahoj
$ sudo btrfs subvolume list /
ID 302 top level 5 path tmp/prvni
$ sudo btrfs subvolume delete prvni/
Delete subvolume '/tmp/prvni'
$ cat a
Nazdar

Zde je potřeba říci pár věcí: snapshot se ihned přimountuje do zadaného umístění a je přepisovatelný (read-only snapshoty teprve brzy budou). Jedná se tedy de facto o dva nezávislé obrazy dat, které jsou z tohoto pohledu rovnocenné. Snapshoty jsou sice automaticky přimountované, nejsou však vidět ve výpisu z příkazu mount. Ne na všechny operace je nutno mít práva roota; na vytvoření snapshotu to například potřeba není. Tohle je ovšem předmět debaty a je možné, že se v budoucích verzích Btrfs chování změní.

Není také možné udělat pevný odkaz souboru mezi snapshoty. Každý snapshot (přičemž základní stav je vlastně snapshot) je označen jako jiné zařízení. Vytvořit snapshot je možné jen v rámci celého disku, nikoli adresáře. Dále bohužel zatím není možné zjistit, kolik jednotlivé snapshoty zabírají, resp. kolik místa se jejich vymazáním uvolní.

Pokud chcete pohodlně verzovat, doporučuji zálohovací skript z wiki – více viz popis. Je možno zálohovat automaticky cronem, já ale zálohuju ručně. Je to z toho důvodu, že vím kdy nemám na disku žádná dočasná data – pokud bych třeba rozbalil na disk ohromný archiv, vytvořil se snapshot a já ten rozbalený archiv ihned pro nepotřebnost smazal, data by byla stále v snapshotu a zabírala místo na disku tak dlouho, než bych ho časem nevymazal. Tímto způsobem bych mohl zaplnit disk dříve než je žádoucí.

Z hlediska snapshotů je dalším pozoruhodným souborovým systémem NILFS2. Ten vytváří snapshoty automaticky po každém zápisu (třeba co pět sekund), čímž jsou zálohy de facto kontinuální. Potom lze říci, které z těch snapshotů se mají nechat trvale; ostatní se budou jednoduše samy odmazávat, když už nebude místo. Neviděl jsem však žádné reálné nasazení a ani FS sám nemá příliš dalších zajímavých vlastností.

Konečné řešení duplicitních souborů aneb chytrý hardlink

Reflink je věc podobná snapshotu, ale jen v rámci jednoho souboru. Například chcete mít na disku z nějakého důvodu jeden soubor dvakrát. Na tradičních systémech máte dvě možnosti, jak ušetřit místo – pomocí symbolického odkazu a pomocí pevného odkazu. Symbolický odkaz přestává fungovat v momentě, kdy hlavní soubor smažete. Pevnému odkazu toto nevadí, ale pokud přepíšete jednu kopii, přepíšete s ním i tu druhou. To někdy může být žádoucí, co když však chcete mít obě kopie zcela nezávislé, ale přesto fyzicky jen jednou? Řešením je právě reflink – jedná se o kopii souboru, která s originálem sdílí stejné bloky na disku. V okamžiku, kdy část souboru přepíšete, se daný blok zkopíruje a od té doby existuje pro každý soubor zvlášť. Nemůže se tedy stát, že narušením jednoho souboru by se přepsal druhý. Jeden soubor je tak v podstatě snapshotem druhého – leží na stejném místě, ale funguje copy-on-write přístup při přepsání.

V praxi je reflink snadno dostupný – stačí dát programu cp parametr –reflink. Vytvoření kopie je samozřejmě velice rychlé. Ukážu to na příkladu:

$ ls -il
celkem 2756828
2830107 -rw-r--r-- 1 ales ales 2822984704 28. úno 22.34 velky_soubor.dat
$ df .
Souborový systém      1K bloků   Použité     Volné Uži% Připojeno do
/dev/sda5            302304256 135745632 163509912  46% /
$ time cp --reflink velky_soubor.dat prepisovatelna_kopie.dat
real    0m0.693s
user    0m0.000s
sys 0m0.050s
$ ls -il
celkem 5513648
2830083 -rw-r--r-- 1 ales ales 2822984704 28. úno 22.37 prepisovatelna_kopie.dat
2830107 -rw-r--r-- 1 ales ales 2822984704 28. úno 22.34 velky_soubor.dat
$ df .
Souborový systém      1K bloků   Použité     Volné Uži% Připojeno do
/dev/sda5            302304256 135746152 163509912  46% /

Ačkoli se jednalo o téměř 3gigový soubor, kopie byla vytvořená prakticky ihned a také se nijak nezměnilo zaplnění disku (resp. nijak výrazně, ukazatel není přesný). Také si všimněte, že oba soubory mají jiný i-node; to je správně, sdílí jen konkrétní bloky (zpočátku všechny), ne však i-node jako takový. Tento konkrétní reflink trvalo vytvořit přes půl sekundy, vytvoření dalších kopií je ještě mnohem rychlejší (metadata bloků už jsou v cache).

Pro kompatibilitu s ostatními souborovými systémy doporučuji používat cp –reflink=auto; pokud daný FS reflink umí, použije se ten, pokud neumí, vytvoří se standardní kopie. Osobně jsem si tento parametr dal jako alias k cp.

Mimochodem, v plánu je zajímavý koncept, kdy se shodné bloky budou samy vyhledávat i bez explicitního určení reflinku, a to i v rámci různých souborů.

Transparentní komprese

Transparentní komprese je věc, která linuxovým FS dlouho chyběla – někdo to řešil přes FUSE, někdo na aplikační vrstvě, ale fakt je ten, že to nikdy nebylo široce použitelné. Btrfs kompresi umí; konkrétně se jedná o zlib, od jádra 2.6.38 je pak na výběr i kompresně horší, ale rychlejší LZO. Komprese se určuje při mountování oddílu (-o compress). FS se v tomto snaží být trochu chytrý, pokud si myslí, že soubor je nezabalitelný (na základě části dat – třeba filmy nebo šifrovaná data), zbytek souboru už se komprimovat ani nepokouší. Tuto vlastnost však lze i vypnout (-o compress-force).

Účinnost komprese se při typickém použití poměrně špatně měří (kvůli snapshotům, tail packagingu apod.). Na disku s čistým systémem mi však df ukazoval cca 60procentní zaplněnost oproti du. Pokud chcete zapnout kompresi už při instalaci systému, ale instalátor to neumožňuje, doporučuji se ihned po začátku běhu instalace přepnout do konzole a tam cílový oddíl remountnout se správnými parametry.

Btrfs zatím neumožňuje u souboru zobrazit, na kolik bajtů je soubor skutečně zabalen. Také neumožňuje selektivní kompresi třeba jen pro konkrétní adresář; komprese se určuje při mountu a ne jinak. Naštěstí díky chytré detekci zabalitelnosti tohle není věc, která by byla až tak podstatná, každopádně je v plánu.

Nevýhody

Při používání jsem samozřejmě narazil na nějaké nevýhody. První byla ta, že se mi systém zdá subjektivně pomalejší; ne při sekvenčním zápisu dat, ale spíše kombinaci diskových operací. Například instalace balíčků je dokonce několikrát pomalejší než na totožném stroji a systému s ext4. Nedělal jsem však žádné větší testy a nevím, čím je to způsobené (kompresí asi ne – CPU skoro nic nedělá). Je také možné, že je to jen specifický stav; v různých testech dostupných na internetu je Btrfs srovnatelný s ostatními FS.

Další nevýhody plynou z mladosti systému – například zatím nemá samostatné fsck. Sice díky copy-on-write přístupu by nemělo docházet k chybám, ale… věřte tomu, zvlášť když je systém v tak bouřlivém vývoji. Každopádně vždy doporučuji používat aktuální verzi jádra.

Závěr

Zdaleka jsem nevyjmenoval vše, co Btrfs umí. Má například vestavěný RAID, a… podívejte se sami. Každopádně vývoj Btrfs je velice živý (v každé nové verzi jádra je ohledně Btrfs dost novinek), a když se navíc kouknu na chystané vlastnosti, máme se opravdu na co těšit. Každopádně i teď je Btrfs pro neprodukční použití velice dobrá volba, je to rodící se perla na poli FS. Pokud se o souborové systémy alespoň trochu zajímáte, vřele doporučuji.