Vlákno názorů k článku ZFSBootMenu: bootování Linuxu na souborovém systému ZFS od dustin - Používám několik let na několika strojích a zatím...

Pripadne vymen poskodeny po 5 rokoch ked uz sa ziadne rovnake ani nedaju kupit.

to je dost odvážné tvrdit, že btrfs je moderní a zfs oldschool :).

Btrfs je prostě nepořádek, dopředu nejsi schopný říct, jak to bude kdy výkonné, při zátěži má místy propady výkonu, o alokacích pro jeho různá metadata a odmítnutí fungovat, ikdyž na disku je vidět místo tady už také zmíňka zazněla. Dělat recovery je dost obtížné, musíš pečlivě studovat vnitřní strukturu a zdroják. Tohle není moderní, tohle je nepořádek.

Zfs v tomhle jde přímočaře dopředu, po nějaké době začneš velmi dobře tušit, jak se kdy zachová, jak to obnovit, co s tím dělat. U btrfs ti ani roky nedají dostatek zkušeností a to je problém.

Já jsem teda rozdrbaný file systém neviděl už roky. A to ani na strojích s consumer grade disky a bez UPSky. Jak často opravuješ Btrfs a ZFS?

A jak děláš testy na recovery a stabilitu? Vždyť součástí toho je prostě být ten zlý a snažit se ten systém rozbít klidně kladivem sám a hledat, v kterých místech to selhává a co se musí vyřešit technicky, co procesem/policy, co monitoringem/doh­ledem. Rozdrbaný fs vidím při každém větším release, tj. alespoň několikrát do roka.

Jak jinak chceš získat zkušenost s provozem, resp. s obnovou? Je naprosto běžné, že u projektů s tím nejsou 10 let vůbec žádné problémy a pak najednou to lehne celé a sháníš odborníky po všech čertech (zdravím Alzu a jiné).

To je právě ten zásadní problém, dnešní HW a SW už je tak stabilní, že se za běžných okolností k moc problémům (pokud jde o uložiště obecně) a opravám nedostáváš, pak nemáš ani zkušenosti.

Tj. když mluvím o problémech btrfs a zfs, tak dnes už mluvím o situaci, kterou musím umět vyvolat, protože se stane tak málo, že jí běžně nepotkáš. Pak ti ale támhle nezvládne ČEZ řízení sítě jako nedávno, lehne proud v 1/3 republiky a máš najednou 5 klientů, kterým něco obnovuješ, na tohle prostě musíš být znalostně a procesně připravený a ne si to teprve jít googlit, že jo. Rozumíme si?

Mě je vcelku jedno jak něco zachránit, protože si nemůžu dovolit něco zachraňovat. Nejde totiž říct jak dlouho to potrvá a jestli to vůbec bude úspěšné. Takže mám recovery plan postavený na backupech, který bude fungovat vždy a vím, že můžu klientům napsat, že za X hodin to poběží.

problémy nejsou binární. Backup ti nevyřeší to, že fs špatně kontroluje checksumy, má velké výkyvy v rychlosti zápisu, neumí správně detekovat poškozený disk a zapisuje si dál, dělá falešný fsync, takže aplikace neví o problémech, má chybnou logiku v snapshotech, takže děláš zálohu předchozího a ne aktuálního atd. atd.

Obnova zálohy z druhé lokality nemusí být do pár hodin, to vyloženě záleží na objemu dat a kapacitě linky. Stejně tak u toho musíš vědět, co obsahuje tvoje záloha, jestli data, OS, konfiguraci OS, co se od zálohy změnilo, jestli budeš dělat nějaké rekonciliace atd.

Doba, kdy mi klientovi stačilo říct, že všechny problémy světa řeší offsite backupy je dávno pryč, dnes jsou klienti už chytřejší, předpisy konkrétnější a neprojde mi to.

Tak já nejen že vím, jaká data zálohuji, ale dokonce vím, za jak dlouho je obnovím :-)

Já data zálohuji na server, který umí fungovat jako i jako záložní. Žádný přesun pak není nutný. Stačí to jen spustit přímo ze zálohy. A na to se mimo jiné hodí to zfs send.

"Takže mám recovery plan postavený na backupech,"

=== pocitas s tim, ze proste o data prijdes. Protoze jakmile obnovujes backup, vzdy prijdes o data.

Navic klientum nic napsat nemuzes ani tak, protoze jak casto testujes obnoveni tech backupu? A obnovujes vsechny? A zkousis to zapnout? A....

Neznam totiz moc firem, ktery by mely kompletne zduplikovanou celou infrastrukturu, takze si tak maximalne muzes otestovat nejaky vzorek, a modlit se, ze vysledek toho testu se da aplikovat i na ten zbytek.

