Btrfs, lepší systém souborů – praxe

21. 12. 2011 | Tomáš Crhonek | Systém | 17488×

Btrfs je souborový systém nové generace, u jehož zrodu stojí především společnost Oracle. Je to takové ZFS pro Linux, ačkoliv se od sebe tyto souborové systémy dosti odlišují. Po předchozím teoretickém dílu si tentokrát používání Btrfs ukážeme prakticky.

Obsah

• Vytvoření systému souborů nad několika pevnými disky
• Přidání dalšího diskového zařízení
• Odebrání diskového zařízení
• Náhrada vadného disku
• Zjištění volného místa na systému souborů
• Vytvoření a připojení pododdílu
• Rušení pododdílů
• Snímky pododdílů
• Praktické ukázky
  • Domácí adresáře jako pododdíly
  • Inkrementální zálohování pomocí snímků a rsync
  • Práce s velkými adresáři

Btrfs prakticky

Vytvoření systému souborů nad několika pevnými disky

V současném stavu vývoje Btrfs je možné vytvořit systém souborů nad několika disky (obecně jakýmkoliv blokovým zařízením) a to v režimech single, raid0, raid1 a raid10. V režimech single a raid0 je minimální počet diskových zařízení jeden, v raid1 dva a v raid10 potom 4. Lze použít disková zařízení různých velikostí, což je další posun oproti systémům raid. Režimy single a raid0 lze použít například pro souborový systém nad hardwarovým či softwarovým raidem, kde je již o ochranu dat postaráno.

Vytvoření systému souborů nad dvěma disky v režimu raid1:

# mkfs.btrfs -d raid1 -m raid1 /dev/vdb /dev/vdc

WARNING! - Btrfs Btrfs v0.19 IS EXPERIMENTAL
WARNING! - see http://btrfs.wiki.kernel.org before using

adding device /dev/vdc id 2 
fs created label (null) on /dev/vdb 
        nodesize 4096 leafsize 4096 sectorsize 4096 size 2.00TB 
Btrfs Btrfs v0.19 

V distribucích, které nemají dobrou podporu Btrfs je před samotným připojením nutné vykonat příkaz

# btrfs device scan

který vyhledá všechny Btrfs souborové systémy.

Takto vytvořený systém souborů lze potom připojit pomocí příkazu:

# mount /dev/vdb /mnt

kde jako připojované zařízení lze uvést libovolné diskové zařízení, na kterém je systém souborů vytvořen, nebo jeho UUID. Případně (pokud, například při startu systému bez initrd, není možné spustit příkaz btrfs device scan, je možné vyjmenovat všechna disková zařízení pro daný systém souborů):

# mount /dev/vdb /mnt -o device=/dev/vdb,device=/dev/vdc

Řádek do /etc/fstab potom bude vypadat následovně:

# /dev/vdb /mnt btrfs device=/dev/vdb,device=/dev/vdc 0 0

Pro zjištění informací o systémech souborů btrfs na celém serveru slouží příkaz

# btrfs filesystem show
Label: none  uuid: b851caba-dccd-4801-9db9-8f1477170063
        Total devices 2 FS bytes used 28.00KB
        devid    1 size 1.00TB used 2.03GB path /dev/vdb
        devid    2 size 1.00TB used 2.01GB path /dev/vdc 

Zde je tedy systém souborů jeden a nad diskovými zařízeními /dev/vdb a vdc.

Vytvoření souborového systému Btrfs je jediná operace, která se (už ze své podstaty) vykonává při odpojeném systému souborů. Všechny další operace se provádějí online, při připojeném Btrfs.

Přidání dalšího diskového zařízení

Další diskové zařízení lze přidat pouze k připojenému souborovému systému a sestává se ze dvou kroků. Příkazem btrfs device add <zařízení> <přípojný bod> se přidá další zařízení do souborového systému:

# btrfs device add /dev/vdd /mnt 

Po té je vhodné (nikoliv nutné) příkazem btrfs filesystem balance <přípojný bod> přeuspořádat data na všech zařízeních pro rovnoměrné rozložení dat.

