Názory k článku ZFSBootMenu: bootování Linuxu na souborovém systému ZFS

V článku jsem nenašel odpověď na základní otázku, která se přímo nabízí. Proč podstupovat relativně složitý proces instalace Linuxu na ZFS místo použití nativního BTRFS?

Nechci vyvolávat flamewar, ale ZFS vs BTRFS jsou dost odlišné filozofie, byť mohou vypadat v základu stejně. Zkuste si vyhledat řešení problémů s BTRFS a pak se ZFS. Zkoušel jsem celkem důkladně oba filesystémy.

Já detailně neznám ani jeden, nicméně autor uvedl pouze povrchní obecné zdůvodnění proč použil ZFS a nijak se nevypořádal s variantou BTRFS.

Toto není kritika, a není důvod proč by kolem toho měl vzniknout flamewar. Skutečně by to článku slušelo, protože ta otázka se opravdu nabízí.

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

Hlavne Btrfs nezvlada dodnes spolahlivo RAID 5. To ho diskvalifikuje z mnohych implementacii ale inak na desktop je to dobry suborvy system a sam ho pouzivam na openSUSE a nikdy som nemal problem.

P.S. Tesim sa na pokracovanie serialu.

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

BTRFS ma problemy, ale raid5 mezi ne v zadnym pripade nepatri. To sou takovy kecy ktery se tu uz nejmin 15 let setrvale dokola objevujou.

Ostatne zkus si provozovat libovolnej HW raid bez baterky a vytrhni ho z elektriny ....

Zaprve zvlada ;-) i raid6, 5 je dnes mimo - mame prece hodne diksu, ale je treba dat index na vice disku - dupliakce aby to paik umle opravit, ale ani je to k nicemu, RAID6 se resi pres SW_RAID, nebo LVM - popr. 3ware RAID radicem ... a nebo to neresi jako ja, nebot mams FC pole, treba HPE Primera popr. Hitachi ;-))

SW_RAID i LVM umi veci, jako rozsireni raidu o disky, nebo dokonce konverze na jiny typ RAID - expand RAID a tak ...

Jak jsem prechazel na nove disky ? - mel jsem vetsi a jedn po druhem jsme menil a delal resync ...

Ale pak jsem prechazel na 20TB - stejna metoda nejdrive jsme tam dal 4 stare a 4 nove, myslim ze jsme data nekopiroval ale dal je do RAID a postupne jsme disky jeden po druhem odebiral - pustil se rebuold, nakonec jsme vytahl vsechny 4 stare disky, dodal 4 nove 20TB, dal je jako spare a udelal konverzi ONLIEN na raid6 a pak jsme raid expandoval a pak na nem expandoval BTRFS - na BTRFS mam 2x index - metadata DUP - je to pak uber bezpecne a mam tak doma 8x 20TB disku v RAID6

Musi mit i SSD 3par - 24 disky - mam i vice polic - a ted chce firma vyhodit jednu HPE Primea plnou SSD disku - ale tyhle masinky silene huci a ja mam NAS doma ;-)

takze jak vidis, takl s RAID6 si umim dobr eporadit, ale ze ZFS, ktwery se vzdy znici a prijdu o datat, ktere pak nelze opravit si uz poradit neumim - a dodnes neni oprtavny nazdroj, jen po kupe znicnych ZFS aspon prinzali, ze ano, ze se ZFS kazi je na to navod co udelat, to ti temer nikdy nezabere ;-) a pak obnovujes se zalohy - uz jsi prisle o data ? a kolikrat ? - ja mam teda ten NAS primarne na zalohy a dulezita data m,am ma RAID5 na Linuxu a zarovne na NAS - zaloha je krizova - neco nativne pouzvam na NAS, ale zaloha je na Linuxu - neb k tomu chodim z MacOS a Linuxu - tak je mam 10Gb LAN

Jo vite ze NFS podaruje z Linux paralelizmus s vice steamy ?

To je zajímavé, více než 10 let používám Btrfs na NASech Synology a nepřijde mi, že by nezvládal RAID. Tedy, nemám RAID5, mám SHR, ale on to v podstatě je upravený RAID5. Co by mi konkrétně nemělo fungovat nebo v čem by to mělo být problematické?

myslím, že to ani nebyl cíl článku, porovnat tyhle dva fs.

Roky jsme testovali btrfs, jestli nedokáže naplnit potřeby, které naplňovalo zfs, v době, kdy se trochu licenčně nepohodli. Btrfs je divný, diagnostika a recovery tam je slabé, pořád člověk musí lézt do zdrojáků. Poté jeho správa alokací je opravdu magie, při velkých systémech, častých změnách a velkému rozdrobení prostoru velmi rychle ztratíš naprosto přehled kolik co bere místa, na disku vidíš desítky GB, ale zápis končí na ENOSPC, btrfs balance není všelék. Za mě si s zfs jsem jistý, vidím, vím, umím.

Naopak btrfs se velmi dobře osvědčilo na malá zařízení, na různé SoC, kde běží linux, pěkně se přes to řeší aktualizace a celková správa.

Z mých malých zkušeností bych řekl, že ty fs si prostě nekonkurují, mají rozdílný segment.