Navic obnovovani backupu je typicky spojeno s akcemi nejakych dodavatelu, kteri ti sice ledacos slibi, ale realne dodat neumi. A garance jsoy typicky na tema "... tam vam v nejlepsim pripade vratime penize za ten support..."

Mimochodem, soucasti prace admina je prave i vyhodnoceni vhodnyho postupu v pripade nejakych tech problemku. A ne otrocka aplikace nejakyho checklistu.

Když mi bylo 20, tak jsem v případě "problémků" "vyhodnocoval postupy". Teď mi je 40 a jedu podle checklistu. Na vyhodnocování má člověk spoustu času při přípravě toho checklistu, ale když k něčemu dojde, tak děkuje bohu, že ho má a může mu "otročit".

Jinak ta obnova nejde na původní stroj, takže pokud tam jde něco zachránit, tak se to třeba zachrání. Klíčové je ale napsat klientům "poběží to za 5 hodin" a dodržet to. Co nechtějí slyšet je naopak "teď si s tím budu hodinu hrát a pak uvidíme".

"to je dost odvážné tvrdit, že btrfs je moderní a zfs oldschool"

To neni, to je realita.

zfs pouziva raidgrupy. Pokud chces pridat disk, musis pridat raidgrupu = minimalne 2 disky v pripade zrcadla. Odebrat disk samozrejme nelze vubec. Presne stejne jako u HW raidu.

btrfs ti umozni pridat libovlny jeden disk a stejne tak ti umozni libovolny disk odebrat.

Mimochodem, spravna cesta uz byla urcena, protoze temer cokoli do se dneska jmenuje diskove pole pouziva tu druhou moznost.

zfs o organizaci raidu vlastne nic nevi, protoze pouziva az tu raidgrupu. Coz pochopitelne vede i ktomu, ze chte nechte musi narozdil od btrfs pracovat s blokama.

btrfs vi jaky pouzivas raid, a muzes je prakticky libovolne mixovat podle potreb. raid navic neni o sektorech/clus­terech ... ale o tech souborech. Mimochodem, znacna cast tech proklamovanych problemu s R5 je zpusobena tim, ze tohle prislusni admini jeste porad nepochopili.

A právě proto je btrfs takový chaos. Mimochodem doporučuji si pročíst materiály OpenZFS proč tuhle "výhodu" nechtějí implementovat. Ono to vypadá hezky jen na papíře.
Ale chápu, že to někomu přijde cool a chce si s tím hrát - no offense. Na produkci tohle nemá co dělat.

Ono to je rozdiel medzi:

Svokra povedala: 0xA7
manželka povedala: 0xB7

Kto má pravdu? Pri mdadm, alebo raid grupách sa nevie imho. Ale spolieha sa na to, že show must go on a proste sa povie, že ten, ktorý zápis bol neskorší, má pravdu a ide sa ďalej.

Pri btrfs, sa pozrie na svokrin checksum a na manželkych checksum a to, čo je nesprávne sa vyhodí a zreplikuje sa to správne inde. Ak "inde" neexistuje (jeden z dvoch diskov skapal), tak sa fs prepne do stavu: nespĺňam špecifikáciu s ktorou som bol vytvorený a končím. To nieje raid. Teda high availability vec. To je viac backup vec. Preto to na serveri admini nechcú... ale napríklad na zabezpečenie korektnosti dát to je imho lepšie. Toto imho uniká mnohým diskutujúcim. IMHO nemal btrfs nazvať raid to, čo je "duplikácia"/kó­pia/záloha/syn­chrónna replika...

20. 10. 2026, 20:43 editováno autorem komentáře

ano, to je výhoda checksumů, jsou ale drahá na metadata a pro mě je pak velmi těžké určit, který disk mohu ze serveru bezpečně odstranit, nevím jaká část dat tam je, u zfs to vím přesně dopředu.

To je prostě jiný use case a není to zaměnitelné pro spousty použití.

"Na produkci tohle nemá co dělat."

Asi neumis cist. Jak sem psal vejs, tohle a presne takhle delaj profesionalni diskovy pole za miliony v zakladu. Ono totiz v ty realny produkci nikoho nezajimaj nejaky politicky dusledky, ale realny vysledky.

U klasickyho raidu definuju odolnost proti vypadku pri vyrvareni toho raidu ze? A ta je definitivni a fixni. Nemuzu to zmenit jinak, ne ze ten raid zrusim a vyrvorim znova ze? Zatimco u FS raidu to muzu menit kdykoli za provozu.

A tudiz trebas moje 24 diskovy minipolicko ma sice v zakladu R6, ale to by platilo v pripade ze by bylo zcela zaplneny. Ve skutecnosti v pripade selhani a volneho prostoru dojde k prerovnani pole ... a to je i bez toho disku porad nedegradovany R6 ... a takhle muze pochcipat tech disku klidne pulka.