# btrfs filesystem balance /mnt

Odebrání diskového zařízení

Odebrání diskového zařízení se opět provádí nad připojeným souborovým systémem a má svá omezení. V souborovém systému musí být alespoň tolik volného místa, jaká je velikost odebíraného zařízení. Dále zařízení není možné odebrat, pokud by se snížil počet zbývajících zařízení pod minimum, které je dané použitým režimem (raid1 dvě a raid10 čtyři disková zařízení). Pro odebrání slouží příkaz btrfs device delete <zařízení> <přípojný bod>

# btrfs device delete /dev/vdd /mnt

Odebrání, na rozdíl od přidání, trvá delší čas, jelikož je nutné datové bloky přesunout na jiné disky.

Náhrada vadného disku

Tato operace se opět a zde poněkud překvapivě vykonává nad připojeným systémem souborů. Někdy může být nutné připojit souborový systém v degradovaném režimu, pomocí volby „degraded“:

mount -t btrfs -o degraded /dev/vdb /mnt

To v případě, že je počet zařízení nižší, než je nutný počet. Například, pokud systém souborů vytvořený s parametry mkfs.btrfs -d raid0 -m raid1 /dev/vdb /dev/vdc, tedy zrcadlení pouze metadat, přijde o jeden z disků, tak jsou data sice „v háji“, ale stále lze získat alespoň názvy souborů (metadata) a výpis adresářové struktury.

Potom lze vadné zařízení odebrat příkazem:

# btrfs device delete missing /mnt

Poznámka: Stejně jako u odebírání „zdravých“ disků v předchozím bodě i zde je nutné, opět poněkud překvapivě, dodržet minimální počet zařízení. Tedy, před odebrání „missing“ disku z raid1 je nejprve nutné připojit další diskové zařízení a až poté odebrat vadný disk. Lze předpokládat, že toto chování bude předmětem dalších změn.

Zjištění volného místa na systému souborů

Operační systém postavený na Linuxu poskytuje dva základní nástroje pro zjištění volného a obsazeného místa na systému souborů. Jsou to příkazy du (disk utilization) a df (disk free). Oba tyto nástroje v současné době poskytují nesprávné informace o zabraném a volné místu na systému souborů Btrfs.

df v současné době jednak nerespektuje metadata a případnou kompresi bloků, ale zejména způsob uložení datových bloků (raid1, raid10). Například na používaném souborovém systému vytvořeném jako raid1 nad dvěma 1TB disky ukazuje df:

# df -h /home
Filesystem            Size  Used Avail Use% Mounted on 
/dev/sda3             1.9T  407G  1.5T  22% /home 

22% zabraného místa, přičemž reálně je zabraných přibližně 44% zrcadlených bloků.

du při zjišťování zabraného místa na disku nerespektuje referenční (cow) kopie souborů, ani snímky pododdílů. Zjištěné zabrané místo na celém systému souborů tak snadno může mnohokrát překročit jeho velikost. Příklad je opět ze 1TB souborového systému nad dvěma disky v raid1.

# du -sh /home
4.7T    /home

Takto výrazný rozdíl mezi skutečně použitým místem (407GB) a spočteným (4.7TB) je dán užitím snímků (několik desítek) pododdílů.

Btrfs poskytuje vlastní nástroje pro zjišťování informací o zabraném místu, btrfs filesystem df <přípojný bod>:

# btrfs filesystem df /home 
Metadata, RAID1: total=7.62GB, used=1.12GB 
Data, RAID1: total=914.62GB, used=404.94GB 
System, RAID1: total=8.00MB, used=144.00KB 
System: total=4.00MB, used=0.00 

Na tomto systému je tedy zabráno celkem (data + metadata + režijní data) 405GB, 510GB je tedy volných (srovnejte si tyto údaje s výpisy du a df). Výpis btrfs filesystem df zatím neobsahuje jednoduchý údaj o celkovém dostupném a celkovém zabraném místu, je tedy nutno počítat.

