Btrfs

Btrfs je linuxový copy-on-write souborový systém (COW), vyvíjený od r. 2007 firmou Oracle pod GNU GPL licencí.

Copy-on-write (COW) znamená, že pokud dvě aplikace pracují se stejným datovým blokem, tak se kopie s pozměněnými daty neuloží hned, ale až ve chvíli kdy se data mají zapsat. Dokud jsou nezměněná, pracují obě aplikace se stejným datovým blokem.

Při ukládání datových bloků se využívá transakcí a průběžných kontrolních součtů. Pro optimalizaci IO operací se při ukládání využívá tzv. algoritmu B-stromu.

Stručný přehled vývoje Btrfs v datech

• verze 0.13 - již měla podporu pro subvolume a snapshoty
• verze 0.14 (Duben 2008) - přidala podporu pro použití více zařízení, což umožnilo implementaci raid0, raid1 a raid10
• verze 0.15 (Květen 2008) - podpora pro zmenšování a zvětšování
• verze 0.16 (Srpen 2008) - podpora pro ACL, změna formátu indexování
• verze 0.17 součást jádra 2.6.29-rc1 (Leden 2009) - změněn diskový formát, zavedena komprese
• verze 0.18 součást jádra 2.6.29-rc2 - opravovala bug verze 0.17, který se vyskytoval při mixování 32 a 64 bitových aplikací
• verze 0.19 (Červen 2009) součást jádra 2.6.31-rc1 - zrychlení FS
• 2.6.32 (Prosinec 2009) od verze tohoto jádra nemá Btrfs vlastní verzování, mazání snapshotů a subvolumes a parametr discard pro SSD
• 2.6.34 (Květen 2010) - zavedení nástroje btrfs
• 2.6.37 (Leden 2011) - asynchronní snapshoty a mazání subvolumes
• 2.6.38 (Březen 2011) - podpora LZO komprese
• 2.6.39 (Květen 2011) komprese per soubor a podpora pro TRIM u SSD disků
• 3.0 (Červen 2011) - scrub souborového systému, autodefragmentace
• 3.2 (Leden 2012) - volba recovery, mount subvolumes přes cestu
• 3.3 (Březen 2012) - podpora pro změnu raid profilů za běhu
• 3.4 (Květen 2012) - Povolena větší velikost metabloku, zachycení IO chyb a zrychlení při práci s metadaty
• 3.5 (Červen 2012) - podpora pro statistiky, podpora NFS
• 3.6 (Září 2012) - qgroups kvóty nastavitelné na subvolume, podpora změn mezi snapshoty, vypnutí volby atime u snapshotů připojených v read-only režimu, podpora klonování souboru napříč subvolume (reflink), mount s vypnutou kompresí (compress=no)
• 3.7 (Prosinec 2012) - odstraněno omezení na počet hardlinků v jednom adresáři, podpora děravých souborů, použití NOCOW na soubor
• 3.8 (Únor 2013) - vylepšení mechanismu výměny HW zařízení za běhu, opravy chyb a dílčí úpravy pro zrychlení souborového systému.
• 3.9 (Duben 2013) - přidaná podpora pro Raid 5/6, přerušitelná operace defrag, změna volání ioctls přes které se zjišťuje či nastavuje návěští souborového systému, zrychlení IO přístupu, defragmentace snapshotovaných dat
• 3.10 (Červen 2013) - redukce metadat díky využití tzv. oholených extentů (skinny extents), ukecanější výstup do syslogu, automatické vytvoření qgroups při aktivaci kvót, rozšířený formát pro send/recv, který umožňuje zpracovávat souběžně několik zdrojů dat v jednom proudu (multiplexing) a odstraněna mountovací volba subvolrootid

Vytvoření Btrfs souborového systému

Naformátování blokové zařízení (v příkladu /dev/mapper/data-sklad ) na souborový systém Btrfs je triviální operací:

stroj:~# mkfs.btrfs -L box /dev/mapper/data-sklad ...

Informace, které se při vytvoření souborového systému vypíšou na konzoli, i další výpisy, které jsou uvedeny v následujících příkladech se mohu lišit podle použité verze btrfs-tools!

Btrfs multidevice

Btrfs je moderní souborový systém, u kterého se data ukládají do tzv. extentů, podobně jako u zařízení typu RAID, nebo LVM. Protože umí udržovat informaci také o tom, na kterém blokovém zařízení je datový blok uložen, může stejně jako ony pracovat s více než jedním blokovým zařízením. Navíc má však tu výhodu, že coby souborový systém má k dispozici také informaci o tom, jestli extent obsahuje pouze datové smetí nebo validní data.

