Názory k článku Konverze Debianu ze souborového systému EXT4 na moderní ZFS

Navod hezky, ocenuji. Ale nebylo by lepsi poskytovatele vps co neumi pripojit vlastni iso vymenit nez se 2 hodiny prcat s konverzi ext4 na zfs? Nebo jej slusne pozadat o iso ktere umoznuje zfs u instalace?Kdyz si predstavim ze tech vps tam budu mit 20…

No ale já 20 VPS dělat nemusím... takže jsem chtěl něco, co bude fungovat skoro určitě u každého poskytovatele, aniž bych se zabýval jeho specifickým interfacem pro připojení ISO či konzoli.
Kdybych tohle musel řešit pro více strojů, tak by se jistě vyplatilo si udělat šablonu např. s cloud-init.

Mimochodem, jak je na videu vidět, tak konverzi lze provést podle návodu poměrně rychle (40 minut i v tom poměrně ad-hoc videu), když se zrovna neuklepnete, jako já na konci videa (což opravuji/ vysvětluji v následném videu).

V “Rescue” mode je mozne pouzit vlastni ISO s pomoci KVM, na virtualce to bude pomalejsi, ale odpadne tim dodatecny krok, viz: https://community.hetzner.com/tutorials/proxmox-docker-zfs

Navic davat ZFS do VM kde nevime jak vypada storage overlay a navic nemame primy pristup k HW (diskum), mi prijde jako blbost. ZFS ma proste rado, kdyz si sahne primo na disky, jakakoliv RAID karta na ceste a virtualizovany storage muze zpusobit dost problemu. Na hrani popr. na ukazku dobry, ale urco bych to ve VM nepouzival na “real work”, ani na dev prostredi.

Ano, je lepší mít ZFS na fyzickém hardwaru bez RAID řadičů (resp. někdy je lze přeflashovat do tzv. IT/ HBA módu), ale pro snapshoty je to pořád velmi dobré řešení. Konkrétně u Hetznera to běží s minimální řežií na NVMe SSD.

Já právě nechtěl žádný rescue apod. řešit. Na řadě míst (třeba když Vám zákazník dá jen SSH na virtuálku) prostě takové možnosti nemáte. I tam s tímto návodem můžete mít ZFS a nemusíte se se zákazníkem dohadovat, aby Vám to nějak zařídil.

Článek se týká virtuálu, ale má někdo zkušenosti s provozem linuxu s kořenovým ZFS přímo na železe, např. přes EFI loader ZFSBootMenu? Používám jej, funguje výborně (zatím), ale je to přeci jen dost "tlustý" loader. Hlavně mi jde o zkušenosti s recovery/přesunem na jiný HW atd. Díky.

ZFSBootMenu využívám a přijde mi šikovné - na ZFS mám plno různých distribucí na hraní/pokusy. ZFSBootMenu bootuje rychle a umí pracovat se ZFS - prohlížet, snapshoty, klony, chroot, atd.. - to jsou někdy užitečné funkce, tak jsem za tuto "tloušťku" rád ;-)

ZFS 2.2.0 je aktuálně RC4, v článku odkazuje na RC1.

Usuzuji z toho, že root má hodně článků v zásobě a tenhle čekal na vydání více jak měsíc ;-)

K samotnému ZFS a článku:

1. ZFS v jádře není kvůli licenci, která je s jádrem neslučitelná - škoda že to není v článku zmíněné ... pro náhodné kolemjdoucí to může vyvolat dojem, že ZFS není dostatečně kvalitní, aby bylo do jádra zařazeno. Zde pro pobavení: github

2. ZFS má samo o sobě docela dost nároků a vzhledem k tomu jak je článek koncipován si dovolím doplnit: pokud máte VPS s jedním jádrem a 4GB RAM, tak na ZFS rovnou zapomeňte ... ano fungovat to bude, ale nelze od toho čekat lepší výkon. V tomto setupu lze čekat jediné ... problémy. Ze zkušenosti ... pokud to má dělat ještě něco jiného než obsluhovat ten filesystém, tak takový základ jsou 4 jádra a 8GB RAM.

3. ZFS je skvělý filesystém, ale je také hodně složitý ... pokud člověk narazí na nějaký problém, tak je potřeba tomu rozumět. Pool i každý dataset mají spoustu nastavení a vedle toho všeho tu je více jak 300 parametrů modulu jádra, kterými lze ovlivnit výkon a chování filesystému.