Co se týče zjištění zabraného místa snímky pododdílů, zde je situace ještě složitější. V současné době neexistuje a ani se neplánuje jednoduchý nástroj, který by poskytl odpověď na otázku „Kolik místa se uvolní odstraněním tohoto pododdílu?“.

Vytvoření a připojení pododdílu

Dostáváme se k operaci, kterou budeme v praxi dělat přece jen častěji. Jak již bylo řečeno, pododdíl je něco jako lepší adresář, který lze samostatně připojit jako samostatný souborový systém s nějakými parametry. Počet pododdílů je prakticky neomezený.

Pododdíl se vytvoří příkazem btrfs subvolume create <cesta>.

Pokud bychom chtěli využít například transparentní kompresi pro textová data (například emaily), lze vytvořit pododdíl a ten připojit například do /var/spool/mail. Btrfs root je v tomto případně připojen do /btrfs_spool.

# btrfs subvolume create /btrfs_spool/mail
# mount /dev/sda3 /var/lib/mail -o defaults,subvol=mail,compress

Jistě se najde spousta využití pododdílů a jejich připojování s různými parametry, nápady lze nalézt na btrfs wiki.

Rušení pododdílů

smazání. Datové bloky se uvolňují na pozadí příslušných jaderným procesem. Ovšem pozor, přestože je smazání zdánlivě okamžité, souborový systém nelze odpojit, dokud tato činnost nebude dokončena. Tato vlastnost ve většině případů nebude vadit, narazil jsem však na případ, kdy jsem po zrušení velkého pododdílu (s velkým počtem souborů) potřebovat daný server vypnout a musel jsem čekat několik minut na odpojení souborových systémů.

Rušení pododdílu:

# btrfs subvolume delete /home/adam

Snímky pododdílů

Snímek pododdílu je atomická kopie zdrojového pododdílu v daném čase. Je důležité si uvědomit, že takto vytvořená kopie je také pododdíl se vším, co k tomu patří, tedy je zapisovatelný, lze jej připojit s nějakými parametry, rušit a vytvářet další snímku.

Snímek pododdílu se vytvoří příkazem btrfs subvolume snapshot <zdroj> <cíl>.

Vytvoření snímku je levná operace (jak časově, tak díky COW i prostorově), snímky lze vytvářet v prakticky neomezeném množství.

Praktické ukázky

Btrfs používám na svém domácím (neprodukčním) serveru několik měsíců k maximální spokojenosti. Rád bych se podělil o způsoby jeho využití.

Domácí adresáře jako pododdíly

Používám Btrfs na /home a jednotlivé domácí adresáře mám vytvořené jako pododdíly:

# btrfs subvolume create /home/<username>

S tím, že se automaticky (pomocí skriptu v cronu) vytváří snímky všech těchto domácích pododdílů. Uživatelé tak mají přístup ke starším verzím svých souborů, které si mohou snadno sami obnovit. Další výhoda je v rychlém mazání příslušného domácího adresáře (což pro adresář „živého uživatele“ nenastává tak často, ale pro adresáře služeb „na vyzkoušení“ je to přece jen častější operace).

Inkrementální zálohování pomocí snímků a rsync

Přenášení dat pomocí rsync po síti je úsporné a tedy rychlé, stejně tak rychlé je i vytváření snímků. Spojením těchto dvou vlastností vzniklo zálohovací řešení stylem:

1. Přenes data pomocí rsync.
2. Vytvoř na zálohovací lokalitě snímek.

Triviální, jednoduché, ke všem souborům je otevřený přístup, na disku jsou uloženy úsporně (pouze změněné bloky) a hlavně, lze smazat libovolnou zálohu prostým smazáním daného pododdílu (což mnohé inkrementální zálohovadla neumožňují a nebo to trvá neakceptovatelně dlouho). Tomuto řešení chybí možnosti zjištění, kolik místa se uvolní smazáním daného snímku. To Btrfs neumí.

Práce s velkými adresáři