Na rozdíl od nich však jsou extenty u Btrfs různého typu.

• systémové extenty obsahují informace o souborovém systému a příslušných blokových zařízeních
• 'metadatové extenty obsahují informace o tom kde jsou uložena vlastní data
• datové extenty obsahují vlastní data

Robustnost Btrfs spočívá v tom, že i když se pracuje s jedním blokovým zařízením jsou automaticky duplikované systémové a metadatové extenty. Extenty s vlastními daty však duplikovány nejsou. Jsou v módu single.

Datové bloky v sinle módu

Je-li tímto blokovým zařízením přímo fyzický disk, se sice díky duplikaci metadat výrazně sníží pravděpodobnost ztráty informace o uložených datech, ale poškodí-li se blok s vlastními daty, skončí pokus o jejich čtení chybou. U fyzického zařízení v takovém případě už moc šancí pro jejich záchranu není, ale pokud je blokovým zařízením pole schopné poškozený datový blok rekonstruovat ze svých metadat, pak ke ztrátě dat dojít nemusí.

Kontrola volného místa

Při použití btrfs příkazy df nebo du nám vůbec nemusí zobrazovat validní hodnoty ze které bychom si mohli udělat představu, kolik volného místa nám zbývá. Proto je vždy lepší použít ke kontrole volného místa přímo administrační utilitu btrfs.

Rozdíl je pěkně vidět na následujícím ukázkovém výpisu. Ačkoliv příkaz df uvádí volných 200GB, je ve skutečnosti volných 340GB.

stroj:~# df -h /mnt Souborový systém Velikost Užito Volno Uži% Připojeno do /dev/mapper/data-sklad 3,7T 3,4T 200G 95% /mnt stroj:~# btrfs fi show Label: 'box' uuid: 8c25587e-6680-4669-b04a-b34725068564 Total devices 1 FS bytes used 3.30TB devid 1 size 3.64TB used 3.64TB path /dev/dm-0 Btrfs Btrfs v0.19

Tato informace neřekne nic o tom, kolik místa zabírají extenty s metadaty, ani kolik místa je zabrané extenty, které jsou vázané na snapshoty. Rovněž aplikací příkazu du bychom se nedobrali k serióznímu výsledku, neboť by počítal vždy plnou velikost souboru u každého snapshotu nikoliv objem rozdílových dat.

Jediný způsob jak získat přehled o skutečném obsazení disku je tedy dotaz přímo na připojený souborový systém. Ten prozradí i kolik místa zabírají samotná data a kolik metadata

spike:~# btrfs fi df /mnt Data: total=3.49TB, used=3.31TB System, DUP: total=8.00MB, used=428.00KB System: total=4.00MB, used=0.00 Metadata, DUP: total=74.75GB, used=5.00GB Metadata: total=8.00MB, used=0.00

Komprese

Používat kompresi lze u Btrfs od jádra verze 2.6.38

Aktivuje se použitím volby compress při mountu. Btrfs pak průběžně před zápisem na disk extenty komprimuje a ověřuje kompresní poměr. Není-li výhodný, tak zapíše data bez komprese.

Data se komprimují automaticky na pozadí, ovšem pouze pokud stíhá CPU!.

Komprimovaná data zabírají fyzicky méně místa. Proto je komprese na úrovni souborového systému výhodná kupř. tam, kde se ukládají především textová data.

Naopak svou režií zbytečně zatěžuje CPU tam, kde se ukládají multimediální soubory, či data pakovaná do malých komprimovaných archívů (typicky např. rozdílové objekty u gitu!).

Komprimace se provádí před uložením extentu z vyrovnávací paměti (cache) na disk. Nelze ji tudíž používat, je-li diskový oddíl s Btrfs namountován v režimu COW, kdy se ukládají pouze rozdílová data, nebo direct IO, při kterém se nepoužívá vyrovnávací paměť a data zapisuje rovnou na disk.

root@stroj:~# mount -t btrfs /dev/data/btrfs /mnt -o compress root@stroj:~# mount | grep btrfs /dev/mapper/data-btrfs on /mnt type btrfs (rw,relatime,compress=zlib,space_cache)

Výchozí kompresní algoritmus, který se použije není-li určeno jinak je ZLIB. Ten sice dosahuje oproti alternativnímu LZO lepšího kompresního poměru, je však pomalejší a víc zatěžuje procesor.

