Názory k článku Souborový systém Btrfs: kontrola dat a pokročilé použití

Používáte někdo aktivně snapper? Já si s těma nástavbama nad btrfs moc nerozumím - mám v texťáku pár příkazů na téma btrfs subvolume create/delete/sen­d/receive a s těma si zatím vystačím. Případně je můžu dát do scriptu (pro sebe) vyřešíno.

Respektive - co ten snapper-gui - ten už se snad ani nevyvýjí ne?

Jsem na tom podobně. Pro lidi jako my je přímočařejší si to udělat pomocí low-level nástrojů, ale jsme menšina. Většina lidí použije nějaký produkt typu snapper, nebo ještě přesněji — většina lidí ani neví, že to používá, protože je to default jejich distra a nesahají na to :-)

Áno, používam snapper, samozrejme na serveri nemám žiadne GUI.

Předně bych chtěl vyjádřit autorovi své díky za brilantní seriál o Btrfs systému. Jelikož ho začínám čerstvě používat spolu s RAID 1 polem, jsem rád, že se dozvídám mnoho důležitých informací jak z článku, tak i od diskutujících.

Nyní k mému dotazu: I zde v článku je zmíněno zálohování. Musím říct, že tenhle způsob záloh mi nedá spát a stále si nejsem jist, že to, jak to celé funguje, chápu správně. Pro mě osobně je záloha, kterou lze označit za zálohu 1:1 kopie dat. Čím více důležitých dat, tím více kopií na více úložištích a také fyzických místech. Tedy příkladně, pokud mám 2TB důležitých dat, lze jako jediné považovat za zálohu, pokud mám tyto data 1:1 na jiném 2TB disku (3 zálohy = 3x 2TB HDD). Jestli to chápu správně, snapshoty fungují tak, že dělají rozdílové "zálohy", tady musím mít něco jako zdroj a ze zdroje odečítám (zapisuji) k prvnímu snapshotu pouze rozdíl. Následný další rozdíl také, ale jenom s tím rozdílem, že již nějaká data odečítám z prvního snapshotu. Důležité ovšem je to, že musím mít někde ty 2TB dat (zdroj, který je porovnáván). Jestliže se zdroj poškodí, můžu si 10 snapshotů strčit někam. Chápu to správně? Jestliže ano, nejedná se totiž o zálohu a je velmi nesprávné a také zavádějící, to takto označovat. Je to jako tvrdit, že RAID 1 je záloha dat. Ano, data máte na dvou discích, ale bohužel, dojde např. k napadnutí stroje ransomware a data se zašifrují i na disku druhém. => proto se nejedná o zálohu. Píšu to, protože mnoho lidí to, bohužel, nechápe. Je mi jasné, že diskutující zde, ví.

Díky za pochvalu.
Ano je bude stal stejný problem jako pri priruskovych zalohach - pokid stratis full zálohu tak prustky ti jsou k nicemu.

Zaloha to je - mas to kopii od produkcnich dat a i na jinem mediu.

Ne úplně. Pokud provedeš na zálohovacím stroji Btrfs restore, tak tam budeš mít dva snapshoty, oba s full zálohama. Pokud starší snapshot smažeš, tak furt pomocí toho nového snapshotu data obnovíš. V tom je ta "genialita" snapshotů a obrovský rozdíl oproti klasickému přírůstkovému zálohování.