Nejednodušší a zároveň asi nejužitečnější využití snímků je při práci s velkými soubory, na které se nehodí klasické systémy správy verzí. Při práci s adresáři, které obsahují stovky gigabajtů souborů se hodí si tento pracovní adresář (pododdíl) „verzovat“ pomocí snímků a mít tak možnost se kdykoliv vrátit o krok zpět, případně zkoušet různé postupy zpracování daných souborů. V praxi jsem potřeboval upravit adresářovou strukturu se stovkami tisíci souborů (soubory samotné jsem nemodifikoval) a možnost vytvoření snímků mi poskytlo možnost porovnat více adresářových struktur vedle sebe.

       

Komentáře

[aaaaaaaaaaa]

A co deduplikacia? Uplne by mi stacila offline. Viem, ze na to boli patche, ale neviem o dalsom vyvoji.

[CET]

Deduplikace, raid5/6, stabilizovat a JDU DO TOHO !!! Sakra, to je nadhera. Ano, je to jako ZFS (co jsem taky nekde videl, slysel, cetl), ale btrfs je GPL, cili v jadre:) Vypada to fakt hezky, zvlast to zmensovani online me laka. Je to takovy vylepseny LVM, pouzivam LVM aktivne a online zvetsovani je super, jen to zmensovani je problem.

[Michal Kubeček]

Lze použít disková zařízení různých velikostí, což je další posun oproti systémům raid.

Vzhledem k tomu, že to stejně už z principu nemůže fungovat, v tom žádnou výhodu nevidím. Např. u RAID 1 buď kus nebude mirrorovaný nebo to bude "fungovat" přesně stejně jako u normálního RAID 1, tj. z větších zařízení se použije jen část.

Obecně považuji snahu reimplementovat RAID (a další funkce) na úrovni filesystému za velmi nešťastnou, raději mám řešení na úrovni blokového zařízení, které je univerzální a neomezuje mne na jediný filesystém.

[Max]

Myslím si, že manipulace s daty v rámci blokového zařízení není úplně to nejlepší. Z toho hlediska je implementace raid fcí v fs výhodná (lze pak dělat lepší prasárničky s daty, páč fs ví, kde data jsou a umí s nimi parádně manipulovat).
Taktéž správa se mi jeví jako jednodušší. Je samozřejmě jasné, že né na vše se btrfs hodí a taktéž je jasné, že raid fcí v kernelu se nikdo zbavovat nebude a taktéž né lvm. Každá věc má své místo a určitě ještě budoucnost.
Zdar Max

[Heron]

Obecně považuji snahu reimplementovat RAID (a další funkce) na úrovni filesystému za velmi nešťastnou, raději mám řešení na úrovni blokového zařízení, které je univerzální a neomezuje mne na jediný filesystém.

Implementace raid ve FS má své výhody. Například při výměně diskového zařízení není třeba kopírovat všechny bloky, ale jen ty skutečně zabrané. Což je mnohem rychlejší. Tuhle informaci raid na samostatné vrstvě nemá. Dále je možné kdykoliv odebrat jakékoliv zařízení. To už souvisí s tvou první poznámkou:

Vzhledem k tomu, že to stejně už z principu nemůže fungovat, v tom žádnou výhodu nevidím. Např. u RAID 1 buď kus nebude mirrorovaný nebo to bude "fungovat" přesně stejně jako u normálního RAID 1, tj. z větších zařízení se použije jen část.

Toto by platilo u dvou disků. Když tam ale budeš mít mnoho diskových zařízení, tak se FS zkrátka postará o uložení zrcadlených bloků na dvě různá zařízení, nikoliv na dvě konkrétní (předem dané). Tedy ani rozdílná velikost příliš nevadí.

[trekker.dk]

Například při výměně diskového zařízení není třeba kopírovat všechny bloky, ale jen ty skutečně zabrané. Tuhle informaci raid na samostatné vrstvě nemá.

Zatím. Pro softwarový RAID v Linuxu je to v plánu.

[čavo]

Obecně považuji snahu reimplementovat RAID (a další funkce) na úrovni filesystému za velmi nešťastnou, raději mám řešení na úrovni blokového zařízení, které je univerzální a neomezuje mne na jediný filesystém.