Nebylo to myšleno osobně. Doufám, že v dalším pokračování bude rozvedeno samotné ovládání a používání ZFS. V tom vidím jeho nejsilnější stránku. Třeba to naláká někoho na vyzkoušení. Největší slabina tohoto filesystému je bohužel nekompatibilní licence.

Mě ta otázka také zajímá. ZFS nemám, neprovozuji nějaké obrovské serverové pooly disků, ale rozhodně věřím že je zde skvělý. BTRFS používám mnoho let jako systémový všude (i na malé RAIDy třeba na raspberry) a nikdy s tím nebyl problém - v kontextu článku hlavně s použitím jako FS pro systém. Přeci jen se článek věnuje instalaci Debianu na ZFS, ne velkému datovému úložišti. Některá distra dokonce mají nativní podporu s bootováním do záložních snapshotů či různých BTRFS volumes. Tady máme ZFS moduly jádra, co se musí pokaždé aktualizaci jádra znovu přeložit, k tomu specifický nástroj na bootování, což mi osobně připadá jako dost velký potenciál na to že se něco (v bootování) rozbije a budeme muset řešit. Sám jsem také čekal rozvedení toho, jaký soubor výhod proti BRTFS v tomto konkrétním využití je, když už se vydat takto relativně neprošlapanou cestou.

Můj důvod proč použít ZFS je ten, že ZFS používám na serverech. A na serverech se používá proto, že v době kdy se to zavádělo, BTRFS nebylo ještě dostatečně vyspělé a i nyní bych pro nasazení např. pro opravdu zatíženou databázi volil raději ZFS než BTRFS. ZFS je prostě více odzkoušené pro kritické nasazení.
A jelikož ZFS používám na serverech, je pro mne lepší jej používat i na desktopech, i když co se nasazení desktopu, je BTRFS nejspíše odladěné dostatečně.

Byl by to zajímavý článek jak dosáhnout stejné funkcionality s BTRFS. Tedy možnost vybírat verzi systému do které nabootuji při startu. Instalace by byla předpokládám snadnější. Používání také? Ne nutně. Případně jak vytvářet a spravovat snapshoty systému. U ZFS je to něco, co funguje automaticky na FreeBSD, velmi jednoduše a přirozeně. Při každé aktualizaci se automaticky vytvoří snapshot, aby bylo možné se při bootování vrátit v čase. A zjevně proto vznikl ZFSBootMenu, aby to stejné umožnil i na Linuxu. Což je se podařilo. Jen snapshoty se ale nevytváří automaticky, což ale není problém.
Nevšiml jsem si, že by BTRFS fungovalo stejně elegantně na Linuxu, ale možná je to tím, že jsem se o to nezajímal.
Zdá se, že většina linuxových serverů BTRFS stále nepoužívá. Ve FreeBSD používají ZFS v podstatě všichni a funguje to dobře.

Jinak není to tak, že bych přecházel na Linux z FreeBSD. Ale přesně obráceně. Používám také FreeBSD a dostal jsem se k němu přes ZFS, které jsem začal původně používat na Linuxu, ale ve FreeBSD je prostě více doma. Ve FreeBSD se mi líbí, že jsou věci jednodušší a přehlednější.

Zrovna pro aktualizaci systému a související tvorbu snapshotů se BTRFS používá už dlouho. Průkopníkem je Opensuse.

Dost by mne zajímalo jako jsou reálné možnosti a dobré postupy na Debianu. Nebo je to tak, že stačí vybrat při instalaci BTRFS a vše jej ke správnému efektivnímu používání navede? A proto vlastně o tom ani není nutné moc psát ? Takhle je to se ZFS na FreeBSD. Funguje to podobně dobře i na Debianu ?

U Debianu fakt netuším, pokud ano, budou to mít v dokumentaci. V případě Opensuse je to default varianta už roky, a funguje to out-of-the-box.

https://doc.opensuse.org/documentation/tumbleweed/snapper/

Když se na to ptám chatgpt tak píše: Btrfs + GRUB: Debian podporuje instalaci na Btrfs a nabízí balíčky pro správu snapshotů, například snapper a btrbk. Automatické zavádění a obnovu snapshotů je však potřeba nakonfigurovat.

Výběr systému při startu
ZFSBootMenu - Integrované prostředí
Btrfs+GRUB - Nutná správná konfigurace GRUBu

Návrat po rozbité aktualizaci:
ZFSBootMenu: Přirozená práce s BE (Boot Environment)
Btrfs + GRUB : Vyžaduje připravený postup obnovy

Správa záchranného systému
ZFSBootMenu obsahuje vlastní prostředí
Btrfs+GRUB: Záleží na použitém řešení

Šifrování:
ZFS - nativní podpora
BTRFS - používá LUKS

Klon systému pro experimenty:
ZFS se ZFSBootMenu - Velmi pohodlný
Btrfs+GRUB - Také možný

Tedy ač instalace samotná je s Btrfs určitě snadnější, vypadá to, že u samotného používání to už platit rozhodně nemusí. Integrace do Debianu zjevně není na tak dobré úrovní jako má integrováno FreeBSD ZFS s jeho Boot Environment. ZFSBootMenu se pak jen snaží to stejné nabídnout pro Linux. Tedy možná se budou moci článkem inspirovat i uživatele Btrfs. Podrobnější porovnání by ale bylo určitě zajímavé.