Ano ale samozřejmě taky s dvojnásobným datovým objemem :(
Zatímco snapshoty jsou něco jako git revize, kdy je celý systém v daném bodě dostupný, ale vnitřně to zabírá jen tu inkrementální část. Podobně jako u věcí typu syncthing.

Nikoli: pokud to send-restore uděláš jako inkrementální, tak na cílovém stroji Ti také vzniknou dva snapshoty sdílející data. Btrfs send-restore právě funguje přesně jako git: snapshoty šetří místo jak na místním, tak na "vzdáleném repozitáři".

Předně bych se nedržel premisy, že záloha == 1:1 kopie dat. Pokud tím máte na mysli to, že bude 1:1 bitová kopie, pak to zase s sebou nese riziko vznikající z chyb filesystému a jeho interpretace (v roce 2020 může mít btrfs nějakou chybu, kterou zároveň v této době umí "správně" interpretovat, ale v roce 2025 při připojení zálohy můžete narazit na projev problému). Záloha bitové kopie je jedna ze specifických typů záloh, ale určitě se nedá říct, že je to nejvhodnější vždy a všude (já bych skoro řekl, že se tato výhoda hodí málokdy).

Zálohovací systémy často umějí přírůstky intepretovat do hlavní knihovny záloh takovým způsobem, že po uložení dat už neexistuje závislost na full záloze a na předcházejících přírustcích (ale přesto umí podle katalogu najít stav ke každému inkrementu). To, jestli vím, tak ani zálohy snapshotů btrfs, ani zfs neumí (a třeba pro mě je to velké mínus).

Formou snapshotů je vhodné zálohovat často měnící se data, aby byl zachycen stejný okamžik na celém subvolume. V praxi je asi nejčastější případ formou snapshotů zálohovat (jenom) transakční logy databázových systémů, případně, pokud to situace dovoluje, tak i hlavní databázi.

Překvapilo mě doporučení na vypínání CoW pro databázová úložiště. Zrovna tam je to potřeba - stejně databáze zapisují stránky na konec transakčního logu, takže k častým přepisům dat nedochází. Ve chvíli, kdy dochází k promítnutí změněných stránek do hlavního úložiště, je CoW zapotřebí jako soli. CoW by mělo mít poměrně mrňavou režii (filesystem stejně zapisuje svoje stránky). Doporučil bych spíš vyladit interval zápisu logů do databáze, případně (po pečlivé úvaze) oslabit fsync, než vypínat CoW - to jde zcela proti smyslu architektury!

Ano, máte pravdu, použil jsem nešťastný termín. Měl jsem na mysli 1:1 ve smyslu stejná data na jiném médiu ("prachsprostě" překopírovaná a poté ověřená a zkontrolovaná). Jinak časový snímek dat je parádní věc a i vím, kde bych to používal já, ale nelíbí se mi to označení záloha, protože to mate uživatele a já jim pak dost blbě vysvětluji, že to vlastně záloha ve smyslu záloha, není. Obdoba RAID 1, jak jsem psal. O bitové záloze máte pravdu, kvůli tomu ji také nedoporučuji používat. Na vlastní kůži jsem už poznal její záludnost.

Ve chvíli, kdy dochází k promítnutí změněných stránek do hlavního úložiště, je CoW zapotřebí jako soli.

Záleží na konkrétní db, ale ty postavené na MVCC architektuře si něco jako COW dělají sami. Nikdy se nepřepisuje existující záznam, ale vždy se vytváří nový. Až zpětně jsou označeny volné záznamy nebo celé stránky.

Takže dělat MVCC nad COW znamená ty bloky na disku měnit 2x. DB zapíše změněnou stránku, FS to vidí jako změnu bloku, tak udělá ještě COW toho bloku. Potom nad DB proběhne vacuum, DB označí tu původní stránku jako volnou a FS to opět vidí jako změnu a provede COW.

Nepřináší to žádnou výhodu, takto postavená DB se sama vyrovná s výpadkem napájení apod. Živé stránky se nikdy nepřepisují a ty mrtvé jsou označeny za volné až někdy zpětně (ano, samozřejmě, existují optimalizace jako hot update apod, ale to není teď potřeba komplikovat). Tj datové soubory jsou vždy v pořádku a snadno rekonstruovatelné pomocí logů. Dělat nad tímto ještě další COW nic nepřinese a sníží výkon zápisu efektivně na polovinu (v praxi ještě více).

Ja by som teda najprv urobil poriadok v pojmoch. Zaloha nie je archiv a archiv nie je zaloha. Mali by ste mat nejaku policy pre archivaciu udajov. Napriklad jeden archiv pre kazdy rok a za poslednych 6 mesiacov kazdy mesiac a posledne 4 stvrtroky. Vzdy full archiv na 2 roznych lokaciach a 2 technologicky roznych mediach (SSD, tocity disk, cloud, paska, ...).
Zalohy sa potom mozu odrazit z tychto archivov, takze si zalohujete iba rozdiely oproti full archivom.
No a na zaver technicka poznamka, musite vediet co robite. Ked si pod beziacim Oraclom urobite snapshot a zazalohujete neznamena to ze viete neskor obnovit instanciu Oraclu.

Ještě bych také doporučil běžným desktop uživatelům příkaz btrfs check s přepínačem –force, kdy můžete provést kontrolu integrity souborového systému Btrfs na připojeném disku a nemusíte jej odpojovat skrz kontrolu.
btrfs check –force /dev/deviceX

Zajímavé srovnání by bylo, kolik % všech filesystémů na BTRFS, nakonec chcíplo.

Upřímně, mám kolem sebe několik desítek Linuxáků a snad každý, má s BTRFS tak mizerné zkušenosti, že si to netroufne nasadit ani na pracovní notebook, nedejbože někam klientovi do produkce.

BTRFS nemá oproti ZFS absolutně nic navíc, ba naopak, tunu funkcionality postrádá.
Proč používat BTRFS, když si ZFS modul může zbuildit kde kdo, na kde čem, co je 64bit?

Proč používat BTRFS, když si ZFS modul může zbuildit kde kdo, na kde čem, co je 64bit?

To je asi na dlouhou diskusi. Spousta by ocenila mít ZFS out-of-box, což je dnes docela problém. Pak samozřejmě můžete uvažovat i o provozu na FreeBSD, které má i některé další výhody oproti linuxu (a ty, kteří by ocenili ZFS by mohli i tyto výhody ocenit).

Přesto Btrfs je zajímavá alternativa k ZFS a snad se najdou uživatelé, kteří budou mít sílu pomoci odladit i ty více enterprise funkcionality.

BTRFS nemá oproti ZFS absolutně nic navíc, ba naopak, tunu funkcionality postrádá.

To záleží na kritériích. BTRFS používám kontinuálně od roku 2011 a za jednu z hlavních vlastností považuju flexibilitu a to na mnoha úrovních. Multidevice podle mých představ. Kdykoliv přidám, kdykoliv odeberu disk. Nejstarší FS, který už udržuju jen tak pro srandu, má devid přes 30. Tohle s ZFS neuděláte. Ano, už jde sice odstranit vdev (čistě formálně) ale existující vdev nepředěláte (snad krom single na mirror a zpět). ZFS tuhle flexibilitu prostě postrádá, základní jednotkou je vdev a pool se staví z vdevů.

Další flexibilita BTRFS je v tom, že snapshot je subvolume a především nezávislý. Takže udělám snapshot nějaké subvolume a tu původní smažu. Takto můžu udělat celý strom subvolume a libovolné z nich promazat.

U ZFS je snapshot datasetu pevně svázán s tím datasetem. Nemůžu smazat dataset a nechat si jen jeho snapshoty. Ano, můžu udělat clone nějakého snapshotu a získám nový dataset, ale ten je ale navázán na původní snapshot (a ten zase na původní dataset). Ano, můžu tento snapshot pomocí zfs promote posunout na nový dataset a ten starý dataset smazat, ale zase nemůžu smazat ten snapshot, ze kterého jsem udělal clone. Prostě už tam bude navždy.

Tohle strašně komplikuje použití těch datasetů.

Na BTRFS mám postavené kontejnery (nspawn). Některé slouží jako template, a ty občas updatuju. Kdykoliv z těchto template udělám nový kontejner. Staré template subolume mohu kdykoliv promazat.

Tohle na ZFS prakticky neuděláte. Když z jednoho snapshotu naklonujete více datasetů (třeba pro jaily) , tak se těch původních snapshotů nezbavíte. Takže nové jaily nakonec řeším plnou kopií template přes zfs send / receive.

Díky za praktické srovnání ZFS a BTRFS.

Od verze 0.8 jde skládat zpooly z kolika vdevů chceš a dělat s tím psí kusy dle libosti. Dokonce lze celej zpool přenést na menší vdev, to dřívější verze neuměly, pravda.

Ano, snapshoty se chovají rozdílně, s tím je nutné počítat.

Mně na BTRFS například chybí:
Šifrování, l2arc cache a zil cache. :-)