4. Jediná opravdová výhrada k článku ... nevidím důvod proč bootovat ze ZFS. Je s tím spousta práce, komplikací a nic to reálně nepřinese. Je to hezké jako akademické cvičení, že to jde ... ale to je tak vše. Grub ze ZFS umí nabootovat, ale je dost pozadu proti vývoji ZFS, proto je potřeba si dávat sakra pozor, jaké features jsou na bootovacím poolu zapnuté. Stačí zapnout jednu co grub neumí a už to nenabootuje. Takže když člověk například udělá aktualizaci ZFS a v euforii že to funguje si tohle neuvědomí, tak snadno spustí zpool upgrade i nad bootovacím poolem ... a pak bude smutně koukat na nebootující systém.

Děkuji za hezký článek

Je to první článek autora tady, tak je pravděpodobné, že došlo k nějakému zpoždění než se to vyladilo.

ten jeden z mála důvodů proč bootovat ze zfs může být třeba potřeba držet konzistenci i bootovacího oddílu, snapshoty, kontrola integrity atd.

Ano, byla tam prodleva skoro 1,5 měsíce. Naštěstí nedošlo k zásadní změně, takže linky jsou snad dostatečně směrodatné.

Díky za feedback, snad je to užitečné i pro zkušené mazáky, třeba i jen jako reference, nebo příklad jiného pohledu.

Ad 1: Ano, možná to tak může působit. Tento článek neměl být dalším seriálem o ZFS, ten už na rootu je a čtenář si jej může přečíst včetně zmínky o licenční problematice. Na seriál odkazuji doslova v první větě článku.

Ad 2: ZFS lze používat i s méně než 2 GB RAM, když se vhodně nastaví a ano, úplně šťastné to asi nebude. Zde je použita VM se 2 vCPU a 4 GB RAM, kterou lze třeba post-hoc zvětšit.

Ad 3: Ano, zmiňuji to v motivaci hned na začátku článku. Na druhou stranu článek, řekl bych, slušně mapuje dostatečnou podmnožinu pro značnou část použití.

Ad 4: Proto je bpool specificky nakonfigurovaný s podmnožinou vlastností. Je to prostě opsané z oficiálního návodu, na který se odkazuji. Idea je, že prostě recykluji znalosti.

(seriál o ZFS) už na rootu je a čtenář si jej může přečíst ... Na seriál odkazuji doslova v první větě článku.

v ZFS sa nevyznám, tak sa chcem opýtať - ten seriál je z roku 2011. Nakoľko sú informácie v ňom stále aktuálne aj dnes?

Nevím, co úplně čekáte, že napíšu. Úplné základy z uživatelského hlediska jsou prakticky stejné. ZFS mezitím umí novější kompresní algoritmy, umí šifrovat a TRIM. Vedle snapshotů existují ještě bookmarks, které umožňují uvolnit místo vázané snapshotem, ale přesto využít inkrementálních záloh za cenu vyšších nároků na IOPS.

Kdyby Vás ZFS zajímal víc, zkuste mrknout do příručky FreeBSD: https://docs.freebsd.org/en/books/handbook/zfs/ nebo si kupte knihy Michaela W Lucase: https://mwl.io/nonfiction/os#fmzfs

Moje zkušenost je takové, že pokud má databáze hodně práce, může být lepší to ZFS nedávat, mnohonásobně to urychlí chod a ušetří to též životnost SSD disků, kterým to v případě databáze kde se často mění jen pár bytů, moc nesvědčí. Databázi clonuji na další stroj a udělat si zálohu nějakého clonu, které je možné dočasně pozdržet (i clonovanou databázi vypnout) není problém..

moje zkušenost je zase takové, že rád obětuji trochu výkonu za cenu daleko vyšší spolehlivosti.

Enterprise SSD nám umírají strašně málo, i ty pod databázemi.

ZFS ale není jednoduchý systém, i výkon pro databáze lze dobře vyladit a je potřeba se rozhodnout, jestli chceš ten čas do toho investovat nebo nikoliv.

Máme také několik velký společností, které provozují rozsáhlé databáze nad ZFS. Máme tady ale o dost více společností, kteří si na tom vylámaly zuby.