Mozte skusit OMV (https://www.openmediavault.org) ten funguje prave na Debian-e a podporuje BTRFS.

Tak jsem našel návod, jak instalovat Debian 13 s podporou snapshotů a využitím Btrfs.

https://sysguides.com/install-debian-13-with-btrfs

Překvapivě není nijak jednodušší než když se to stejné dělá se ZFS. A je to dost podobné.

Vypadá to, že openSuse tohle má vyladěné daleko lépe, ale přecházet kvůli tomu na Suse smysl nedává.

Ten návod je zbytečně komplikovaný. Ale záleží na to, co od toho očekáváš. Mi třeba přijde jako nesmysl oddělovat každý adresář v / do samostatného subvolume. To stačí na /tmp a /home, případně něco z /var/.

Instalaci mám provedenou jako standardní, / je běžně vytvářeno jako subvolume. Vytvoření dalších subvolume je pak jednoduché a dle preferencí.

Na správu mám snapper, ten si teda musím nakonfigurovat sám. Co se týče bootování, zde v grubu stačí v boot parametrech nastavit správný snapshot.

Pokud bych potřeboval, myslím, že by nebyl problém vytvořit něco jako zfsbootmenu pro btrfs. Ale asi to potřeba není.

Tady je další "překomplikovaný" návod jak nainstalovat Debian 13 na Btrfs + šifrování.

https://ravidwivedi.in/posts/installing-debian-with-btrfs-and-encryption/

Tento návod nepoužívá živou distribuci ale pokročilé možnosti instalátoru. Opět to nevypadá o mnoho lépe než ZFS + ZFSBootMenu.

Proč to sakra nefunguje rovnou bez těch nesmyslů? Pokud chci použít Btrfs, předpokládám, že budu chtít plně využít jeho výhody, jinak bych to nedělal.

U ZFS to chápu, je daň za omezující licence. Nerozumím ale proč na tom není Btrfs výrazně lépe. Tedy snad kromě openSuse, ale tam si nejsem úplně jist, jestli to nemá také nějaké skryté mouchy při porovnání se ZFSBootMenu o kterých se nemluví.

Jsem zaujaty,stranny a jako byvaly zamestnanec Sunu jsem byl pritomen zrodu ZFS filesystemu na solarisu v dobe kdyz BTRFS nebylo jeste ani ve stadiu slapaci nebo na klicku.
Verim vlozenemu casu kolegu do designu ZFS a mym vecnym pokusum ktere ho dohanely k padu. A i tyto chyby ovlivnily design struktur uvnitr FS. Take verim zatezovym testum farem co to chroupaly vc ruznych profilingu. Proste od zacatku na to byly prachy a to nemohla dat parta hipiku. Protoze to byl hard task a vyvinout stabilni FS s temito vlastnostmi neni jen tak.
ZFS pouzivam tam kde je to vhodne. Nektere zfs struktury poznavam i po letech a moc se nezmenilo.

Jako ale se vsim ZFS ma sve antipatterny pouziti kam se proste nehodi.

21. 10. 2026, 09:56 editováno autorem komentáře

Používám několik let na několika strojích a zatím s tím nebyl žádný problém. Ale fakt je, že jsem nemusel řešit žádné kritické recovery.

Když jsem ZFS nasazoval na servery, testoval jsem docela šílené scénáře :-). Náhodně jsem mu přepisoval bloky, týral ho na discích s chybami SMART, ale všechno ustál. Jen mu nedělá dobře, když se zaplní disky na 100% (to se dá snadno řešit nastavením kvóty) a je docela hladový na paměť. Ovšem šlape spolehlivě i na RPI4 se 4GB RAM ;-P

Myslel jsem to ZFSBootMenu, které je přeci jen netriviální kus softwaru na kritickém místě. Má někdo nějakou negativní zkušenost, o které by bylo dobré vědět? Tipnul bych si, že z diskutujících zde jej používá minimum. Vlastní ZFS považuji za naprostý standard, tam to asi nemá smysl řešit.

Se ZFS se problémy neřeší, se ZFS prostě problémy nejsou. Jediné co jsem řešil je přílišné opotřebování disku write amplifikací při použití na hodně zatížené databázi, která má převážně zápisy. Množství zaznamenaných zápisů by pak mělo odrovnat disk za několik let, což je zbytečný hazard i plýtvání. Žádná rada nepomáhala. Vyřešil jsem to přestěhováním databáze na FreeBSD, kde se stejný problém prostě nekonal. Po vhodném nastavení recordsize výkon a zatížení disku stejný nebo lepší jak na jiných souborových systémech.
Ale je to nějaká výjimka, neslyšel jsem o tom, že by se s tím setkal někdo jiný. I když naprostá většina uživatelů ZFS na Linuxu neprovozuje opravdu hodně zatíženou databázi na zápis. Protože jedině v tomto případě je to problém.

Mimochodem, přímo se nabízí otázka, jestli ZFS umí něco podobného, jako je chattr +C xxx na btrfs (no-copy-write), a případně, jak se to "popere" se situací, pokud existuje snapshot.

Ne, tahle možnost vypnout CoW v ZFS není, používá se vždycky.

"se ZFS prostě problémy nejsou"
Nj, mas problem v tom, ze guugl a spol sklerozou netrpej.

"Se ZFS se problémy neřeš"
S timhle se souhlasit da, protoze jakykoli problem se ZFS === data v trapu.