Osobně používám Btrfs přes dva roky v noťasu (Ubunut 18.04.3 LTS | kernel 5.3.18 | btrfs-progs v4.15.1) - dva 512GB SSD disky na RAID0 - jeden mSATA a druhý SATA3. Vytáhnu z toho, tak rychlost čtení a zápisu až na cca 900MB/s a 2x větší IOPS. Vytvořené subvolume na / alias @ a /home alias @home, k tomu jeden klasický disk místo dvd mechaniky, který používám pro nedůležitá data a jako zálohovací. Mám napsaný bash skript spouštěný cronem každou hodinu a vytvářející jednou denně snapshot z @ a @home a tyto snapshoty mi posílá skriptík rovnou přes btrfs send | btrfs receive na klasický disk s Btrfs samozřejmě, kde jsou inkrementálně zálohované, mám to zautomatizované tak, že se o to vůbec nestarám. Na RAID0 mi to promazává více jak 14 dní staré snapshoty automaticky (pořád mám ale snapshoty přistupnné 3 měsíce zpět na jiném fyzickém disku, 3 měsíce je až až pro mé potřeby), jednou za měsíc se odleje inkrementálně poslední snapshot @home a @ na externí USB disk, pro jistotu.

Obnova v případě vážné havárie disků v RAID0 je úplně jednoduchá bootnu live distro na usb a použiji čtyři příkazy v terminálu:

mkfs.btrfs -m raid1 -d raid0 /dev/sda1 /dev/sdb1 - vytvořím si nový souborový systém s metadaty v raid1 a daty v raid0
btrfstune -U XXXXXX /dev/sda1 - změním UUID prvního disku na původní, protože po naformátování je mu přiděleno jiné náhodného UUID, tak abych jej nemusel měnit v fstab a grubu
btrfs send /media/HDD/.snap­shots/20200218_0­90101/@home | btrfs receive /media/XXX/@home - pošlu si vybraný snapshot s adresářem home na nově vytvořený Btrfs filesystém
btrfs send /media/HDD/.snap­shots/20200218_0­90101/@ | btrfs receive /media/XXX/@ - pošlu si vybraný snapshot s adresářem / na nově vytvořený Btrfs filesystém

Změním zapsané snapshoty, které jsou ještě v read only režimu (byly to snapshoty v inkrementálním režimu) na zapisovatelné
btrfs property set media/XXX/@home ro false
btrfs property set media/XXX/@ ro false

Rebootnu noťas a jedu :)

Btrfs je podle mého skromného názoru báječný souborový systém i pro desktop použití, docela jsem s ním dříve hodně cvičil, když jsem se jej snažil pochopit a zkoumal jej, ale nikdy mi nezhavaroval tak, že bych se nemohl dostat k datům.

Nejvíc na něm oceňuji lehkost práce se snapshoty, implementaci interní komprese zstd, a možnost přidávat a odebírat disky dle potřeby, ještě by to chtělo implementovat interní šifrování a nemělo by to chybu.

18. 2. 2020, 15:20 editováno autorem komentáře

"Obnova v případě vážné havárie disků v RAID0 je úplně jednoduchá" - jako komické číslo je takové konstatování fakt úžasné, to je jak nabízet nemožné ihned a zázraky do 5 minut :D

U ZFS za mna napr chyba moznost zmensit ulozisko a ma to vacsie pamatove naroky.... Samozrejme nebavime sa o enterprise

Od verze 0.8 s tím není žádný problém, sám jsem migroval původně 750GB zpool na 120GB mirror z SSD.

U ZFS za mna napr chyba moznost zmensit ulozisko a ma to vacsie pamatove naroky.... Samozrejme nebavime sa o enterprise

To je právě životní nesnáz pro Btrfs. Funkce má naprojektované podle enterprise filesystémů, ale ve skutečnosti s ním zatím pracují převážně jedinci, kteří tyto funkce nevyžadují. Pro málé (nebo domácí) použití je Btrfs navržený hodně velkolepě, ale nedopracovaný. Pro enterprise použití není naplánován dost velkolepě (dnes je konkurence dál) a zároveň není dokončený a zároveň jsou zvoleny kompromisy pro "malé" použití.