ZFS má velkou výhodu v tom, že i na storage, který má pomalé IO můžu dělat poměrně levně zálohy pomocí snapshotů aniž bych musel všechno procházet a podívat se, co se změnilo, což je výkonnostně mnohem náročnější než případných konstantních pár procent, které mi evtl. ZFS přidá. Pro nás je to v podstatě čistá a zcela zřejmá výhra. I mentálním modelem je to mnohem blíž Clojure s perzistentními datovými strukturami, než klasické souborové systémy.

Jak to vidíte? Já myslím, že nastíněný tuning PostgreSQL + ZFS bude drtivé většině firem na provoz stačit. Tam, kde to nestačí budou asi mít i na klasickém setupu dost starostí, takže je to o tom, které starosti chtějí mít radši/ co je bolí víc. Storage obecně je hodně těžká kategorie a žádné řešení nebude vyhovovat všem, ale myslím si, že kompromisy, které dělá ZFS může řadě adminům v dlouhodobém horizontu vyhovovat víc. Ano, vyžaduje to určité znalosti.

Neumi snapshoty i nektere databaze na aplikacni urovni? Neumi snapshoty i storage? Neumi snapshoty i jine filesystemy / volume managery. Jako byvaly Sunak jsem sice ZFS postizeny od jeho neverejnych pocatku, nicmene k objektivite je nutno dodat ze ne vzdy se vyplaci mit snapshoty az na urovni filesystemu a upinat se na jedno reseni.

Zrovna optimalizace ZFS na databaze byl diky komplexite ruznych db vrstev docela orisek. Zde jsme zrovna razili filozofii ze cim mensi overhead tim lepe. Takze bud uplne hloupy FS nebo idealne databaze dostane blokove zarizeni a resi mi tam svuj pisecek plne ve vlastni rezii. Stejne ma DB sve interni schema ulozeni informaci - cili vlastne specializovany filesystem.

Naprostý souhlas. Jestli ZFS použít i na databázi s hodně zápisy a updaty je otázka. Pro mnoho použíti může být jednodušší se ZFS vyhnout. Stejně je totiž nutné řešit zálohování i na úrovni databáze a ZFS k tomu nutně nepotřebujeme. Snapshot jde vytvořit i jinak než díky ZFS a overhead může být výrazně nižší.

Snapshot umí ledacos, problém ale bývá to dělat za běhu databáze, na to si často vylámeš zuby.

Databáze to často umí (Pg, ORA atd.), ale není to zrovna zero cost. Mohu použít transakční logy, jejich obnova je ale časově poměrně náročná znamená zpracovat transakci po transakci (což trvá klidně i hodiny na hodně silném HW), u ZFS to máme zadarmo a můžeme hned vedle spustit na readonly snapshotem databáze a koukat na data.

Enterprise diskové pole umí snapshoty, většinou, ale opět ne vždy jsou zero cost, ne vždy je možné je dělat na zaběhu a cenově to je občas dost vysoko.

Poměrně dlouho jsme používali u rýzných klientů takovou tu architekturu, že máme replikovaný SAN přes FC, nad tím Oracle RAC. Vše dost těžkopádné, obnovy znamenaly zalarmovat půlku firmy a čekat hodiny. Roční náklady 5M. Pokud něco běželo na single serveru, tak mirror raid přes řadič a hot swap disky, výkon pro random iops je ale žalostný, při degradace máme data na jediném disku, nic moc.

Dnes ale výkon jednotlivých serverů tak extrémně pokročil, že moderní nvme disky ani pod řadič nedáme a musíme to řešit přes SW. ZFS je zajímavá volba, můžeme mít asychronně replikovanou Pg databázi s vysokým iops výkonem nad jediným server s 3 mirror disky a k tomu ještě zero cost snapshoty a schopnost se kdykoliv koukat do historie jako do knihy. Líbí se mi to jako alternative k drahým enterprise řešením, ale náklady na počáteční vývoj jsou relativně vysoké, není to pro každého.

Tak třeba PostgreSQL s blokovým zařízením pracovat neumí a i u Oracle se pokud vím doporučuje použít XFS.

Mě přijde, že do určité velikosti ta režie ZFS lze značně snížit základním nastavením, které je zmíněné v článku. Jsou i další nastavení, ale ta asi budou potřeba až na hodně velká či jinak vybočující nasazení databáze.