Taky bych byl nepoužil tuhle formulaci, ale zas to že někdo přišel o data nebo řešil nějaký problém si vygoogluješ o každém souborovém systému :)
Ano ZFS je relativně složité, jak pro korektní nastavení/archi­tekturu úložiště, tak z hlediska on-disk formátu, ale zas se to nedá paušalizovat a takhle tam dávat rovnítko (nebo tři). Jako u každého recovery, úspěšnost záleží na tom, co konkrétně se pokazí.

Jenze kdyz vedle sebe postavis btrfs a zfs ... tak mas moderni vs odschool fs. Moderni v tom, ze btrfs ti integruje nekolik vrstev, z cehoz muze tezit, do fs, zatimco zfs to drzi oddeleny, z cehoz plynou ruzny trable, identicky s HW resenim, coz pak vede k tomu, proc bys vlastne mel vubec zfs pouzivat?

Priklad, pridej(nebo odeber, ale to je typicky nepravdepodobna uloha) jeden disk.

No samozřejmě že je třeba brát větu "Se ZFS se problémy neřeší" s nadsázkou. Ale je fakt, že na cca sedmi strojích jsem za posledních 10 let nikdy problémy s integritou či opravou dat na disku neřešil. Pokud odešel disk, byl vždy v raidu.
A i kdyby byla data nečitelná, což se ostatně může stát vždy i třeba selháním hardware, tak bych to také neřešil také a místo toho použil maximálně 5 minut starý snapshot, který se automaticky vytváří a přesouvá díky inkrementálním zálohám na záložní stroj každých 5 minut. Tedy až tak nadsazené mi to nepřijde.

U nekterych databazi jsou primo postupy na optimalizaci ZFS. Pri velkych extremech se doporucuje vubec ZFS nepouzivat. Bud pouzit nejaky hloupy FS a nebo nepouzivat FS vubec a pouzivat raw block device. Zalezi jak mate konfigurovatelny db system.

Ano je to tak. V našem případě jsme nakonec hodně vytíženou databázi přesunuli na FreeBSD kvůli záhadné write amplifikaci a jiným záhadám pod Linuxem a vyladili tak, že jak výkon tak disk fungují lépe než na ext4 pod Linuxem s běžným nastavením.

Dobré je se zamyslet nad tím, jestli neomezit trochu sync a comity databáze. Aby se to nedělo dvakrát. Jednou na úrovni databáze a podruhé na úrovni ZFS. Vždy to stačí jen jednou. Pokud nevadí teoretická ztráta dat v desítkách vteřin při havárii hardware nebo výpadku elektřiny, je možných sync nechat jen na ZFS s tím, že jej stačí provést třeba jen jednou za minutu.
A pokud se jedná o databází, která je replikací hlavní databáze, tak vrátit se v čase pár desítek vteřin nevadí nikdy, protože replikaci mohu znovu nastartovat od okamžiku posledního syncu. V případě nutnosti též z okamžiku posledního funkčního snapshotu, který mohu dělat klidně třeba každých 5 minut. Replika pak ztracené dotazy provede znovu, takže ani možný výpadek elektřiny nepoškodí uložená data.
Výsledná rychlost a zatížení disku tak může být i lepší, než co lze dosáhnout s defaultním nastavením ext4 a databáze. Možnost snapshotů je velmi dobrý bonus navíc.

Zkoušet dělat podobné věci s Btrfs by asi nebylo úplně moudré, neb ten systém se na podobné scénáře tolik nepoužívá. I dnes bych dal přednost ZFS, protože je to lépe odzkoušené. Za mě je ZFS profi nástroj a jeho snapshoty a inkrementální synchronizace na záložní stroj (třeba i každých 5 vteřin) dovede výrazně usnadnit život.

https://vivianvoss.net/blog/zfs-integration?=0

Jako experiment to je určitě dobré, ale ZFS je silné hlavně na diskových polích a na desktopu/notebooku oproti Btrfs zas tak moc nenabídne. Btrfs je lépe podporované distribucemi a umí všechno, co člověk na desktopu potřebuje: subvolumy, snapshoty a kompresi.

Na serveru můžete použít úplně ten stejný postup. Instalaci na Desktop lze brát jako cvičení k tomu,a by jste to stejné mohli zopakovat na serveru. A možná někoho inspiruje článek i k tomu, že začne používat pokročilé možností Btrfs, principy jsou podobné.

To sice můžu, ale za mě to je recept na průser. Mám pár produkčních strojů, kde jsou data a systém na jednom poli a zkomplikovalo mi to situaci, kdy bylo potřeba přehodit disky z jednoho stroje do druhého. Dneska u nových serverů už dávám oddělený disk se systémem s Btrfs a pole s daty mám na ZFS. Je to mnohem pohodlnější, což člověk ocení až když něco nejede :-)

Naše požadavky na velikost místa nejsou tak velké, takže mít i samotný Debian na ZFS smysl dává. Dva disky máme mirorované pomocí ZFS a dávat tam další dva disky jen kvůli nabootování smysl nedává.

Pokud by těch disků bylo mnohem více, dává pak smysl bootování oddělit od samotných dat. Aby i v případě potíží s disky bylo možné nabootovat a problém se pokoušet opravit.