Algoritmus LZO, který je navržen pro kompresi v reálném čase, zatěžuje procesor mnohem méně, ovšem jeho výsledky mají horší kompresní poměr a tak jsou data zapisována ve větší míře bez komprese.

root@stroj:~# mount -t btrfs /dev/data/btrfs /mnt -o compress=lzo root@stroj:~# mount | grep btrfs /dev/mapper/data-btrfs on /mnt type btrfs (rw,relatime,compress=lzo,space_cache)

Rozhodovací mechanismus Btrfs, který určuje zda-li se mají uložit data s kompresí či bez, lze ovlivnit použitím volby compress-force. Tím se natvrdo upřednostní komprimovaná data, bez ohledu na to, zda-li je kompresní poměr výhodný či nikoliv.

root@stroj:~# mount -t btrfs /dev/data/btrfs /mnt -o compress-force=zlib root@stroj:~# mount | grep btrfs /dev/mapper/data-btrfs on /mnt type btrfs (rw,relatime,compress-force=zlib,space_cache)

Špatný kompresní poměr může vznikat mimo jiné když CPU nestíhá data komprimovat v reálném čase. Btrfs v takovém případě začne data ukládat bez komprese.

Jakým způsobem Btrfs aplikuje kompresi?

Jak už padla zmínka, Btrfs neaplikuje kompresi přímo na uložené soubory, ale na jednotlivé extenty souborového systému. V rámci jednoho svazku se tak mohou vyskytovat jak extenty nekomprimované, tak extenty komprimované přes ZLIB, či LZO.

Komprese (a to platí i pro zvolený algoritmus), se aplikuje po namountování až na nově zapsané extenty. Extenty, které byly uloženy dříve, zůstávají beze změny.

Dodatečná komprimace extentů

Dodatečně lze extenty komprimovat (i dekomprimovat) během defragmentace. Pouze je třeba si uvědomit, že Btrfs nepracuje se stromovou strukturou, ale s objekty. Mají-li se tedy komprimovat objekty (soubory a podadresáře) rekurzivně, je třeba příkaz k defragmentaci aplikovat na každý objekt zvlášť pomocí utility find.

root@stroj:~# find /mnt -exec btrfs filesystem defrag -czlib '{}' \; root@stroj:~# btrfs filesystem df /mnt System: total=4.00MB, used=4.00KB Data+Metadata: total=996.00MB, used=183.27MB root@stroj:~# sync root@stroj:~# btrfs filesystem df /mnt System: total=4.00MB, used=4.00KB Data+Metadata: total=996.00MB, used=165.39MB

Lze zjistit aktuální kompresní poměr?

Bohužel v současné době nelze zjišťovat, s jakým kompresním poměrem jsou data uložená, neboť do nástroje btrfs prozatím není integrován patch, který umožňuje zjistit kolik fyzického místa na disku zabírají komprimovaná data uloženého souboru.

Více k tématu viz odkazy

Subvolume

Btrfs je souborový systém, který však má některé aspekty LVM. Mimo jiné umožňuje vytvářet tzv. subvolume a jejich snapshoty, které z hlediska souborového systému sice vypadají jako adresáře, ale fungují jako logické diskové oddíly a jejich snapshoty.

• Subvolume lze namountovat na jiný přípojný bod, stejně jako logický diskový oddíl.
• Na subvolume lze aplikovat nastavení kvót.
• Z aktuálního obsahu subvolume lze vytvářet snapshoty, stejně jako v LVM, které lze namountovat, i exportovat a zpětně importovat do jiného subvolume stejného, ale i jiného Btrfs souborového systému.

Z hlediska Btrfs je snapshot subvolume, které spravuje pouze rozdílová data jimiž se snapshot od původního subvolume liší. Pokud je původní subvolume odstraněno, zahodí jen data, která s nimiž snapshot už nemá nic společného a ta zbylá se do něj zaintegrují. Ze snapshotu se tím stane regulérní subvolume.

Vytvoření subvolume

Vytvoření subvolume se provádí pomocí utility btrfs s parametrem subvolume a příkazem create, kterému se přidá cesta do přípojného bodu, kam máme připojen svazek s Btrfs, doplněná o jeho unikátní název, který nesmí být v kolizi s jiným existujícím souborem na přílušné úrovni. Bez ohledu na to, bylo-li by to jiné subvolume, snapshot, soubor či adresář.

stroj:~# btrfs subvolume create /mnt/Subvolume\ B Create subvolume '/mnt/Subvolume B'