Implementace raid ve FS má své výhody. Například při výměně diskového zařízení není třeba kopírovat všechny bloky, ale jen ty skutečně zabrané. Což je mnohem rychlejší. Tuhle informaci raid na samostatné vrstvě nemá. Dále je možné kdykoliv odebrat jakékoliv zařízení. To už souvisí s tvou první poznámkou:

Nie je mi celkom jasné, prečo sa na tento účel nezačal používať TRIM, ktorý sa aj tak musel implementovať kvôli SSD diskom.

[frr]

Třeba proto, že by si RAID musel vést nějaká metadata o tom, který blok je "použitý" a který nikoli - a to s granularitou na jednotlivé bloky, které prezentuje vyšším vrstvám (tzn. dodnes obvykle 512B sektory). To by bylo docela dost dat, netriviální logika, seeky navíc, a co odolnost vůči výpadku napájení...

MD RAID umí používat "write-intent bitmap", ale ta má jiný význam: poukáže na bloky, které byly v okamžiku výpadku proudu "dirty" a které nikoli.

Troufnu si odhadnout pár dalších optimalizací RAIDu, které lze páchat ve "filesystému se zabudovaným RAIDem": je tu možnost provádět inteligentní read-ahead (číst pár bloků napřed v souboru, nikoli tupě pár bloků napřed na každém disku v RAIDu), rozlišovat při read-aheadu mezi užitečnými daty / metadaty / volným místem, a dále je tu možnost alokovat bloky do souborů sekvenčně/spojitě bez nějakého jednotného strajpování s pevným krokem.

[čavo]

Metadáta môžu byť v bloku, pre ktorý sú, nemusia byť s granularitou 512 B a ľahko sa môže použiť bitová mapa pre pár blokov zapísaná v jednom bloku (potrebuje len dva stavy obsadený, neobsadený).

Iná otázka je, či sa chce.

[alblaho]

Ano, teoreticky je hezčí, když je to hezky univerzální a ortogonální. Jenže prakticky je to na používání horší: LVM/RAID neví, které bloky jsou obsazené, takže některé operace jsou velmi neefektivní.

Jako uživatel LVM se na Btrfs velmi těším, protože mi to jednoduše umožní dělat složité věci. Navíc btrfs oddíl můžeš mít pořád nad odschoolovým RAIDem.

Mně spíš mrzí ta práce s volným místem. Je to takové uživatelsky napřítulné. Chápu, že situace je komplikovaná, nicméně df by nemuselo vracet vyložené nesmysly.

[Filip Jirsák]

LVM/RAID neví, které bloky jsou obsazené, takže některé operace jsou velmi neefektivní

To je ale přece záležitost současné implementace, nikoli principu. Většina souborových systémů používá nějaké bloky, takže tahle vrstva se dá do LVM/RAID implementace přesunout a mohou ji využívat všechny souborové systémy.

[the.max]

Kdyz uz df samo neumio zjistit volne misto a pokud nas danem pocitaci je btrfs pouzito, zrejme tam budou i potrebne utility. Pak by prece nemel byt takovy problem, ze kdyz df zjisti, ze je jako FS btrfs, tak misto toho aby se sam snazil zjistit volne misto, radeji rovnou zavolal btrfs filesystem df a jen to proste zobrazil. Stejne tak du.

[pavlix]

Jenže prakticky je to na používání horší

Líbí se mi, kolik lidí si vybere jedno jediné kritérium a use case, a na základě toho tvrdí, že je něco obecně (prakticky) lepší nebo horší.

[petr_p]

df sám nic nepočítá. Prostě zavolá statfs(2). A ten si v jádře implementuje každý souborový systém zvlášť. Takže míč je na straně btrfs.

[Mrkva]

Už to má fsck? :)

[czi]

Nemá. Na disku mi čeká několik měsíců pokažená partišna s bezcennými daty a přemýšlím jestli ji přeformátovat nebo počkat až bude nějaký nástroj na opravu.

[Honza Jaroš]