Za mě je nejlepší aby data byla co nejblíže místu kde se používají. Tedy mít vyhrazený stroj pro disková pole mi v mém případě nedává smysl. Místo toho každý stroj si uchovává vlastní data a zároveň slouží pro zálohování a jako záložní stroj pro ostatní.

Tak já nemluvím o vyhrazeném stroji. Mluvím o oddělení dat a systému. Navíc systém se v mnoha případech spokojí s jedním diskem a není nutné ho strkat hned do raidu. Jsou servery, které spokojeně bootují z jedné USB flashky.

A proč by byl problém nemít přes oba disky čistě ZFS, ale rozdělit je tak, že na boot (popř. root) bude ext4 nebo XFS nad mdraid RAID1 a na zbylém místě obou disků ZFS mirror? Nebylo by třeba řešit žádné nestandardní postupy kvůli bootu (stačil by léty prověřený GRUB) a data by se ukládala na ZFS. Upřímně nemám se ZFS prakticky žádnou zkušenost, ale nenapadá mě, proč by to v principu nemělo jít udělat takhle.

Myslel bych že na systém stačí jeden disk a ještě nějaký prcek. Zálohovat se může do toho ZFS RAIDu, ono toho zase nebude tolik co potřebuje zálohovat čistě v systému. Mě osobně by to přišlo příjemnější i proto že se oddělí případné potíže se systémem či ZFS tím, že to není všechno vzájemně provázané a tím snáze diagnostikovatelné.

Jinak samozřejmě proti gustu... :-)

zfs vie per-dataset encryption, btrfs este stale nie. Mat samostatny kluc pre kazdy homedir sa moze hodit.

Těším se na další článek. Snapshoty, incrementální snapshoty, posílání snapshotů, zfs send/receive, raidz, cache, zvoly a jejich použití na virtualizaci a jejich snapshoty, kombinování rychlých SSD pro cache a plotnových disků atd.

Za zmínku by stála deduplikace a její nároky na paměť - na tom se dost lidí ošklivě spálí a pak ZFS nemohou přijít na jméno.

Časté kameny úrazu by také stály za zmínku - obtížné změny disků v raidz, odlišná filozofie při uvolňování místa (smažu, ale snapshot nebo naklonovany volume data pořád drží), či potíže při zaplnění poolu. Swap na ZFS má také svá úskalí.

Díky a těším se na pokračování!

Z velkou částí potencionálně problémových věcí bohužel nemám zkušenost, neb jsem jej nepotřeboval nebo se jim preventivně vyhnul.

Když si něco smažu, místo se hned neuvolní, protože jej drží snapshoty. Je to logické a kromě smazání snapshotů s tím nejde nic dělat. Je třeba s tím počítat a po nějaké době snapshoty např. promazávat. SWAP nedávám na ZFS. ZVOL jsem zatím nikdy nepotřeboval.

Co by ale stálo za zmínku, že je dobré si pomocí SMART a jiných nástrojů hlídat, kolik dat se skutečně zapíše na disk a vyhnout se případné write amplifakaci. Aby se zbytečně nesnižoval výkon a nekrátila životnost disku. Lze to ladit pomocí hodnoty recordsize. Např. dataset s kterým pracuje databáze by měl mít nižší recordsize, např. 16 KiB. Defaultní je 128 KiB .

Deduplikaci máme vypnutou, neb duplicitních dat je stejně zanedbatelné množství v našem případě. A i když paměti máme dost, pořád teoreticky hrozí, že se může deduplikace pobláznit a zabrat výrazně více paměti než by měla. Horší to bývá, pokud je snížené recordsize, pak paměťové nároky na deduplikaci mohou růst výrazně více. Deduplikovat jednou za čas ZFS zatím neumí.

Kombinovat SSD pro cache a magnetický disk pro data jsme také nepotřebovali. Magnetické disky používáme v podstatě jen pro zálohy. Jde o to, že v našem případě nemáme na místo na disku nějaké obrovské nároky, pořídit si SSD disky na vše s čím se pracuje nebylo moc drahé.

Co používáme hodně je vytváření snapshotů a posílání na další stroj každých 5 minut. To funguje bez problému. V případě, že by se hlavní stroj odmlčel, lze vše pustit s náhradního stroje z maximálně 5 minut staré zálohy.

Zvol su fajn, pokial prevadzkujete virtualky. Kazdy zvol je potom virtualny disk (vid napr. proxmox na zfs).

Kombinovanie SSD a HDD ma tiez niekolko variantov:

- SSD metadata device + HDD data device: na SSD sa ukladaju metadata filesystemu, na HDD obsah samotnych suborov. Metadata devices mozu mat inu topologiu ako data device (donedavna aj museli, metadata devices nevedeli raidzN, uz vedia).

- na zaklade vyssieho sa da urobit aj zakladny tiered storage; da sa (per dataset) nastavit, aby sa medzi metadata ukladali aj subory po urcity treshold. TrueNAS 27 by k tomuto mal priniest GUI klikatka.

- potom su tu cache a tu sa vela ludi kopne: je ZIL (write cache: zapisuje na SSD, potvrdi sync a potom presypa na HDD, klient nie je obmedzeny rychlostou zapisu na HDD) a L2ARC (casto citane data, ktora sa nezmestili do RAM cache -- RAM je "L1ARC" -- zapise sem a potom pri citani ich berie odtialto, nie z HDD). Nema nejaku unifikovanu cache, spolocnu pre zapis a citanie. Tieto cache maju materialny dopad len vo velmi specifickych pripadoch, povacsine su zbytocne.