Btrfs by potřeboval nějakou vzpruhu, někoho, kdo se enterprise funkcí ujme a opravdu je dotáhne a hlavně vymyslí, jak mohou oba scénáře použití dlouhodobě koexistovat.

Nebudu opakovat, co už napsali jiní (hlavně p. Crhonek), přidám svoje:

Zvolil jsem btrfs jako filesystem i distribuční metodu pro polo-průmyslovou síť "IoT" embedded zařízení. Na poli hardwarovém klasika - SoC s "áčkovým" ARM Cortexem, pár set mega DDR3 paměti, pár GB NAND flashe. Flash je klasicky pomocí mtdparts rozdělen na různé oddíly podle boot předpisu čipsetu, zbytek je formátován jako jeden btrfs oddíl. Klasická MBR/GPT tam není. V oddílu jsou subvolumes, které systém používá: read-only rootfs, jeden s konfigurací, jeden se persistentním stavem prvků, nějaké logy atd.

Updaty se distribuují jako btrfs delty, tj. na mastering mašině se provede btrfs send -p starý_subvol nový_subvol | zstd | nějaké crypto s podpisy > update.bin, to se dá na veřejný server, odkud si to postahují stroje v terénu. Aplikují to na sebe, čímž vznikne nový (tenký) subvolume nezávislý na stávajícím, přehodí se nějaký symlink, a systém se restartuje. Když dojde k chybě, nezávislý watchdog v bootloaderu symlink přehodí zpátky a nabootuje předchozí (known-good) subvol.

Super je, že díky architektuře těch delt není podmínkou, aby starý subvolume byl beze změn - deltu lze úspěšně aplikovat i na subvol, který byl např. zákazníkem modifikován. Jeho změny jsou tak propagovány i do nové verze.

Díky block-level součtům máme perfektní přehled o zdraví eMMC. Když někde selže modul, zpravidla to víme dřív, než se to projeví na provozu. Scrub odhalí všechno. V síti máme nasazeno lehce pod 5000 zařízení (kolem 24 tisíc device-years), k chybě způsobené btrfs nedošlo nikdy. Pár selhání flashe, pár PEBKACů.

"Na poli hardwarovém klasika - SoC s "áčkovým" ARM Cortexem, pár set mega DDR3 paměti, pár GB NAND flashe."

Asi sem lehce zaspal dobu, ale vetsina IoT zarizeni, co pouzivam, ma RAM v radu desitek kB a Flash v radu jednotek MB :D.

Proto ty uvozovky, že :-)

Je to normální moderní PLC, ale marketing trvá na používání buzzwords jako IoT a cloud.

Jak je to s tou databází, vypnutím COW a snapshoty? Rychlé snapshoty samozřejmě závisí na COW – znamená to, že když udělám snapshot, bude btrfs příznak vypnutí COW ignorovat? Nebo mi vůbec nedovolí snapshot na oddílu přimountovaném s vypnutým COW udělat? Nebo (to by byla nejhorší možnost) to btrfs vůbec neřeší a s vypnutým COW bude klidně přepisovat data ve snapshotu?

Já jsem k tomu psal výše, že celé doporučení vypínat CoW na databáze mi přijde pochybné. Jaký existuje lepší případ pro CoW, než u databází? (Výkonnostně to nemůže mít měřitelný vliv, díky zápisu pages.)

Záleží na tom, jak má databáze data uspořádaná. Ale obvykle jsou databázové soubory optimalizované z pohledu rotačních disků, aby se předešlo fragmentaci. Pak samozřejmě vypnutí CoW dává smysl, protože CoW vám to celé rozbije a soubor fragmentuje.

Ano, to je snad jediný případ. U většiny filesystémů stejně nemáte možnost rozumně fragmentaci ovlivnit a nastavovat databázi podle "situace na discích" je zbytečně komplikované. Filesystem (a volume manager) je zde od toho, aby znal topologii disků a určoval, jak je nejlepší zapisovat. Databáze má být od tohoto dilematu odstíněná jak jen to jde. Ve skutečnosti databáze neumějí předejít fragmentaci na discích.