Každopádně se zdá, že O_DIRECT je na dohled: https://github.com/openzfs/zfs/pull/10018

Úplně hloupý FS (EXT4) s hloupým RAID (mdadm) neřeší konzistenci dat. Při velkých nasazeních tohle reálně potřeba řešit je. Takže se to bude flikovat na nějaké vyšší úrovni s možná ještě větší režií.
XFS snad umí metadata checksums, takže aspoň něco. Taky existuje dm-integrity. https://www.redhat.com/en/blog/what-bit-rot-and-how-can-i-detect-it-rhel
Ale ZFS má integritu dat řešenou od začátku by default a má k tomu zabudované nástroje a automatiky, které usnadňují správu toho všeho. Jestli si dobře vzpomínám na nějakou přednášku, tak pro LLNL je lepší udržovat ZFS on Linux, než používat původní řešení - náklady na údržbu a hledání chyb byly výrazně větší. Zdá se, že jim ZFS přijde pro jejich účely jako jedno z nejlepších řešení. I jiným, zdá se, nasazení ZFS vyhovuje: https://klarasystems.com/articles/openzfs-openzfs-for-hpc-clusters/

Nebavím se o velikosti databáze, ale zatížení a hlavně množství zápisů, které je se ZFS problémovější. Pokud je v databázi např. účetnictví, tak je ZFS jistě OK. Ale pokud to sbírá a vyhodnocuje nějaká velká data, kterých když se pár poztrácí, nic se nestane, tak je lepší se ZFS vyhnout. Bude to několikanásobně rychlejší a SSD disk se několikanásobně méně bude opotřebovávat. A to i při všech známých optimalizacích.

Nebavím se o "trochu výkonu" ale násobcích.

V našem případě to ZFS vyladit nešlo, všechny běžné poučky měly jen relativně malý vliv, zapsaných dat bylo nesmyslně mnoho. Jednoznačně pomohlo se ZFS zbavit. Používáme ZFS ale na vše ostatní.

19. 9. 2023, 12:39 editováno autorem komentáře

Zde je možné, že některé z posledních úprav přímo v kódu ZFS můžou pomoct. Musel bych vědět mnohem víc (hardware, zátěž, nastavení), abych se k tomu byl schopen vyjádřit, takhle je to bohužel jen informace, kterou si přečtu, ale žádné velké poučení nebo vhled z toho neplyne. ---\__o__/---

Podrobnosti jsou zde https://forum.root.cz/index.php?topic=26555.0

Netradiční je používání myisam. Ale zkoušeli jsme inodb a také to byla mizérie.
Jedno použití je sbírat všechny signalizace pakety VoIP provozu pro případné řešení problémů. Pokud by se měl ztratit jeden zápis z milionu v podstatě to vůbec nevadí.

"běžné poučky", to bude asi ten problém. Těch zdrojů na internetu a v poučkáš moc není. My si zkušenosti předáváme mezi sebou a drží se u projektů.

Asi nejlépe to popsali na blogu lets encrypt před pár lety (mimochodem mariadb pod lets encrypt běží nad zfs).

K ladění ZFS je často potřeba se podívat do kódu, pročíst si podrobně man pages, udělat si nějaké flame grafy a lépe problém analyzovat. To je i důvod proč ZFS nelze obecně doporučit, je to těžká technologie.

U nás nad ZFS má jeden z operátorů OLTP databázi v Pg, což jsou desítky tisíc zápisů každou vteřinu ve špičce.

19. 9. 2023, 16:35 editováno autorem komentáře

Bylo to pouziti jako ssd write cache nebo primarni ssd? Nezkouseli jste vyhradit na write cache SSD s vetsim poctem zapisu/levne SSD?

Asi jsem v tomhle "brutus", ale pokud potrebuji nasobne vyssi vykon na zapisy/cteni tak to nechavam na "all-in-memory" s tim ze obsah je nekde nareplikovany na konkurencni nod(y). No a z nich se delaji semtam snapshoty. Objemove mezi desitkami TB az stovkou.

No koneckoncu nevim nic o profilu loadu tak muzu byt taky mimo pisoar... Specificke potreby maji treba strizny, zpracovani videi ci odbavovaci pracoviste.

Fatalny problem z FS som zazil len zo ZFS.