Na ilustračním obrázku adresářové Btrfs struktury vpravo, jsou subvolume podbarveny červeně. Ačkoliv z pohledu souborového systému nově vytvořené subvolume s názvem "Subvolume B" vypadá jako prázdný adresář, skončí pokus o jeho odstranění příkazem rmdir chybou

stroj:~# ls -al /mnt/Subvolume\ B celkem 4 drwxr-xr-x 1 root root 0 srp 12 15:10 . drwxr-xr-x 1 root root 282 srp 12 12:42 .. stroj:~# rmdir /mnt/Subvolume\ B rmdir: odstranění „/mnt/Subvolume B“ selhalo: Operace není povolena

Pro nedestruktivní zjištění zda-li jde o adresář nebo subvolume či snapshot lze použít utilitu btrfs s parametrem subvolume a příkaz show

stroj:~# btrfs subvolume show /mnt/Subvolume\ B /mnt/Subvolume B Name: Subvolume B uuid: eb730a78-2ec5-d045-9526-2ad6bd10ef46 Parent uuid: - Creation time: 2013-08-12 15:10:41 Object ID: 3514 Generation (Gen): 679887 Gen at creation: 679887 Parent: 5 Top Level: 5 Flags: - Snapshot(s):

Pokud by nešlo o subvolume či snapshot, skončil by příkaz chybou

stroj:~# btrfs subvolume show /mnt/Directory\ A ERROR: '/mnt/Directory A' is not a subvolume

Vytvoření snapshotu

Snapshoty jsou na ilustračním obrázku adresářové Btrfs struktury vpravo podbarveny zeleně. Lze si je představit jako snímek určitého stavu subvolume, se kterým lze dále pracovat, nemá-li příznak "readonly".

stroj:~# btrfs subvolume snapshot -r /mnt/Subvolume\ B /mnt/Snapshot\ B Create a readonly snapshot of '/mnt/Subvolume B' in '/mnt/Snapshot B'

Výchozím zdrojem snapshotu nemusí být pouze subvolume, ale může jím být klidně jiný snapshot, nebo subvolume, které je součástí jiného snapshotu, jako kupř. subvolume "Subvolume d", které je součástí snapshotu s názvem "Snapshot B". Pokud bychom si vytvořili rozdílový soubor mezi "Subvolume d first" a "Subvolume d second", pak bychom zjistili, která data přibyla v "Subvolume d" od doby vytvoření snapshotu "Snapshot B" (který nelze modifikovat, jelikož má příznak readonly) do okamžiku vytvoření snapshotu "Snapshot d second".

Připojení subvolume ( snapshotu )

Pokud chceme namountovat pouze subvolume, nebo jeho snapshot, tak se přidá jako doplňková volba jeho relativní cesta coby parametr atributu subvol

stroj:~# mount /dev/mapper/btrfs-volume /mnt -o subvol="/Subvolume B"

Zrušení snapshotu či subvolume

stroj:~# btrfs subvolume delete /mnt/Subvolume\ B Delete subvolume '/mnt/Subvolume B'

Při zrušení se odstraní pouze extenty, které nejsou použity nikde jinde. To je třeba brát v úvahu, pokud chceme uvolnit místo na disku. Extenty, které patřily do subvolume "Subvolume d", by se nyní staly součástí snapshotu "Snapshot d first" a zůstanou i nadále na disku.

Od verze 3.9 má btrfs podporu pro defragmentaci extentů, které patří ke snapshotům.

Kvóty

Defragmentace

Defragmentace je proces, kdy se data jednoho souboru, rozdělená na více objektů rozházených po celém disku scelí do jednoho nového objektu.

Btrfs pracuje s on-line defragmentací. To znamená, že lze objekty defragmentovat za normálního provozu. Defragmentace se totiž v btrfs provádí de fakto automaticky, při každém kopírování či přesouvání souboru, neboť cílový objekt se vytváří z těch stávajících jako zbrusu nový, scelením objektů původních. Díky tomu jsou takové operace v btrfs bezpečnější než u jiných FS, protože původní objekty se odstraňují až poté co úspěšně vytvořen objekt nový.

I tak se ale může stát, že se vyskytnou defragmentované soubory. Obzvláště tehdy, je-li disk poměrně plný, protože k jednou vytvořeným objektům se už btrfs automaticky nevrací. Proto lze objekty deframentovat i dodatečně.