Tohle je presne ta vlastnout, kterou s klasickym raidem (a tudiz ani se zfs) vubec nejses schopen realizovat. Vede to mimochodem k pomerne znacnym usporam (samo na malych poctech disku to neni zas tak zasadni) a vede to i navyseni dostupnyho vykonu a prostoru. A tou sou presne ta cisla ktera rozhoduji o tom co jak bude nebo nebude fungovat.

btrfs sice umí R6 na 24 disků a dynamicky to měnit, ale metadata umí nejvýše 4 kopie (-m RAID1C4), takže při umření poloviny disku to je loterie, jestli jsi trefil 4 kopie pro dané metadata block group nebo ne, je ale velmi pravděpodobné, že jo. Odolnost je pouze 3 disky najednou, pak můžeš přijít o data. Počet metadata block gorup rostou s počtem souborů a nikoliv jejich velikostí (zaplněností).

Tohle je na btrfs fajn a i jeho nevýhoda, na malé systémy ho mám rád, u velkých mi ta nejistota prostě vadí.

"btrfs sice umí R6 na 24 disků a dynamicky to měnit, ale metadata umí nejvýše 4 kopie"

Kdy ti naposled chciply 4 disky najednou? To pole po chcipnutym disku udela rebalanc .. tudiz zadnej disk nechybi. A kdyz ten chciplej vymenis, udela to znova.

Kdyz vemu klasicky R10 ... tak je to KO bez ohledu na pocet disku po druhym mrtvym ze? Kdyz vemu klasicky R6 ... prezije to 2 disky a KO je to pri tretim ze?

U klasiky ze pouzivaj spare disky. Jejich pocet by mel samo nejak odpovidat celkovymu poctu disku, pri tech 20+ bys mel mit aspon 2. To znamena, ze mas dva plonkovy disky ktery nic nedelaj. V aktualnich polich ale jen vyhradis spare kapacitu (treba o velikosti tech 2 disku) ale ty disky na sobe maji data a dodavaji IOps. Tohle s klasikou nemas jak udelat.

Predstav si ze tech disku mas desitky tisic, to znamena tisice spare disku. Vs nejaka, vyrazne mensi spare kapacita a dalsi desitky tisic (v pripade mechaniky) IOps navic. To uz nejaky ty milionky hodi ze?

Tak hlavně jsi to psal sám, že klidně můžeš přijít o polovinu. Ten rebalance nebo replace musíš udělat ručně, brtfs pole ti to samo neudělá, stejně tak nepodporuje žádné hot spare disky, logiku kolem brfs replace si musíš opět volat a hlídat sám.

Nemám nic proti btrfs, jen mi tvoje tvrzení nesedělo. Na nějaký domácí nas to je podle mě mnohem lepší než zfs, protože to máš pod rukama, občasný výpadek ti nevadí, můžeš si to přeuspořádat jakkoliv a je to fajn, jakmile to ale nasadíš na flotilu serverů, zešílíš z té správy, nějak to rozumně automatizovat je strašně těžké, ty status příkazy jsou tak neskutečně hloupě automatizovatelné až to není hezké.

Při blackout celých sálů těch disků vždy odpadne dost, takže se to párkrát do roka řeší.

OK. Na druhé straně pokud jedu hlavně na bezpečnost dat a spolehlivost je lepší být trochu konzervativní. Hodně tak může záležet na tom, jak drahé a nenahraditelné jsou vaše data.

AI mi na dané téma napsala:

"For large disk arrays and large-capacity storage pools, I would generally favor ZFS, especially for a server or NAS holding important data. But Btrfs can also work well, depending on the number of disks and the redundancy you need."

Je to trochu rozdíl filozofií FreeBSD a Linuxu. FreeBSD vsází více na jednoduchost a dlouhodobost. Linux by pořád něco měnil a nabízel spoustu možností, což může být jak výhoda tak zbytečná komplikace a potencionální zdroj nestability. Od cca roku 2000 Linux měnil implementaci firewallu už třikrát, FreeBSD funguje pořád stejně a přitom se nedá jednoznačně říci, že v Linuxu by to bylo lepší ani po všech těch změnách. Viz. např. pfSense profi openSource router postavený na FreeBSD.

Proč nemá Linux plnou a automatickou podporu všech výhod co může Btrfs nabídnout ? Protože to velká část uživatelů Linuxu stále nepoužívá. Je to stále tak nějak dodělej a dokonfiguruj si to sám. S výjimkou OpenSuse jsem na tom tedy dost podobně jako když používám pod Linuxem konzervativnější ZFS.