Náhrada vadného disku
Tato operace se opět a zde poněkud překvapivě vykonává nad připojeným systémem souborů. Někdy může být nutné připojit souborový systém v degradovaném režimu, pomocí volby „degraded“:

Když to tak čtu, zajímalo by mě - jak to dopadne při startu? Ve fstab běžně volba "degraded" nebývá, co když umře jeden ze systémových disků? Pokud by v takovém případě byla nutná asistence na místě, viděl bych to jako problém...

[Honza Jaroš]

Mno, takže jsem si to zkusil pod aktuálním Gentoo s jádrem 3.1.5-gentoo a initrd z genkernelu. Prvním zjištěním bylo, že výchozí initrd skripty nespouštějí btrfs device scan, takže je nutné uvést seznam zařízení v fstab. Druhým zjištěním bylo, že pokud je explicitně uveden seznam zařízení v fstab, disk se v degradovaném režimu nepřipojí s hláškou, že takové zařízení neexistuje. Nakonec jsem z fstab seznam zařízení vyhodil a před spuštěním initu zkusil ručně spustit btrfs device scan; v takovém případě se souborový systém bez protestů připojil.

Čili pokud na btrfs v RAIDu závisí start systému, je podle všeho nutné mít do initrd doplněné scanování btrfs...

[petko]

Na wiki citam o super vecicke - filesystem seeding. Ide o zapis na ine medium. (dobre podla mna na live distribucie, alebo obmedzenie opotrebovania flash diskov). Ale hned nastava otazka, ci je to take super - da sa to aj s ext4, pripadne nejakym pseudofs?
Inak na btrfs mi vadi jedna vec - je strasne pomaly s postgresql.

[Heron]

Inak na btrfs mi vadi jedna vec - je strasne pomaly s postgresql.

Doplnil bych ještě v jaké verzi Btrfs a Postgresu. Na Debianu (2.6.32 a PostgreSQL 8.4) je to brutálně pomalé, ale v benchmarku (počínaje tímto článkem) od Tomáše Vondry (2.6.39-gentoo-r3 a PostgreSQL 9.0.4) už to bylo "normálně" rychlé.

[Otto Šabart]

Velmi pekny clanek... diky

[Petr Ježek]

I já děkuji.

[loki]

Pekny clanek. Kdy tak bude tento FS zraly podle vaseho nazoru pro nasazeni na serveru? Jeho schopnosti vypadaji obstojne. Je mozne v dohledne dobe ocekavat vydani fsck nastroje?

[Heron]

Díky všem. :)

O btrfs.fsck nemám bližší informace (myslím si, že základem je zálohovat, fsck netřeba).

Co se týče nasazení na produkční server, to má ještě pár let čas. Nejdříve musí být prohlášen za stabilní potom bude následovat několik let testování a až potom půjde do enterprise dister.

Osobně jsem na domácím serveru nezaznamenal žádné problémy (tedy až na občas podivný výkon), ale také jsem ještě neřešil výměnu vadného disku (jen simulace ve virtuálce, kde to dopadlo dobře), nevím, co se stane, když dojde místo na disku apod. Bugů je stále dost.

[Michal Kubeček]

Nejdříve musí být prohlášen za stabilní potom bude následovat několik let testování a až potom půjde do enterprise dister.

Taky jsem si to myslel. Ale vypadá to že ne.

[Lukáš Zapletal]

Po dlouhé době se přihlašuji na abc, abych mohl napsat: pěkný článek.

Jinak rsync používám stejně, ale s ext4 a hardlinky. Výsledek je velmi podobný, šetří se místo a je možné "umazávat" staré zálohy, ale chápu, že tohle řešení může teoreticky ušetřit místo u velikých souborů (např. ISO a podobně), pokud se mění. Tam hardlink nepomůže a musí se uložit nová verze. Ale velké soubory se v mém případě téměř nikdy nemění

http://www.sanitarium.net/golug/rsync_backups_2010.html

[Heron]

Díky Lukáši.

JJ, na běžném FS používám prográmek rsnapshot, který funguje podobně (také inkrementální zálohování pomocí hardlinků).