Povodny admin nasluboval zo ZFS zazraky ale zabodol sa zmienit o nutnosti mat minimalne 10% kapacity ako vatu.

A je velmy tazke presvedcovat ze potrebujes novu policu a disky ked mas este 20% volnej kapacity. (Cas kedy zacinaju problemy).

Toto je obecná vlastnost asi všech COW filesystémů. Když se podíváte do dokumentace Netappu a jejich WAFL, tak narazíte na nápadně podobné informace.

Otázkou je, zda je chyba minulého admina, že Vám o tom neřekl. Nebo Vaše, že jste pak dál provozoval technologii o které nic nevíte.

To je moc hezká teorie, dokonce s malou a hlavně zbytečnou urážkou na konci, ale hádám, že tohle nebude pole o dvou discích a na takových nemusí úplně snadné ani ekonomické měnit filesystém, zvlášť když jsou z 80 % obsazené.

Ale nie vsetky maju tak katastroficky dopad ked im kapacita dochadza. (IBM storwize/IBM SVC) Ale to sa bavime o triedu lepsej lige ako je Netapp.

Ad posledny odstavec.
Som zvedavy ako presvedcite nadriadenich ze riesenie naraza na svoje limity ked predchadzajuceho admina mali za poloboha.

Skor typujem ze su to len silne reci maleho chlapa. Ktory nikdy nic podobne riesit nemusel.

Ke konci článku nastiňuji triky, jak se možná dostat na úplně jiný řád výkonu, který si prostě s klasickým mutabilním souborovým systémem nikdo netroufne nastavit, protože by to bylo naprosto šílené.
Paradoxně může být ZFS k SSD např. díky kompresi šetrnější. Protože jestli data přepisuji in-situ nebo kopíruji bokem by mělo být z hlediska wear levelingu celkem jedno resp. případně i lepší, protože přirozeně rozkládám zátěž do plochy.

ZFS má ze své podstaty jinak hodně slušné možnosti za běhu SSD vyměnit, pokud používám např. mirroring. Díky snaphostům a inkrementální replikaci můžu lépe a rychleji zálohovat na druhý stroj a zkrátit dobu obnovy v případě havárie.

Mohu rici z praxe ze komprese se hodila v momente kdy bylo zfs provozovano na konfiguraci kde bylo uzke hrdlo storage sit. Tim ze prenasena data byla pomerne dobre komprimovatelna, doslo ke zvyseni vykonu temer o rad. Bylo levnejsi mit vykonnejsi zelezo nez momentalne(v kratkodobem horizontu) upgradovat slozite storage cesty pred dve patra DC za devatero FC switchi a devatero racky...
Ne vzdy se to ale hodi. Zalezi od aplikace Jednak clovek taha nejaky overhead na noze dalsi vec je ze se zvysi latence takze na near-realtime ulohy to neni moc vhodne.

20. 9. 2023, 14:02 editováno autorem komentáře

Trošku to tu latenci může zvýšit, ale u menších bloků a LZ4 to asi nebude nějaká tragédie. Případně lze kompresi i vypnout a nebo komprimovat jen souvislé nuly.

Jinak ohledně sítí a jejich upgradů je to občas složité. Někdy si lze poměrně dobře pomoct např. pár kanály CWDM, což je častokrát levnější než tahat v provozu více vláken.

Jinak, napište mi prosím, ať si vyměníme kontakt (viz můj profil).

Zde hodně záleží na tom, co to je za datábázi a s čím má "hodně práce". Jsem stará škola a ZFS jsem se dlouho bál. Zkušenosti ale ukazují, že se správným nastavením lze u databází obecně docílit stavu, kdy je výkon minimálně stejný jako s konvenčním filesystémem, ale často o mnoho lepší.

Pro takový scénář ale musíte mít i dostatek systémových zdrojů a znamená to jak věnovat čas nastavení ZFS, tak upravit vhodně nastavení databáze. Pokud vezmete běžící databázi a zcela bez úprav ji přesunete na ZFS v defaultu, tak nejpravděpodobnější scénář bude horší performance.