xsouku05:
Deduplikaci máme vypnutou, neb duplicitních dat je stejně zanedbatelné množství v našem případě. A i když paměti máme dost, pořád teoreticky hrozí, že se může deduplikace pobláznit a zabrat výrazně více paměti než by měla. Horší to bývá, pokud je snížené recordsize, pak paměťové nároky na deduplikaci mohou růst výrazně více. Deduplikovat jednou za čas ZFS zatím neumí.

V tomto pripade tedy diky za BTRFS a Bees. ;-)

Aj s vypnutou deduplikaciou explicitny reflink funguje a deduplikuje. V kontexte zfs sa deduplikaciou mysli online deduplikacia, kde aplikacia neriesi ci klonuje nejake bloky, ale samotny zfs si udrzuje zoznam existujucich blokov aj s ich checksumom v pamati a pri zapise prehladava, ci zapisovany blok uz niekde neexistuje a ak ano, ze staci len urobit odkaz.

No a prave tento zoznam existujucich blokov zabera mnozstvo pamate.

Offline deduplikacia sa da riesit pomocou nastroja tretej strany zfs-dedup.

Chci moc poděkovat za článek. ZFS mě již nějakou dobu fascinuje. Sice mám jen jedno offline zrcadlo na zálohování v rámečku, takže ho využívám proti skutečným adminům směšně minimálně (mně jde především o ochranu před přespinováním), ale i tak moc se těším na další pokračování, bude-li. Je fakt, že člověk prostě nepotřebuje, co nezná. Někdo se tu zmiňoval o deduplikaci a nároky na RAM. Musím říct, že to není tak strašný. Navíc ZFS kdykoliv RAM ochotně uvolní. A dokáže to někdy doslova zázraky. Nicméně ne vždy je to ideální. Kdo zálohuje také například qcow2, ten radši bude deduplikovat přímo na vrstvě zálohovacího programu (já používám BorgBackup). Nicméně otevřeně přiznávám, že tomu prd rozumím a experimentuji stylem pokus / omyl. Ještě jednou díky za článek! Jo a mimochodem díky ZFS jsem se začal zajímat také o FreeBSD.

Naroky na RAM. Ano ECC. V Sunu nikdo nepredpokladal ze to bude nekdo provozovat na consumer HW. Treba rpi4 uz ma interni ECC ale o chybach se nedozvite a to je sice lepsi nez bez ECC. ale o velkem problemu s RAM se nedozvite - napr pri prehrivani / problem s napajenim (protoze raspberry a "silnoproudi inzenyri" ) kdy zacne masivne chybovat prenos ci cip.

ECC nutné není a co se týče nároků na RAM omezující to mohlo být tak před deseti lety, pokud nemáte puštěnou deduplikaci. Ale pravda je, že pro rpi4 může být jiný souborový systém vhodnější.
Pokud dělá RAM potíže, dojedete na to s jiným souborovým systémem, který si toho dost možná ani nevšimne.

Chcte prijit o data ? poridte si ZFS - a hnako bonus vam nenabyzi zadne oprtavne nastroje, Estonci jej nasazovali a ja vse zezalohoval a smazal - do jednoho a jako architekt zakazal.

Dale jsme nasadil posledni verzi ZFS a ukazal jsme, jak znicim masivnim I/O data - testujeme vypnuti elektriny, pad OS atd. - a pak jsem rekl, ze pokud poskozeny ZFS - testovano na dikovem poli HPE Primera - FC !!! takze zadne lokalni disky - Primeru jsme samozrejme nevypinal, jen server pres ILO - hard power OFF

Krom toho, ze me ZFS zcenruiovali a tvrdili, ze jakozto spickovy NetApp specialista jsme deb*** nebo jsme pozadoval, aby sel expandovat ZRAID - pry to niko nema, tak jsme jim rekl, ze to naopka z enterprise maji dnes vsichni - treba Netapp u svych Raid grup, SW_RAID - nakonec to nedavno dodali, aha takze to byl dobry napad to pozadovat ze ? - a tez jsme chtel oprvany naztroj, pry se ZFS nikdy nepokazi ;-) tak urcite.

ZFS nic neumi, uz nejak resili dedupliaci, aby to nezralo RAM, ale co ja vim, me ZFS moc nezjima, deduplaci proste predtim nemel, ja spravji desitky PB - kdyby NetApp zral RAM jakjo ZFS na deduplaci, tak potrebuji 100TB RAM - LOL

Dale kenrel 7.2 a hlavne 7.3 plne ipomlementoval Large Folios - pouzitelne to zacaslo byt v kernel 6.12+ - ale uplna revolucie proi BTRFS je 7.2 a hlavne 7.3 - kde predelali i IO_scheduler ... cili BTRFS je dnes brutalne rychly - jako RAID chci SW_RAID nebo LVM - ten umi raid taky ...

Mimochodem SW_RAD large folios pouziva taky - umi jej vubec ZFS - kdyz pro Linux oficilane vubec neni a je to port ze zastaralých Unixu ?