Každá položka souborového systému je samostatný objekt. Defragmentace adresáře v případě btrfs se tedy v žádném případě neaplikuje rekurzivně na objekty, které jsou jinak jeho součástí. Defragmentují se pouze metadata, která se týkají objektu který je defragmentován (adresář).

Rekurzivní defragmentaci lze provést s využitím utility find

Přitom je třeba mít na vědomí, že při defragmentaci objektu, pro který v rámci btrfs existuje nějaká přírůstková kopie (COW) - typicky objekt, který je součástí snapshotu, dojde k jejich vzájemnému oddělení a vytvoření vzájemně nezávislých objektů. Tzn. že si data ukousnou další místo na disku!

Vyvážení - balance

Vyvažování (balance) je operace, která prostě vezme všechna data a metadata a přepíše je na jiné místo disku, s tím že je propasíruje přes alokační mechanismus. Tj. mechanismus, který rozhoduje kam se má co uložit.

Toto vyvažování bylo původně navrženo pro použití u btrfs rozloženého přes fvíce fyzických zařízení - odtud také název této funkcionality. Ale dá se využít i tehdy, pokud se přidá další zařízení, když hrozí zaplácnutí disku.

Tato operace má i další postranní efekty, které lze s výhodou využít: - Je-li na zařízení alokováno hodně bloků dat, které jsou jinak poměrně nevyužité, lze jejich zpřeházením scelit místo, neboť během vyvažování dojde k efektivnějšímu uložení dat a metadat. - Na souborovém systému, kde došlo k chybě při replikaci (např. u RAID-1 kde umřel disk) to donutí obnovit ztracenou kopii z metadat na aktuálně aktivním zařízení.

Co je důležité vědět

Vyvažování nijak nepracuje s tzv. B-stromy, takže nemá žádný vliv na zrychlení přístupu k souborovému systému.

Export/Import Btrfs subvolume

Vlastnosti Btrfs z principu vylučují, aby bylo možné zkopírovat obsah subvolume, včetně případných snapshotů prostým příkazem cp, aniž by došlo k duplikaci dat. Pro takové případy, kdy chceme vytvořit kopii (nebo zálohu) subvolume, má utilita btrfs příkazy send, kterým se provede export do proudu dat a receive, kterým se ze vstupního proudu dat vytvoří kopie subvolume na jiném místě či stroji.

Ilustrační schéma popisuje situaci, kdy se exportuje snapshot "Readonly snapshot c" ze stroje "stroj-A" na "stroj-B".

• Nejprve se vytvoří na stroji stroj-A "readonly" snapshot subvolume "Subvolume c"

Btrfs je stále ve vývoji, proto lze vyexportovat pouze snapshot subvolume, který je ve stavu "readonly". Nikoliv subvolume jako takové, nebo některý z jeho podadresářů.

• Na stroji stroj-B se připraví subvolume "Subvolume B", do kterého se bude importovat exportovaný stream
• Pak se ze stroje stroj-A snapshot "Readonly snapshot c" odešle na stroj-B kde v "Subvolume B" vytvoří jeho kopiie

stroj:~# btrfs send -v /mnt/Readonly\ snapshot\ c | ssh root@stroj-B 'btrfs receive /mnt/Subvolume\ B'

send

V exportovaném proudu dat, který se posílá na standardní výstup a který se může prohnat rourou nebo také přesměrovat do souboru, jsou obsaženy veškeré data, které patřily k "Subvolume B" v okamžiku, kdy byl vytvořen "Readonly snapshot c"

receive

Po naimportování vznikne z přijatý dat snapshot, který je opět ve stavu "readonly". Ale pokud se vůči němu vytvoří zapisovatelný snapshot a původní naimportovaný "Snapshot subvolume c" je zrušen, tak se "Readwrite subvolume C from snapshot" změní na normální subvolume s nímž lze dále pracovat.

Obnova btrfs

Pro obnovu btrfs existuje utilita btrfs-restore, která umožňuje nedestruktivním způsobem obnovit data ze souborového systému, který nejde namontovat.

Odkazy

https://btrfs.wiki.kernel.org/index.php/Problem_FAQ Oficiální FAQ

https://wiki.archlinux.org/index.php/Installing_on_Btrfs_root Btrfs jako kořenosý souborový systém

https://wiki.archlinux.org/index.php/Maximizing_Performance Maximalizace výkonu u Btrfs

http://www.ckernel.org/news/uploadfile/2012/ppt/04.pdf Příspěvek z China Linux Kernel Developer Conference 2012 o defragmentaci Btrfs snapshotů