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

[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ů).