Cos e tyce refl;inku, snapshoptu, replikaci a nakonec i reduplikaci,. je BTRFS vyrazne lepsi - skoda ze neumi SSD cache - coz lze na linuxu udelat jinak, ja bych chtel jen RO_SSD - na linuxu to ovsem znemanea smazat data - BTRFS to neumi, umi jen pridat treba 2 SSD v mirroru ale jsou pak RW - tedy pri vypadku odejdou data ... ale vyresil jsme to ;-) mam 64GB RAM v NAS a tak jsme upravil linux tak, aby delal lazy mazani a drzel tam data jak jen muze - a zvetsil jsme RW cache v RAM a velkou RO RAM cache - dost to na 10Gb pomohlo ... ted jedu na kernelu 7.2 a cekam na 7.3 - ale BTRFS se zrychlil brutalne, dostal mega patche, aby pouzival Large folios - kdyz to FS nema a neni na to prepsany, tak je nevyuzivate a zabijite CPU kupou 4kb bloku a hlavne indexem ktery to peklo zpravuje, mi to udela treba 64MB blok a je to pak jena polozka v indexu .... Large Folios je dynamicka vec a je to jako Huge Mem v Oracle, ale Oracle uz LargeFolio zacal posuzovat, jen na to ma svuj subsytem pro aplikace, pro DB a indexy + cache ma stale statcike HuigePage, na apliakce, triggery a veco kolem uz ma dynamicke a funguje to az od kernelu 6.12 a s novymi Oracle ... proto musite mit min Oracle Linux 9 UEK8 (kde je prave unbreakable kernel 6.12) a nebo 10 ...

Takze za me ZFS nebrat, je to smjed, prijdete o data - a videl jsme nekolik firem co po me pak chteli, abych jim to opravil a ja jkim rekl, ze jsou pozde, ze to nejde, tedy ze obnova ze zalohy a uz to svinstvo nemaji nasazovat - a zkousel jsme i Solaris a jeho hracku ala opravny nastroj, prtoste rekne ze je vazdny a nepomouze nic, je par metod, jak se o to pokusit, ale nefunguje zadna, jedna se neco zahodi, nevim zda jsournal, nebo indexy - prste me to nezajima - a na rozdil od doby, kde me jakzosto spickove odbornika zablokovali, kdyz jsme jim rikla dobre napady z WaflFS a co pouzivam - to prosim zadarmo, Cinani mi platili 10k euro/ mesic za migraci netappu z Cluster mode na MetroCluster ... no tak v ZFS poiprve priznali, ze ten FS je smejd a ze se teda fakt kazi - LOL kolik let pote, co jsme jim to rikal ? UTFG kde to rikaji a kde vam rikaji, ze to mate smazat, onbovit ze zalohy ;-)) + 3 pokusy, jak to opravit - vetsinou vam, nepomuze zadny.

A co ja se naoppravoval XFS kde bylo potreba smazat journal, to same ext3 nebo ext4 s naborenym journalem, dokonce cerla struktura pro journal byla vadan a bylo treba ji smazat a delal to 30 minut (jinak FS zamrzl pri kazdych novych datech ) - ja opravdu vzkrilil FS z vsemoznych stavu ....

BTW ja uz krisli raid5 kde odesly 2 disky a byly vadne bloky, vadna serie disku SEAGATE - jeden byl mrtvy a druhy mel asi 100 vadnych bloku - dodal jsme novy WD RED a dal sync - a prekocil ty vadne ploky, SW raid je chytyry, kdyby prisle o disk, tak se snazi udelat maximum, pak oprava - zajimave vec, data byly 100% v poradku ale poskozena byla prave prazdna struktura ... ale to jsou m,el veci, na NetAppu se mi takove veci nikdy nestaly ... btw i NetApp ma opravnou utilitu na wafl !!!! jen ji ma k dispozici jen support - ale nebyla nikdy potreba - kolega zazil, ze se jednou sama spustila po padu - netapp pak opravoval data nekolik hodin ;-))) to ja nikdy nevidel a to jsme resil veci jako kahuna a disk consistency sync a daval tak pomale disky na jednu hlavu a rychle na druhou.

BTW proti lidem z ZFS nic nemam, tomu ze me zabanovali se dodnes smejsi, nebot jak se ukazlo, vubec nerozumi FS a o nasazeni v enterprise - na rozdil od lidi z BRTFS je nezajima, ze umim nasimulovat zhrouceni ZFS ;-) naposledy jsem to pro filmu delal minuly rok - kdyz jsme testovali vsemozne virtualizace, a musely projit firemnim standardem - ukazoval jsme na to PROXMOX - a do zparvy jsme dal FS co maji zakazano nasazovat. Jen ro davam rad k doby, ze tahle arogantni komunita na napady reguje tak, ze nerousmim entreprise ze to nikod nema a kdyz jsme treda rekl ze treba NetApp ? a ze spise neznam moc enterprise reseni, ktere to nemaji ... zjimalo by me, kolik storage epxertu z enterpsie tridy takhle zabanovali ;-)) a prisli tak od nazor a rady od lidi, kterym plati firmy nemale penize a maji obrovske zkusenosti se spavou dat i se vsemoznymi FS.