S životností SSD lze v principu souhlasit ... double write má prostě režii a disky opotřebovává víc. Pokud nad takovým filesystémem pustím databázi co také dělá double write, tak tím životnost disku snižuji. Někdy to lze řešit konfiguračně a někdy nikoliv ... nicméně za sebe jsem názoru, že pro daný usecase použiju vhodný HW místo abych upravoval pro HW co mam vše okolo. Takže pokud chci používat na ZFS obecně cokoliv co dělá hodně zápisových operací, tak si na to pořídím disky co to dlouhodobě umožní.

Vyborne, dekujeme za sdileni zkusenosti.

Doplnujici otazka - jak se ZFS srovnava s BTRFS ? Jsou napriklad (technologicke) duvody pro to prejit na ZFS z BTRFS?

Co jsem vyrozuměl, má btrfs pořád problém s konzistencí výkonu a spolehlivostí. Některé vývojáře ZFS znám osobně a zdá se mi, že mají hodně podobný hodnotový systém, co se týče očekávání na souborový systém. Ale dál jsem se btrfs nezabýval, srovnání nechám na Vaši rešerši, případně jiné komentátory, kteří o tom ví víc.

I zde se da v historii najit hned nekolik zazitku prave na tema ZFS a totalne neopravitelne rozpadly fs, coz se kupodivu pres vsechny problemy ktere ma btrfs jeho uzivatelum nedeje.

Nemluve o tom, ze zfs je i koncepce proste zastarala technologie (trebas raidgrupy ...)

Z me vlastni zkusenoti pak chovani btrfs do znacne miry zavisi na ficurach, ktere se uzivatel rozhodne pouzivat - tedy predevsim tech, ktere jine fs neumi. Z tech problemu ktere bych zminil, tu je pomerne nemile chovani v pripade, ze obsazenost vyhrazeneho prostoru presahne nejakou (ficurove zavislou) mez. V extremnim pripade napriklad nelze smazat soubor, protoze neni misto. Ne ze by se to nedalo vyresit, ale clovek by nejak cekal, ze i 100% zaplneny fs je stale i 100% funkcni a pokud fs potrebuje nejake misto pro nejake akce, tak si jej ma vyhradit.

Možná jste nám mohl ušetřit hledání a poskytnout aspoň jeden odkaz na "totalne neopravitelne rozpadly fs".

Nejsem si jistý, co myslíte "raidgrupami".

Vazne ti nebudu delat archeologa, kdyz nevis, ze ZFS neumi pridat jeden disk, musis pridat jeden raid = grupu, skupinu disku. Narozdil od btrfs, kde se proste prida dalsi jeden disk a raid se roztahne i pres nej.

Tohle je postup z minuleho tisicileti.

Mimochodem, tahle schopnost dava btrfs pomerne zajimavou vlastnost - muze odpadnou (postupne) tolik disku, kolik je volneho mista + raid.

A pak je tu jeste jedna vlastnost kterou btrfs mozna ziska a ktera s tim souvisi (nejake patche na to tema tam uz jsou) a to je tiered storage. Pro ty co netusi to obnasi to, ze pole pak samo distribuuje data pres ruzne typy disku (ssd/hdd/...) podle toho zda se casto prepisuji, ctou, nebo tam jen tak smrdi.

Poslední problémy s konzistencí jsem snad zaznamenal kolem roku 2014 (raid 5 v podání btrfs je ale pořád problém).