ZFS tento gap řeší pomocí ARC a ZIL (Adaptive Read Cache a ZFS intent log). Pokud je nenastavíte, ano, přicházejí nevýhody. Pokud je nastavíte, přicházejí výhody. Třeba si myslím, že provozovat ZFS (analogicky Btrfs) bez ARC/ZIL je případ bez use case. Nedovedu si moc představit, jaké výhody má okleštěné ZFS (Btrfs) oproti tradičnímu filesystému. Databáze bez CoW, snapshoty, které plně a výkonně nezajistí atomicitu - no pěkně děkuju, to mi přijde naprosto vyhovující Ext4 a jediné, v čem se přizpůsobím je způsob archivace a zálohování.

Ono se vůbec vymýšlejí kombinace bez use cases.

Velky databaze casto nepouzivaj filesystem vubec. Proste zapisujou primo na disk. Zadny nastavovani neni potreba DB server se o vse postara sam a fragmentaci samozrejme resi vlastnimi nastroji.

Snapshot lze pořídit i s nocow. Ke zkopírování změněného bloku dojde, ale jen jednou, při jeho první změně. Takže bez problémů.

Jinak balíčky některých db (vím určitě o PostreSQL v Debianu) nocow na datových adresářích nastavují už roky. Takže je to do značné míry již zavedeno v praxi.

Takže je to do značné míry již zavedeno v praxi.

Otázka je, jestli to není jen nějaký hotfix na stav Btrfs, postupně povýšený na standard.

Odpověděl jsem vám výše. Velmi záleží na konkrétní architektuře dané DB, ale některé dělají něco jako COW sami (už jen z důvodů viditelnosti záznamů různými transakcemi).

To ano, ale CoW má zanedbatelnou režii. Zápis stránky (ať už se jedná o existující nebo novou) trvá stejně s CoW, jako bez něj. Jediný rozdíl je v napojení zapsané stránky - a ta režie je (měla by být) absolutně zanedbatelná. Na flash médiích se stejně nepřepisuje stejný fyzický blok.

Pokud má existovat nějaký význam CoW, tak je právě v tom, že aplikace by měly (postupně, volitelně) přestat řešit starost o zápis dat a přenechat to na filesystému. Vypínání CoW jde naprosto proti velké výhodě Btrfs či ZFS. Jak Filip správně poznamenal, ztratí filesystem možnost inteligentně (s malou režií) řešit snapshoty, takže další ztráta proklamované výhody.

Pokud má něco výkonnostní výhodu, pak je to nastavit správnou velikost stránky na filesystému vs. databáze. Vypínat CoW je špatně.

Sekcia "Repair tools" sa mi veľmi nepozdáva.

Podľa btrfs wiki je "btrfs check - - repair" to posledné, čo by ste mali vyskúšať. https://btrfs.wiki.kernel.org/index.php/Btrfsck "btrfs check --repair, aka btrfsck is your last option if the ones above have not worked."

Opensuse má na wiki popísaný podrobnejší popis obnovy/opravy btrfs: https://en.opensuse.org/SDB:BTRFS

(S opravou btrfs nemám žiadne skúsenosti. Btrfs mi beží na Tumbleweede na / zatiaľ bez problémov)

Přesně tak. Btrfsck nebo btrfs check je v praxi, pokud se vyskytne problém, nepoužitelné. Na notebooku mně za posledních 10 let několikrát potkala Poweroff death a pak zjistíte, že to prostě nefunguje (zatímco takhle na serveru, kde vám stále běží online check nástroje za stejnou dobu nepoznáte problém).

A jediné, co má pak smysl je btrfs restore s následným přeformátováním a nakopírováním dat, která se podařila obnovit zpět. Možná by tuhle sekvenci včetně nějakých rozumných pojistek a automatického obnovení nastavení (např. subvolumes) mohli integrovat v nějakém lepším, opravdu použitelném opravném nástroji.

Doporučil bych autorům/udržo­vatelům tohoto fs vylézt z univerzitních kabinetů nebo temperovaných serveroven a třeba používat nějaký čas svůj notebook naformátovaný výhradně v btrfs, včetně velkokapacitních výměnných disků (portable) v těžším terénu, v různých podmínkách. Myslím, že by se pak rychle chytli za hlavu.