BTW diky tomu, ze BTRFS byl dost zpomalovan tak tam kde neni potreba komprese a dedupliace pouzivame XFS (umi reflink i deduplika pouziva to VEEAM - mem nekolik nodu destiky PB zaloh ) nekde ext4 ... ale jak Infinidat, Netapp tak i HPE Primera umi inline kopresi a deduplikaci (ibox jen kompresi) - a ent. RedHat BTRFS nepodporuje, Oracle Linux jej umi ... a Veem je sifrovany, takze by deduplikovat a komprese nesla, Veeam tak musi data zkomprimovat a deduplikovat na proxy a zasifrovane se pak zapisi jiz zkomprimovane a deduplikovane - sifrovane data nejde ani komprimovat, ani deduplikovat - proto tam mame vice levnejich FC poli pro bakcup co tyhle veci vubec neumi.

Takze pokud chcte prijit o data, pouzivejte ZFS - zvlaste vas support ala RedHat ci OracleLinux tas pak posle nekam ;-) a vendor pole ci serveru taky - no lidi co delaji support pr pro filrmy v situacih, kdi si HPE/IBM/DELL atd nevbi rady - TAKY nebot uz s tim maji bohate zkusenosti a reknou vam, ze pokud jste zkusili ty 3 metdoy, tak ze vam ustri penize za cas darheo odbornika a radeji vam pom,uze s disaster recovery ze zaloh ;-))

Já bych pokažený ZFS souborový systém rozhodně neopravoval. Podobně jako bych neopravoval rozbitou innodb databázi. ZFS jsem rozbitý ještě neviděl, ale stát se může vše. Když nějaký problém se strojem - jakýkoli, prostě všechny věci spustím na záložním stroji, kam se zálohují i všechna data. ZFS SEND každých pět minut. Pak mohu přijít o změny maximálně za posledních 5 minut.
Databáze se zálohují okamžitě pomocí Master -> Slave replikací. V případě problému mohu udělat Master z nějakého Slave a o žádná data nepřijdu.

Ale pokud se někdo specializuje na diskové pole a souborové systémy, určitě má spoustu možností tohle všechno řešit nějak složitěji. A možná i lépe.
Ale celkově té potřebě mít obrovské diskové pole s kterým vše padá nechápu. Raději data rozdělím na více serverů, které pak mohou zálohovat jeden druhého, bez nutnosti obnovovat něco ze zálohy.
Když jsem s tím začínal byl Btrfs ještě děravý jak řešeto. A nyní nemám důvod ZFS opouštět. Kdybych znovu začínal nyní, byla by situace možná trochu jiná.

A hlavní argument, proč si instalaci neulehčit použitím Btrfs není moc platný, neb pokud chci používat Btrfs a všechny jeho výhody a zároveň Debian, nelze moc mluvit o tom, že by situace byla celkově v Debianu jednodušší, než pokud použiji ZFS. Instalovat systém pomocí debootstrap není žádná raketová věda.

Panové, přiznám, že vaše příspěvky "nejdou pročíst" všechny, pardon, ALE napadlo vás, že ZFS může být z principu špatný nápad ho provozovat na komplexních RAID+FC hardwarech ?
Začal bych čtením zde:
https://openzfs.github.io/openzfs-docs/Performance%20and%20Tuning/Hardware.html#hardware-raid-controllers
a pak se pídit dál.

IMHO, také BTRFS bude mít svoje principy implementace, které mohou v jistých HW konfiguracích diskového podvozku narazit, a tedy píditi se pak i směrem k BTRFS považuji za rozumé.

Peklo pro složitější typy FS začíná v momentě, kdy mu diskový subsystém = HW/ovladače nedokážou zaručit, že nějaký jeho jisto-jistě zapsaný blok (metadato/žur­nál/log/ apod.) byl skutečně zapsán a to často i v pořadí v jakém měl.

Nehledě na FS, příklady problémů začínají už s NCQ na obyč SATA discích. Kde buďto funguje FUA/DPO/apod. nebo ne. A je na zvážení vypnout write-back.

Zkoušel jsem předělat Blade servery se sdíleným řadičem + DAS -- prostě z konfigurace vhodné VMwaru na PROXMOX. Jak jinak :-)
Tak ten sdílený řadič jsem vzdal a lokální RAIDy v bladech snad půjdou přepnout do HBA. Čímž vznikne lokální ZFS mirror v každé žiletce a abych zajistil, že mi do těch ZFS nebudou lokální HBA kecat (jsou příliš chytré) zkusím extra PCIe karty do každé žiletky pro SLOG (tedy synchronní data půjdou nejkratší cestou do dvou disků zperzistentnit). Přiznám, ještě to je WIP, ale chtěl bych využít navíc funkcí ZFS oproti (default) LVM pro ten PROXMOX resp. práce s VM disky.

Někdo tady zmiňoval innodb ... Máte někdo pls z praxe zkušenost, že obnovy SQL databází po pádu diskového subsystému jsou bezpečnější/ús­pěšnější, když jsou na COW FS ?

Ještě na téma ZFS versus Brtfs.
Když porovnám co je napsáno o obojím na debianní wiki.

https://wiki.debian.org/ZFS
https://wiki.debian.org/Btrfs

Tak ZFS prostě funguje ale Btrfs má spoustu známých případů, kdy nemusí fungovat dobře. No pravda je, že část těch informací o možných potížích může být již zastaralá a už to může být částečně nebo zcela vyřešeno. Nicméně stále to nepůsobí pro Btrfs moc dobře. Btrfs působí jako dodělej si sám a vyhni se všem možným bugům.