Btrfs se každý bojí, to je asi jeho zásadní problém. Proti ZFS nemá journaling a nemůžeš z něho bootovat. Na databáze a vysoké iops je ale problematický, krátký test můžeš vidět u percony (https://www.percona.com/blog/taking-a-look-at-btrfs-for-mysql/), osobně jsem nikde neviděl btrfs vyladěné a použité pro databázi.

Naopak brtfs poměrně rádi používáme na malé stroje, má velice (proti zfs) malé nároky na cpu a paměť, umí snapshoty, auto healing, replikace.

Na FreeBSD mám všude ZFS, samozřejmě, ale v Linuxu… Proč? Btrfs je přímo v kernelu. Žádná oddělená kompilace kvůli CDDL, žádné podivné mezivrstvy, žádné C89 archaismy všude. Btrfs dnes není o nic méně desetiletími prověřený a „stabilní“ (ať už to má znamenat cokoliv) filesystém než ZFS. Rozumná distra typu Fedora nebo openSUSE mají (z dobrých důvodů) Btrfs jako implicitní volbu. (Debian je zase pozadu, jako vždy.)

Kolem kapitoly Motivace chybí další klíčová kapitola, které se v akademickém psaní říká Related Work. (Název mate; ve skutečnosti má kapitola Related Work ukázat, proč je zdánlivě související dílo zcela nesouvisející a proč tedy příslušný článek má svůj přínos a smysl.) Bez této kapitoly (a bez odpovědi na zjevnou otázku „proč ne Btrfs“) to celé sice vypadá jako zajímavá hříčka pro zábavu, ale o moc víc v tom nevidím. V praxi chci mít Btrfs, který mám vždy automaticky v každém kernelu.

Klíčová výhoda ZFS proti Btrfs tady není zmíněná (a asi ani využitá): hierarchie subvolumes, která umožňuje atomicitu snapshotů přes celé podstromy subvolumes, ne přes jediný subvolume. To je asi tak jediná věc, která mi v Btrfs citelně chybí, v kontrastu se ZFS. (A tak mám hloupější zálohovací skripty, než bych mohl mít, no co už.)

Myslím, že cílem tohoto článku nebylo OpenZFS uvést a jeho použití obhájit, to snad řeší např. odkazovaný seriál. Motivaci berte tedy prosím i trochu jako úvod/ připomenutí kontextu. Vzhledem k tomu, že i tak je článek docela dlouhý si myslím, že nějaké obhajování ZFS a to ještě vůči btrfs většina čtenářů ráda oželí.

Moje motivace používat ZFS kromě toho, že má celou řadu užitečných vlastností je i to, že řadu jeho vývojářů jsem osobně potkal. Přijde mi, že vývojáři ZFS jsou absolutně zaměření na to, že nechtějí přijít o data, protože to jsou často přímo jejich firmy, které na kvalitách ZFS zakládají svoje podnikání. Řada z nich jsou velmi pokorní lidé, což je speciálně u inženýrů obecně dobrá vlastnost.
Tím neříkám, že by to jiní vývojáři souborových systémů a správců úložišť měli jinak, třeba vývojáři kolem XFS na mě působí lidsky taky jako lidi, kterým bych mohl svěřit svá data. Ale XFS prostě řeší jinou množinu problémů než ZFS.
Jinak bych za sebe napsal, že mám pocit, že nikdo nad btrfs neprovozuje produkčně databázi, nebo k tomu nejsou až tak rozsáhlé materiály, jako u ZFS.

Jinak mě přístup Debianu velmi vyhovuje, jsem na to zvyklý. Vyhovuje mi, že někdo z Debianu řeší balíček pro ZFS, takže to nemusím řešit já.

Jako uživateli mi je opravdu jedno v čem je ZFS napsané, když to spolehlivě funguje a má to dostatek lidí, kteří to vyvíjí. I kdyby to bylo PL/I, Adě, nebo Fortranu.

> Jinak bych za sebe napsal, že mám pocit, že nikdo nad btrfs neprovozuje produkčně databázi, nebo k tomu nejsou až tak rozsáhlé materiály, jako u ZFS.

Pocity většinou klamou. Co takový Facebook / Meta? Že by tam neměli žádnou „produkční“ databázi? Ale co já vím, třeba tam mají jenom „konzumační“ databáze… https://lwn.net/Articles/824855/ https://facebookmicrosites.github.io/btrfs/docs/btrfs-facebook.html

Tedy výrok, že nikdo neprovozuje nad Btrfs „produkčně“ databázi, je tak vzdálený realitě, jak jen může být. Kdyby neměl Btrfs za sebou desetiletí produkčního nasazení (co do celkového objemu dat možná i většího než veškeré nasazení ZFS dohromady), těžko by ho velcí hráči mezi distribucemi (Fedora, openSUSE) prosazovali jako implicitní volbu.

Nedávná chyba je sice opravena, ale není v aktuálním Debian Stable repozitáři.

Dá se to napravit přidáním bookworm-backports main contrib do /etc/apt/sources­.list odpovídajícího repozitaře dle preference.

Potom lze zupdatovat a nainstalovat backportované verze. apt update && apt install zfs-dkms/bookworm-backports zfs-zed/bookworm-backports zfs-initramfs/bookworm-backports zfsutils-linux/bookworm-backports buď jako root nebo se sudo, ale to asi někdo, kdo si hraje se Root-on-ZFS asi zná ;-)