Názory k článku Souborový systém ZFS: přechod a běžná práce s daty
-
"a nechce se vám instalovat systém od začátku"
To mi vysvetli, proc bych proboha mel delat takovyhle harakiri? A pak resit, co se kde zapomelo?
Vemu disk, nahodim si na nej partysny/fs dle vyberu (je uplne jedno jaky) a pak nad tim pustym rsync z disku A na disk B. A kupodivu nejakym zazrakem se prenesou vsechny soubory, veskera konfigurace a celej system a bude to zcela funkcni. Jediny do ceho musim zasahnout je potencielne fstab a pripadne konfigurace grubu(nebo pustit grub-install).
A to zcela pomijim takovou "drobnost" jako prenaseni potencielne klidne i stovek GB data po ssh ... to bude fofr.
-
Samotný linuxový systém opravdu nemá stovky GB. Linux je mnohem úspornější. Spíše jednotky, max. desítky GB. Pokud máte gigabitovou síť a přenášíte to lokálně, je to otázka několika minut. Rychlost vás nejspíše překvapí a bude to pravděpodobně rychlejší než běžná nová instalace.
Stovky gigabajtů může mít adresář /home/, ale to jsou data, která zjevně potřebuji přenést bez ohledu na to, jaký souborový systém používám. Pokud použijete na přenos ZFS, tak je přenos výrazně rychlejší než, kdyby jste použili např. rsync. Krom toho ZFS umí dělat inkrementální zálohy, tedy čerstvou zálohu je možné mít i za několik vteřin.
Když používáte ZFS boot menu, už nikdy nemusíte mít obavy z upgrade systému, nebo z toho, že si systém nějak pokazíte, protože můžete mít verzí Linuxu, kolik chcete, na jednom disku. A pokud něco nefunguje dobře, tak se můžete vrátit v čase. S obvyklým ext4 je to pak mnohem složitější.
Kdyby někdo napsal článek, jak podobné věci dělat s Btrfs v Debianu, byl bych rád. Obávám se ale, že to nebude o moc jednodušší. Btrfs také není dobře do Debianu integrován, většina jej zatím nepoužívá.
-
Mno, dva debiány s rootem btrfs mám, otázkou je, jak ta integrace vypadá.
Jestli jen na tom jet, tak to je naprosto transparentní, prostě se v instalátoru zadal btrfs místo ext4, žádné další harakiri.Jestli využívat nějaké pokročilejší funkce? Zatím používám (před velkými změnami) akorát jednou za X měsíců snapshot, zkušenost s revertem nemám, jen maně vím, že je třeba do command liny grubu je potřeba "cosi" přidat, aby nabootoval ten snapshot, a ve velkém teda používám offline deduplikaci (bees), ale ta je na tom naprosto nezávislá,
-
No kdyby se jeden z Debianů pokazil, můžete nabootovat do toho druhého a pak zkoušet provést rollback, nebo zkoušet přidávat do GRUBu právě to "cosi", co by vám umožnilo nabootovat do té starší verze. Zjevně ale nic uživatelsky přívětivého to není.
Vy máte ale tu velkou výhodu, že máte nachystaný ten druhý Debian, což ale většina uživatelů mít nebude. A tak to možná budou muset řešit z nějaké live distribuce v závislosti na tom, jak moc si původní Debian rozbili. Také by to bylo zjevně na článek, jak tohle co nejlépe řešit a jestli jsou nějaká rozhodnutí na začátku, co mohou pak ulehčit život.
U ZFSBootmenu je to čisté právě v tom, že je to nezávislá ministribuce uložená přímo v UEFI, která umí bootovat všechny Linuxy na ZFS. A ty jsou na sobě nezávislé. Spravovat a vytvářet snapshoty a bootovat do všech snapshotů. A aktualizovat ZFSBootmenu lze pouhým stažením jednoho souboru. Není to závislé na nějakém konfiguračním souboru GRUBu jedné z těch uložených distribucí, která kdyby se smazala, přestane GRUB fungovat. Nebo je to už řešeno lépe?
-
Nie.
Je to na to, aby system vedel zistit, ci nabootovane komponenty su tie, ktore ocakava a ci mu niekto nepodhodil nieco ine.
Napriklad preto, ze ked ma niekto zasifrovane disky, treba k nim heslo, ktore odomkne kluc na desifrovanie. Toto heslo mozem bud rucne tukat do systemu pri kazdom boote, potencionalne do kompromitovaneho systemu, alebo pokial su vsetky komponenty podpisane doveryhodnym klucom, tak si moze heslo/kluc odpecatit z TPM a ja nemusim tukat nic; system nabootuje a desifruje disky bez mojej asistencie a heslo by pytal, len keby sa na situacii nieco zmenilo.
-
Díky za vysvětlení Secure Boot. Nikdy jsem to moc nechápal k čemu je ta komplikace dobrá.
Tedy k uchování hesla, aby je nebylo nutné zadávat při startu.
Ale pokud se někdo dostane do Biosu, aby to vypnul a nebo má možnost disk vytáhnout, stejně přestane tato ochrana fungovat. Tedy je to taková hodně chatrná ochrana.
Operační systém by stejně běžnému uživateli neměl dovolit zapisovat něco do boot uefi partition. A pokud se někdo umí stát rootem, má jiné možnosti jak se k datům dostat.No já to raději vypínám i na serverech, protože nechci někdy v budoucnu řešit problém, že je něco po aktualizaci špatně podepsané. A u notebooku to heslo při startu raději zadávám. Ale není to moc často neb téměř vždy počítač jen uspávám. Výhoda je, že by dotyčný měl problém se k datům dostat i když si vytáhl disk.
-
> Ale pokud se někdo dostane do Biosu, aby to vypnul a nebo má možnost disk vytáhnout, stejně přestane tato ochrana fungovat. Tedy je to taková hodně chatrná ochrana.
Praveze nie. Ked to niekto v BIOS-e vypne, tak BIOS nebude hashovat komponenty v boot sekvencii, nebude sediet finalny hash (bios+bootloader+kernel+initrd+kernel cmdline) a TPM tajomstvo (kluc) nevyda. Pokial sa vyberie disk do ineho pocitaca, tak ten nema TPM s potrebnym klucom a nema co vydat. Treba to brat tak, ze je TPM je uschova tajomstiev, naviazana na dosku, ktora vyda to tajomstvo za urcitych podmienok -- a tie podmienky nie su tak celkom v rukach toho, kto si to tajomstvo pyta.
> Operační systém by stejně běžnému uživateli neměl dovolit zapisovat něco do boot uefi partition.
Vsak ono to v uefi partition nie je. Dokonca ani v uefi vars. Je to v TPM.
> A pokud se někdo umí stát rootem, má jiné možnosti jak se k datům dostat.
No, nema. To je predsa pointa.
> Ale není to moc často neb téměř vždy počítač jen uspávám.
Tu bezpecnost zavisi od toho, ako sa pocitac uspava. Vymaze kluce z RAM a vypyta si ich znova pri zobudeni? (Systemd-homed mal s tymto problem typu kura vs vajce: pokial vymazava kluce pri locku alebo sleepe, a pouzivatel ma zasifrovany home, v nom ~/.ssh/authorized_keys, ako ho potom overit a odomknut home, pokial pouzivatel nema aktivnu session a teda este nie je jeho home odomknuty?).
> dotyčný měl problém se k datům dostat i když si vytáhl disk.
To by mal aj s TPM. Musel by mat desifrovaci kluc -- co moze mat, ono nie je dobre spoliehat sa len na TPM. Ked ten z nejakeho dovodu zlyha -- napriklad pri update BIOS-u -- tak je dobre vediet odomknut svoje data staromodne.
> vypínám i na serverech, protože nechci někdy v budoucnu řešit problém, že je něco po aktualizaci špatně podepsané.
Je to pohyblive kolecko, ktore sa moze pokazit, ale prave tohto by som sa neobaval.
-
Díky za vysvětlení. Ještě ale nechápu tohle.
>> A pokud se někdo umí stát rootem, má jiné možnosti jak se k datům dostat.
>No, nema. To je predsa pointa.
Pokud se někdo dostane do mého počítače nebo serveru jako root. Jak mu Secure boot zabrání aby se dostal k datům? Data jsou přece v té chvíli již odemčená. A jako root je možné se stát libovolným uživatelem.
Také mne napadá, že díky TPM 2.0 může být s každým upgrade trochu kovbojka.
-
> Jak mu Secure boot zabrání aby se dostal k datům? Data jsou přece v té chvíli již odemčená.
Bezi tvoj system. Nie recovery, nie utocnikov system.
Takze pri klasickom sifrovani, ano, tvoj root sa vie dostat k datam, ale iba tvoj root z tvojho systemu (t.j. utocnik musi poznat heslo roota, mat jeho ssh kluc alebo sa nejako inak dostat k jeho pravam). Root z recovery media sa k datam nedostane. Root z ineho pocitaca, kam vlozis disky, sa k datam nedostane, ani jeden z nich ich nebude vediet desifrovat.
Pokial vsak mas dataset per homedir a kazdy ma svoj vlastny kluc (so zfs to mozne je, btrfs zatial nevie nativne sifrovat), alebo pokial mas luks image per homedir (ako robi spominany systemd-homed), tak aj ako root uvidis len zasifrovane data. Musi sa prihlasit user a odomknut svoj home, az vtedy bude desifrovany. A zase sa zamkne, ked sa odhlasi alebo zamkne pocitac.
(A teoreticky: teba nemusi zaujimat sifrovanie samotneho systemu -- v pripade open source systemov utocnik nezisti nic nove. Na systeme ta zaujima integrita /, na co ti staci nieco ako dm-verity. Sifrujes len zaujimave data, teda /home a mozno /etc+/var).
-
"No kdyby se jeden z Debianů pokazil, můžete nabootovat do toho druhého"
"A tak to možná budou muset řešit z nějaké live distribuce v závislosti na tom, jak moc si původní Debian rozbili"man grub-btrfs
Vase argumenty silou mocou obhajujuce ZFS proste neobstoja. Zameriavate sa na malichernosti, alebo veci, ktore existuju aj vo svete BTRFS, akurat o nich asi neviete. ZFS neodsudzujem, ale takmer nic z toho, co je uvedene v clanku, nie je ta killer feature kvoli ktorej by som na zfs prechadzal.
-
Instalator debianu vie btrfs tak maximalne vytvorit v ramci partition a nastavit mu mount point.
Zhodou okolnosti som sa prednedavnom s nim hral (13.7) a chcel som btrfs filesystem tak, ako som zvyknuty z inych distribucii -- so subvolumes @root, @home a @boot. Instalator samozrejme o existencii subvolumes netusi a Google prezradil, ze kedy si treba z instalatora odskocit do druhej vt a tam si to vsetko nastavit rucne. Rovnako netusi, ze btrfs moze ist cez niekolko partition alebo diskov, alebo ze moze mat definovany pocet kopii alebo paritu pre data ci metadata co rozhadzuje na rozlicne zariadenia.
-
"zkušenost s revertem nemám, jen maně vím, že je třeba do command liny grubu je potřeba "cosi" přidat"
Hele je to uplne primitivne trivilani ... proste si pripravis disk ... a v pripade btrfs se to jmenuje subvolume. (i celej disk je subvolume) a muzes si do grubu proste pridat polozku backup ... ktera ti misto primarniho subvolumu na / pripoji libovolnej jinej. A normalne z toho nastartujes, obnovovat nic nemusis. A klidne z toho muzes pak zacit delat dalsi snapy.
Jenom to potom vede k takovymu ponekud chaosu, protoze muzes mit ruzny odbocky odbocek ... technicky to bude fungovat, a ty pak uz nebudes vedet co jsou ty aktuelni data.
Ma to ovsem jeste dalsi aspekty, cim vic snapu mas, tim je to cely pomalejsi a tim vetsi fragmentace dat. Deduplikace samo dela presne totez.
-
"Samotný linuxový systém opravdu nemá stovky GB"
Ano soudruhu, takze uzivatelsky data zahodime."použijete na přenos ZFS, tak je přenos výrazně rychlejší než, kdyby jste použili např. rsync"
Tak to jiste, to mi vysvetli, jak pouzity FS ovlivnuje rychlost ssh po siti ...lol."Když používáte ZFS boot menu, už nikdy nemusíte mít obavy z upgrade systému, nebo z toho, že si systém nějak pokazíte, protože můžete mít verzí Linuxu, kolik chcete, na jednom disku. "
Hezky nesmysl vygenerovany LLM ... -
Ehm, pardon, COZE ?! BTRFS nad debianom pouzivam, no, 15 rokov, alebo tak nejak. /home nemam na samostatnej particii, dokonca ho nemam ani ako samostatny subvolume. Rootfs mozem mat ako samostatny subvolume a upgradovat/snapshotovat/prepinat sa medzi snapmi v grube bez akychkolvek problemov (ale nepouzivam to). Celkovo som zmysel clanku vobec nepochopil, pripada mi to ako nejaky checklist niekoho kto robil nejaku migraciu nejakym pre neho konkretne vyhodnym sposobom, ale cloveka co o prechode na zfs *1 uvazuje to v nicom nepouci a nijak mu to nepomoze.
*1 - a priznam sa ze nevidim jediny dovod preco to robit. Za tych 15 rokov som na btrfs neprisiel o data ani raz. Mozem narozdiel od zfs kombinovat disky roznych velkosti (ked viem co si mozem dovolit, aby som nesiel do priliz velkeho rizika). Funguje tam ako -send tak -receive. Snapshoty. Subvolumes.
4. 11. 2026, 16:52 editováno autorem komentáře
-
"Většina lidí stále používá ext4"
A v tom je nejakej problem?"a nebo pokud si někdo dělá skladiště filmů či her"
???btrfs je dobry ve firmach, kde ti na tom sharu operuje stado negramotnych opic, ktery maji pocit, ze si kazdej soubor musej zkopirovat "k sobe". Potom dava smysl pouzivat deduplikaci, ktera uplne vpohode sahne na 1:10 i vic.
Ale musis pod tim i nad tim mit pochopitelne adekvatni HW.
-
A ta deduplikace pro stádo opic, to je docela vtipné.:) Že je to asi nejčastější užití deduplikace s největším efektem mne nenenapadlo. U nás má deduplikace naprosto zanedbatelný benefit. A i kdybych nasazoval třeba 50 téměř stejných kontejnerů, je možné to řešit i jinak a lépe, jako většinu adresářů sdílet mezi nimi jako read only a podobně.
> "Většina lidí stále používá ext4"
> A v tom je nejakej problem?Ext4 je příšerně "zastaralé" jak s porovnáním se ZFS a tak Btrfs. Důvod proč většina lidí nepoužívá něco lepšího je spíš v tom, že to není dostatečně pohodlné a není to zjevně ani dobře zdokumentované, navíc o těch možnostech (vracet se v čase, snapshoty, incrementální zálohy, flexibilita, komprese, šifrování) ani nemusí vědět.
-
Tak konkrétně na AI sdílet jinak se mi krajně nevyplatilo, všechno "dá řešit i jinak" vede k "pruda na entou" až po "velmi nepříjemná časovaná bomba" (ne-RO hardlinky).
Ono jinak třeba takový PyTorch si v desítce různých projektů žije svým vlastním životem, jednotlivé venv žerou neskutečně místa, to samé modely (spousta věcí si při prvním spuštění natahá modely k sobě, pokud je nemá, dělat ručne symlinky u každého pokusu beru jako kategorie "extra pruda dlouhodobě neudržitelná").
ad poslední odstavec - trochu konzervatismu neuškodí. btrfs používám, protože ty funkce na daný use case potřebuju, ne proto, že ty funkce má. On ten ext4 je extrémně stabilní i rychlý, ne vždycky platí, co má víc funkcí, to je lepší. Však dejte na ZFS vytíženější mariadb... :)
-
S PyTorch si nehraji, na to bude speciální počítač s jiným diskem. Já ZFS používám na kontejnery. A tam je jedno z běžných použití, aby měl každý zákazník svůj kontejner. Žádné hardlinky, ale kontejnery mohou sdílet (mít namountovány) celé adresářové struktury co budou read only. Nejen že to zabere méně místa na disku, je to i bezpečnější, ale také to stačí aktualizovat jen jednou a ne pro každý kontainer zvlášť.
Hodně vytížené databáze na zapisovaná a update na ZFS a FreeBSD mám, po vyladění to běží výrazně úsporněji a rychleji s menším opotřebením disků, než dříve na Linuxu s ext4. Zásadní je zbavit se dvojitých komitů jak na úrovni databáze tak fs. Používám jen komity na ZFS cca jednou za minutu a je to pak mnohem úspornější. Při výpadku elektřiny (kdyby selhala záloha elektřiny) pak mohu přijít max. o poslední necelou minutu dat, což ale v mém případě není zásadní problém. Data ale budou vždy konzistentní. Pokud se používá ZFS na databázi s replikou, problém to nemůže být naprosto nikdy, protože se replika nastartuje od posledního komitu naprosto bez problému a vše co se neužilo nechá provést znova.Offline dedup pro ZFS také existuje např. https://github.com/Mic92/zfs-dedup Ale neměl jsem zapotřebí to používat, protože v mém případě je úspora zanedbatelná. Pro stádo opic bych o tom uvažoval, nebo bych klidně nasadil i onlinde dedub, které může být paměťově náročně, ale pro opice by to stačilo. Opice totiž ukládají spíše větší soubory, ale množství není tak obrovské a na tom se dedub dělá lépe. Na rozdíl od kontainerů nebo jailů, kde může být obrovské množství spíše menších souborů.
-
" celé adresářové struktury co budou read only."
Jenze o tohle se musis starat, musis to resit a obsluhovat, zatimco dedup se o to postara tak nejak samo, a ta vec vubec netusi ze nekde s necim nejaky data sdili ... a navic a to predevsim ... to NENI RO. Tudiz to muzes pouzit kdekoli a kdykoli, a ne jen ve velmi specielnich pripadech.
Takze pokud mam na disku 100x identicky excel, prorotoze si ho 100 oranguranu stahlo ze sdilenyho disku do svyho profilu, tak to zdeduplikuju na jeden (a nejaky ty metadata) a kdyz ho nahodou jeden z nich nejak zmodifikuje, tak bude mit pro sebe tu zmotifikovanou verzi ... ktera mozna bude 90% obsahu stejne sdilet.
"ZFS na databázi"
Ze se fubec namaham == nevis ani jak funguje fs a uz vubec netusis jak funguje databaze. Transakce je pro tebe (a predpokladam ze i pro tu nejmenovanou databazi) tak maximale sprosty slovo.A ne neprijdes o minutu, se svym pristupem prijdes klidne o celou databazi.
-
- Ake kontajnery pouzivate? Docker standardne pouziva jeden image pre rozlicne identicke kontajnery a aj image su riesene po vrstvach, takze tie, ktore maju spolocneho predka zdielaju spolu subory. Nemusi (moze) na to ani pouzivat zfs, bezi to s overlay2 aj na ext4.
- Vypinat commity je nebezpecne. Ano, bude to rychlejsie :) ale hw moze klamat, ci to ma naozaj ulozene.
- dedup nezalezi od velkosti suborov. Deduplikuje sa po blokoch a teda vie to deduplikovat aj take subory, ktore zdielaju len cast obsahu. Samozrejme, idealne je, ked aplikacia pouzije reflink, vtedy je informacia uplne presna. Automat nekontroluje zhodu od kazdeho offsetu, ale od hranice bloku, na rozdiel od informacii, co ma k dispozicii reflink.
-
- Používám samotné lxc a jaily. Každý kontejner je samostatný. Jakákoli deduplikace se nevyplatí, ušetřil bych max. několik procent celkové kapacity. Pokud to má docker dobře vyřešené, pak deduplikace bude dobrá opravdu jen pro snížení škod stádem opic.
- ZFS funguje dobře i bez vypínání komitů. Ale ne vždy je nutné je nechat zapnuté, protože ZFS samo o sobě bývá dostatečnou ochranou proti poškození konzistence dat. Pří výpadku elektřiny ZFS změny na souborovém systému rollbackne k poslednímu konzistentnímu stavu. Přijít o pár vteřin dat jednou za pět let, při výpadku elektřiny i záložního zdroje, je pro mnohé služby akceptovatelné. Krom toho "ztracená" data nejspíše budouv pořádku na serveru, na který se databáze replikuje klidně v jiné lokalitě. Pokud máte v databázi např. účetnictví, kde je každá položka hodně podstatná včetně navázání na další záznamy, pak jich ale nemáte zase tolik, aby několikanásobný zápis dělal problémy s výkonem.
- pokud máte převážně větší soubory, můžete mít větší recordsize a to výrazně usnadňuje a zefektivňuje deduplikaci. Stádo opic vytváří převážně větší soubory, ale nezvládne jich vytvořit obrovské množství - deduplikace je snadná a efektivní a u stáda opic přináší i velmi podstatnou úsporu místa na disku. -
ZFS je odolnější vůči chybám co mohou vzniknout na disku při výpadku elektřiny než ext4 díky copy on write. Data se nepřepisují na místě. Stav disku se vrací k poslední komitnutné a konzistetně zapsané skupině dat. A i kdyby tohle selhalo, lze se vždy vrátit k poslednímu snapshotu. Vypínat komity v databázi je tak bezpečnější než u ext4.
Pokud se ale něco stane s hlavní databází, scénář je, aby funkci databáze přebral jiný stroj, který byl do teď jen replika. Pokud replika není zasažena stejným výpadkem elektřiny, žádná data se neztratí a nekonzistence nevznikne. Replikuje se totiž okamžitě.
-
Docker uz roky vie vcelku uspesne pouzivat btrfs subvolumes a funguje to dobre. Ma to jednu nevyhodu, ktora ma mozno riesenie, ale ja som ho neobjavil - ked chcem odzalohovat /var/lib/docker, s btrfs je to PITA, preto si docker prepinam na overlay2 aj na btrfs diskoch. Pokial ma niekto nejake jednoduche riesenie, sem s nim.
-
Adam KaliszStříbrný podporovatelUž je to nějaký pátek, ale psal jsem tu článek o tom, jak migrovat z EXT4 na ZFS aniž by k tomu bylo potřeba cokoliv dalšího. (https://www.root.cz/clanky/konverze-debianu-ze-souboroveho-systemu-ext4-na-moderni-zfs/) Používám to pořád, mám na to skripty, mám podobné skripty i na instalaci rovnou na ZFS, včetně šifrování, encrypted swapu atd. Kdyby o to byl zájem, můžu se pokusit to trochu začistit a zveřejnit...
-
Články o ZFS jsou bezesporu zajímavé, ale osobně tam trochu postrádám nějaký úvod do problematiky. O ZFS mám jakousi představu, ačkoliv nikdy jsem ho nepoužíval.
A tak by mi přišlo užitečné, kdyby vyšel (nejspíš hned jako první v řadě :-) článek o tom, co a zač je ZFS, jaké jsou jeho silné (případně slabé) stránky, co mi nabídne oproti klasice jako ext4, XFS, btrfs, ideálně jaká je jeho podpora v hlavních distribucích (ale chápu, že autor používá Debian, tak s ničím jiným třeba zkušenosti nemá; nicméně z licenčních důvodů jej typicky nenasadím stejně snadno jako "klasické" souborové systémy) a proč bych jej vlastně měl chtít začít používat. Pokud by autor zvážil napsání takového článku, patří mu předem mé poděkování :-).
-
Tohle je třetí díl série o ZFS. První a druhý je zde.
https://www.root.cz/clanky/zfsbootmenu-bootovani-linuxu-na-souborovem-systemu-zfs/
https://www.root.cz/clanky/souborovy-system-zfs-klonovani-instalace-na-jiny-disk/A není to první článek na téma ZFS ani na rootu. Je jich více.
ZFS není žádná novinka, ale je nyní snandé jej používat i na Linuxu.
Bohužel články není moc snadné je najít. Např. zde je jedna série.https://www.root.cz/serialy/souborovy-system-zfs/
Pokud bych měl říci ve zkratce výhody.
- snapshoty, snadné inkrementální zálohy na jiný disk.
- možnost libovolně vytvářet a mazat datasety (oddíly disku), jak je potřeba. datasety sdílejí společné místo.
- komprese (úspora cca 1/3 místa) a možnost šifrování datNevýhody:
- licence, nekompatibilní s Linuxem
- starší, ale dobře odzkoušené generace oproti btrfs, který je podobný souborový systém pro Linux. Pokud máte velké diskové pole, možnosti přidávat další disky jsou omezenější. Odebírat není možné. To já jsem ale nikdy nepotřeboval. -
Používání ZFS u tak starého článku se může lišit maximálně nějakými detaily, jako např. mohla přibýt nějaký nový způsob komprese. Základní principy a použití budou určitě naprosto stejné. Ve freeBSD se věci obvykle tolik nepředělávají jak bývá zvykem v Linuxu.
Zde je ještě jeden novější článek.
https://www.root.cz/clanky/konverze-debianu-ze-souboroveho-systemu-ext4-na-moderni-zfs/ -
Ono sa za 15 rokov toho aj u zfs zmenilo dost. Napr. uz je flexibilnejsi ohladom rozsirovania pola.
Ohladom ficur ma ako kazdy dospely filesystem feature flagy ulozene v metadatach. Takze pre stary filesystem bude pouzivat stare ficury, pre novy novsie ficury a ked pouzivatel vie, ze stary filesystem uz do stareho systemu nepojde, moze si ich pozapinat tiez.
-
- snapshoty - ma aj btrfs
- snadné inkrementální zálohy na jiný disk - ma aj btrfs
- možnost libovolně vytvářet a mazat datasety - ma aj btrfs (subvolume)
- komprese (úspora cca 1/3 místa) - ma aj btrfs
- a možnost šifrování dat - toto btrfs nema- starší, ale dobře odzkoušené generace oproti btrfs - no, neviem. V petabytovych poliach dajme tomu, s tym skusenosti nemam a tam asi zfs exceluje. Doma (jednotky az desiatky diskov) by som tam zasadny rozdiel asi nevidel
- pokud máte velké diskové pole, možnosti přidávat další disky jsou omezenější. Odebírat není možné. To já jsem ale nikdy nepotřeboval. - no, ja mam NAS o 8 diskoch a uz som odoberat potreboval - napriklad ked chcipol stary disk s malou kapacitou (4 TB) a nahradzal som aj jeho brata za dva vacsie disky (14 a 20 TB), pricom som nemal oba k dispozicii v rovnaky cas. Proste som jeden disk odobral (a nechal jeho data rozliat po zvysnych diskoch v poli) a potom som az postupne pridaval nove disky. Tu by si clovek zo ZFS podla mna dost vylamal zuby.
Ja som so ZFS experimentoval pred par (8?) rokmi, ked som staval svoj prvy vacsi (5+ diskov) NAS. Nakoniec som zhodnotil, ze ta teoreticky vacsia bezpecnost dat (*1) nevyvazi diskomfort ktory to prinesie a ostal som na btrfs 'raid1(10)'. Jedna z mala veci co sa mi na zfs pacila bolo, ze self-healing fungoval uplne transparentne a lepsie reportoval problemy. Na btrfs to chce o krok naviac - pridat do cronu scrub a pokial ten na niecom failuje, horsie sa dohladava zoznam zasiahnutych suborov. Pokial by som mal btrfs nieco vytknut, tak prave tento reporting, ktory stale, aj po tolkych rokoch, stoji podla mna uplne za prd.
*1 - ono je to uz nejaka doba, ale niekde na webe som narazil na ludi co sa so zfs dostali do slepej ulicky a prisli o data
-
*1 O data se dá přijít vždy, zvláště když někdo nedělá backup a spoléhá se, že to pole nikdy nemůže padnout a i kdyby, že půjde opravit.
Když se podívám na Debian wiki o Btrfs, budí to dojem, jako že to není ještě dodělané kolik je tam různých varování. I když některé možná budou zastaralá.
https://wiki.debian.org/Btrfs
Naproti tomu ZFS je relativně čisté.
https://wiki.debian.org/ZFSV mém případě dělám a posílám snapshoty na záložní stroj každých 5 minut. Kdyby disk nebo stroj odešel, převezme jeho práci záložní stroj. Nemusím nic obnovovat nebo dolovat, aby vše běželo ze záložního místa. Ale ještě jsem o žádné ZFS nepřišel. Spíše padají nebo zlobí počítače. Tedy zrovna v mém případě mám jistotu, že to co umí Btrfs navíc nikdy nebudu potřebovat. Kdyby šlo hlavně o to mít hodně dat na jednom poli a větší množství různých disků, je to trochu jiné užití.
-
U btrfs je najvacsi fuckup asi write hole u raid5/6. Preto sa doporucuje tieto raidy nepouzivat. Synology na to slo inak a stavia kvazi-raid spajanim sw raidov rozprestrenych po diskoch do jedneho btrfs filesystemu, coz mi pripada genialne, ale zaroven zlozite na udrzbu. Ja som na ZFS chcel prejst niekolko krat, ale proste moj realny mix diskov je taky, ze nikdy nemam x diskov rovnakej kapacity - a ani nechcem v pripade havarie jedneho disku preskladavat cele pole z novych diskov, aby som neplytval kapacitou noveho disku. Toto je viac pravdepodobnejsi scenar v datacentrach, kde je tych serverov x v racku a maju rovnake disky - a za rovnake ich v pripade poruchy vymienaju.
Co sa tyka migracie, ja uz doma bezim vlastne vsetko v proxmoxe. Keby som mal teda 2 a viac strojov, tak by som postavil ceph cluster a bezal to na nom a na zfs a btrfs sa uz asi vykaslal.
-
Write hole sa da riesit UPS-kou, pre tie situacie, kde je to problem. Osobne si myslim, ze toto nikdy nebude v btrfs vyriesene. Na rozdiel od ostatnych rezimov, v parity mode nie su peniaze. Ani Synology ich nenaslo, a to btrfs predavaju a ziju z neho.
V zfs pravidlo rovnakej velkosti diskov plati pre vdev, nie pre pool! Takze je mozne zostavit pool z viacerych vdev, pricom kazdy vdev ma inu velkost. Ale to sa tiez bavime o pocitacoch, ktore maju viac diskov ako zopar.
Na ceph 2 nody nestacia, resp. nema to zmysel. Aj proxmox ma pri jednocifernych poctov nodov vacsi zmysel v HA clusteri a VM na NAS alebo lokalne a synchronizovat ich. Proxmox pre HA vyzaduje aspon 3 nody (treti node nemusi byt nutne plny Proxmox, ale musi to byt corosync qdevice, aby nody vedeli kedy maju quorum, co sa v parnom pocte neda). A este pamataj na to, ze ceph s nizkym poctom nodov bude mat nizsi vykon ako lokalne disky, takze aby si nebol sklamany.
-
"U btrfs je najvacsi fuckup asi write hole u raid5/6. Preto sa doporucuje tieto raidy nepouzivat."
Neustale a dlouhy roky oprakovany blabol ...
Kdyz libovolny pole vyrves z elektriky, tak to zjebe data na nem. A je uplne jedno jaky je to HW a jaky na tom je FS. Presne proto mas na raidovych radicich baterky, a kazdy spevpravny pole ma baterky taky, svoje, vubec neni rec o UPS ktera je jen dalsim prvkem.
-
S tymto nemam skusenosti, najvacsie pole co som kedy riesil malo 8 diskov a bol to sw raid. Mozno prave preto, ze to nemam pod kozou, tieto hw raidy nepouzivam. Raz som sa nechal ukecat a pouzil som v dell serveri hw raid s linuxom a rozbil som si hubu ked jeden disk chcipol - a uz to nikdy nechcem zazit. Preto som pri upgrade domaceho serveru (presiel som zo skladacky na dell poweredge) preflashoval perc do it mode a bezim tam btrfs raid1 zatial k plnej spokojnosti. Tak uvidime.
-
Michal ŠmucrStříbrný podporovatel
To se mi nějak nezdá, spíš mi to přijde, že tam u vás musel být souběh s nějakým jiným problémem.
Protože pokud je všechno ostatní v pořádku, dostanete se maximálně do fáze, že už nemůžete zapisovat žádná další data a ne že by se začaly samovolně mrvit nějaké struktury fs.
A samozřejmě ano, pokud nějaký fs delší dobu provozujete s nedostatkem volného místa, tak se to přirozeně projeví na výkonu, fragmentaci. U těchhle složitějších fs s CoW, snapshoty atd. to pak může být ještě citelnější. A pokud ho naplníte úplně po hrdlo (což ale zdaleka neodpovídá těm 20%, které zmiňujete), může za určitých okolností nastat hlava 22 situace, což ale opět neznamená ztrátu dat.Teď přímo k tomu ZFS, zpool po vytvoření počítá s takzvaným slop space, což je ve výchozím stavu 1/32 kapacity (s maximem 128 GiB a nastavitelné přes parametr modulu - spa_slop_shift).
https://openzfs.github.io/openzfs-docs/Performance%20and%20Tuning/Module%20Parameters.html#spa-slop-shift
To je vyhrazená část právě primárně na to, aby se daly dokončit operace s metadaty, pokud už došlo standardní místo. Je to víceméně ten rozdíl kapacity, co vidíte při zpool list (free) a zfs list (available).
Další obecný aspekt, co je třeba mít na paměti, je to, že pokud mažu soubory (tzn. i když je zpool plný a potřebuju uvolnit místo), tak musím dát logicky pozor, aby nebyly součástí jiných snapshotů a také, že se místo neuvolňuje okamžitě, ale asynchronně přes workery na pozadí.Stran té praktické degradace výkonu, respektive nějakého prahu volného místa, kdy se se to začne chovat jinak z hlediska alokace. Většinou se jako bezproblémové "pravidlo" zmiňuje držet se do 90 % použitelné kapacity. Je to zjednodušená celková cifra kvůli tomu, že se při alokaci používají tzv. metaslaby, aby se zlepšila škálovatelnost. Pokud daný metaslab má míň než 4 % volného místa, alokátor pak použije jinou (pomalejší strategii). Takže nejde jen o to kolik celkově mám volného místa, ale i kam přesně zapisuji.
https://openzfs.github.io/openzfs-docs/Performance%20and%20Tuning/Workload%20Tuning.html#metaslab-allocatorTakže mechanismy, které by měly bránit problémům, v ZFS jsou. Osobně jsem s poškozením nebo ztrátou dat v důsledku nedostatku volného místa problémy (neřkuli s těmi 20%, co zimňujete) nikdy neměl. Přičemž se bavíme o dlouhodobé zkušenosti s nejrůznějšími použitími (byť tedy převážně na FreeBSD a předtím i Illumosu) i velikostmi zpoolů.. včetně různých DIY NASů od kamarádů, co se k nim nechovali úplně "hezky" a mělo to fakt daleko k best practices :). A několikrát během let jsem i tyhle specifické situace zkoušel.
-
No zdať sa vám to nemusí. Ale ja som to zažil.
- Opensolaris ako storage server tam je to natívne. - Strata dat alebo len konexie. Pomale ako keby tie dáta boli na USB kľúčiku.
- Linux (myslím Ubuntu) - Pomalosť a strata konexie.
- IBM SPP Vsnap - Strata časti dat. Musel som to zmazať a vytvoriť prázdne. A tam som vedel pridať kapacitu hneď ako to vyskočilo. (Ale obrovsky balík dat tak bolo neskoro)Všade rovnaký problem. Kým som dostal navýšenú kapacitu prehuplo sa to cez 20% a v prípade IBM SPP Vsnap cez 10% volného.
-
Adam KaliszStříbrný podporovatel
Prosím o jakém časovém rozpětí se tu bavíme? Je něco z toho se ZFS 0.8 nebo novějším?
-
Michal ŠmucrStříbrný podporovatel
O.K. já nerozporuju, že s tím máte špatnou zkušenost. Rozhodně to má nárok na to, aby se to v určitý moment zpomalilo a technicky dává smysl, proč se to děje. Fragmentace volného místa v metaslabech, daleko vyšší vytížení CPU při alokaci, špatná lokalita - nekontinuální uložená data.
A ano samozřejmě kolik toho případného zpomalení vaše použití snese je další věc. Stejně jako bude záležet na nastavení celého systému. V tom ohledu, že to zpomalení bude daleko drastičtější dopad, pokud budu mít třeba často se přepisující soubory nebo zvoly s malými bloky, snapshoty a ještě to bude např. na nějakém vdevu s točivými disky a raidz (od počátku nicmoc IOPSy).. tam bych si na dostatek volného místa dal extra pozor. Oproti tomu pak v případě, že to bude víceméně bulk storage, data se nebudou moc měnit, tak to snese mnohem míň volného místa, aniž by se to zásadně projevilo (ozkoušeno poměrně mnohokrát, zmíněné různé DIY nasy, co jsem dával do kupy).
V ZFS pak (minimálně ve těch verzích za posledních x let zpět) máte poměrně hodně nástrojů, jak tohle analyzovat (zdb, sysctl OID na FreeBSD nebo procfs položky na Linuxu, DTrace a perf pokud chcete jít úplně do detailu a zkoumat kolik času ZFS tráví v jednotlivých úkonech, abyste třeba odseparoval samotná bloková zařízení a CPU).
Plus jak už jsem zmiňoval předtím, zpomalení je problém víceméně všech fs.. zvlášť těch složitějších Btrfs nevyjímaje (tam používám také leckde tvrdé kvóty)."strata konexie" upřímně nevím, co si pod tím představit - jakože to mělo tak dlouhé odezvy, že vypršely nějaké timeouty v aplik. vrstvách nad fs?
Ale prostě moc nemá logiku, proč byste měl v tu chvíli přijít o data pokud zaberete 80 nebo 90 % kapacity poolu.
Ano mohl to být i nějaký bug v konkrétní verzi, ale to je s tím výčtem, co jste psal, docela nepravděpodobné.
OpenSolaris už jsem minul (co to Oracle zařízl, pak už byl Illumos, kde to stejně konvergovalo ke společnému OpenZFS) a IBP Vsnap jen vím, že existuje jako nějaká alternativa Veemu. Ale už tím, že je to sw s podporou, v podstatě sw appliance od IBM s přednastaveným ZFS, tak bych v případě takového fatálu tohle rozhodně s nimi řešil a chtěl se dobrat detailního rozboru chyby.
Stejně tak, kdyby se mi to třeba stalo na FreeBSD, asi bych asi také pátral, chtěl to zdebugovat a nebral to jen jako "shit happens". I v té komunitě okolo se pohybuje dost lidí z Klary, iX Systems, OpenZFS.. co by tyhle fatální situace měly zajímat a mohli být nápomocní.
Totiž ať už tam muže být zmíněné zpomalení, tak nepřipojení fs nebo ztráta dat je úplně jiný level problému. Nedokážu si představit, že fs, který je mnoho let výchozí na všech FreeBSD instalacích, existuje bambilion instalací s Oracle appliancemi, TrueNASy, Proxmoxem (oboje může mít placenou podporu a SLA), QNAP QuTS, takb bude mít problém v duchu:
víc než x % zabraného místa -> ztráta dat, fajn kluci jdeme od toho.. to se tak prostě stává. -
Michal ŠmucrStříbrný podporovatel
Díky za doplnění, tohle jsem nevěděl..
Se Solarisem jsem se už po uzavření kódu prakticky nesetkal, ale teď jsem to zkoušel dohledávat - musel jsem do blogu z r. 2015
https://web.archive.org/web/20210411183233/https://blogs.oracle.com/roch/block-picking
To potvrzuje, co jste psal. Není to jednotlivý fix, ale jak to chápu, tak docela razantně překopali ten alokátor, který už nepřepíná dvě strategie (first fit, best fit) na bázi celkového volného místa v metaslabu. Tzn. není tam ten fixní práh (70% historicky před 2010 a pak 4%) a jinak to pracuje s vážením těch vhodných metaslabů.
Nicméně byť tahle úprava z proprietárního Solarisu už není v OpenZFS, tak se nedá říct, že by tohle vůbec neřešili. Pamatuju si historicky (2018-19) pár pull-requestů i od Matthewa Ahrense nebo ze SmartOS, které řešili právě ty kritické propady výkonu a nějaké patologické situace, co mohly nastat v metaslab alokátoru když docházelo místo. Teď jsem to nehledal znovu, ale od té doby budou součástí OpenZFS (minimálně od dvojkové verze). -
Nejde jen o to nabídnout Btrfs (nebo ZFS) během instalace, ale nabízet i všechny jeho výhody automaticky bez další ruční konfigurace. Např. možnost nabootovat do staršího snapshotu, home v odděleném datasetu, možnost přidat další instalaci např. novější verze na stejný disk a podobně. Pokud někdo používá Btrfs stejně jak by používal ext4, tak si nijak nepomůže, snad kromě toho, že kdyby někdy dostal chuť se tím ručně prokousat, bude to mít možná mírně snadnější.
Napadá mne, že pokud Ubuntu nabízí instalaci přímo na ZFS, mohla by být instalace ZFSbootmenu jednodušší. Ale návod je v podstatě stejný jako pro Debian. Této možnosti nevyužívá. https://docs.zfsbootmenu.org/en/v3.1.x/guides/ubuntu/uefi.html
Je otázka jestli je k tomu nějaký podstatný důvod, nebo jen ten návod nikdo nenapsal. -
Nie som si istý, ale myslím, že práve toto rieši OpenSUSE a Snapper
https://doc.opensuse.org/documentation/tumbleweed/snapper/ -
Samozrejme. Je to len autorova neznalost. Tieto veci (boot do snapshotu, cp --reflink pre rychlu shallow copy, atd...) su tu s btrfs minimalne 10 rokov, mozno aj viac. Uz som to pisal a zopakujem to - mne sa na zfs paci a na btrfs mi chyba reporting problemov a self-healing. S btrfs musi proste clovek cumiet pri problemoch do kernel logov, inak sa nedozvie ani prd. A to je podla mna obrovska skoda a obrovska hanba, ze je to v tomto pastave tak dlhu dobu.
-
Táto séria článkov o ZFS ma zaujala. Musím však povedať, že po prečítaní, zvlášť tohto posledného aj sklamala. Nechcem autora nijako haniť. Napísať dobrý článok, prípadne sériu, nie je vôbec jednoduché. Sám som už chcel pre root.cz napísať niekoľko článkov, no nakoniec som si uvedomil, že buď by to vyžadovalo veľké množstvo času a energie alebo by to vlastne ani nebol článok ale skôr blogový zápis. Po prečítaní článkov a diskusie pod nimi by som zatiaľ moje vnímanie zhrnul takto:
- prvý článok mal byť o ZFSBootMenu. V skutočnosti bol o ručnej inštalácii Debianu a ZFSBootMenu a vypísaní vlastností ZFS. Teda vlastne nie ZFS ale vlastností moderných filesystémov založených na CoW. Áno, je tam spomenuté aj natívne šifrovanie, ktoré napr. Btrfs natívne nevie.
- druhý článok je o klonovaní na iný stroj. Tu veľmi nie je čo vytknúť, článok popisuje to čo sľubuje
- tretí článok ma vyslovene zaskočil. Má to byť článok o prechode na ZFS a bežnej práci. V skutočnosti to pôsobí ako poznámky z migrácie konkrétneho starého systému na nový. Nazvať novú inštaláciu systému, skopírovanie dát a hádanie, čo všetko vlastne potrebujem skopírovať, aby systém fungoval ako predtým by som nenazval "prechodom". ZFS síce neumožňuje priamu konverziu ext4 na zfs ako napr. btrfs-convert. Ale prečo to neurobiť napr. cez rsync zo starej inštalácie do zfs a následne úpravu /etc/fstab, bootloadera a pod., ako to v tejto diskusii už niekto spomínal?
- celkovo mi v článkoch chýba napr. porovnanie možností Btrfs a ZFS s vysvetlením prečo autor zvolil práve ZFS. Neskôr v diskusii sme sa dozvedeli, že so ZFS má skúsenosti a tak použil práve toto. Je to dobrý a postačujúci argument. Lenže nikde v článkoch to spomenuté nebolo. Naopak, vlastnosti ZFS boli spomínané ako najväčšia výhoda oproti iným FS. Pričom napr. Btrfs má skoro všetky tie vlastnosti a navyše je súčasťou kernelu.
- za najväčší prínos považujem rozbehnutú diskusiu pod článkami. Tam sme sa dozvedeli o vlastnostiach Btrfs, limitoch jedného aj druhého FS. Pravidelne sa objavuje argument, že Btrfs nie je dostatočne integrovaný do Debianu a jeho inštalátora. Avšak ZFS je integrovaný ešte menej - cez inštalátor s ním pracovať neviem vôbec a dokonca musím mať DKMS modul. Iný argument je, že ZFS je starší a teda viac overený ako Btrfs. Tu môžeme namietnuť, že ext2 je ešte starší, ale zjavne to nie je argument pre jeho použitie v moderných strojoch :-) Z môjho pohľadu teda ZFS má výhody len dve:
- RAID56
- natívne šifrovanie s možnosťou posielať šifrované inkrementálne snapshoty na vzdialený stroj bez toho, aby cieľový stroj poznal kľúč
Ešte raz - nechcem autora haniť. Vážim si, že napísal tieto články. Ale predsalen mi tam niečo chýba. Autor zjavne ovláda ZFS, má s ním skúsenosti na viacerých strojoch a pod. Podľa všetkého v oblasti Btrfs, či SecureBoot už to také presvedčivé nie je. Čo ma veľmi zaujalo je, že robí snapshoty bežiaceho systému každých 5 minút. Má tak možnosť v prípade problémov nabootovať starší snapshot, prípadne vrátiť zmenu, ktorú vykonal. A práve toto by mohlo byť jadrom seriálu - ako vlastne tie snapshoty orchestruje? Robí snapshot každých 5 minút, potom raz za hodinu jeden vyberie a staršie vymaže, raz za deň vyberie jeden a zmaže tie z predchádzajúceho dňa, atď. ? Toto by bola naozaj veľká pridaná hodnota.
Aby nedošlo k nedorozumeniu - Btrfs nepoužívam. Kedysi som ho skúsil na laptope kvôli Timeshift. Vtedy ma to nepresvedčilo a neskôr som sa vrátil ku LVM + ext4. Momentálne mám v pláne migráciu laptopu na LUKS2 + TPM2 + SecureBoot + Btrfs. Práve kvôli bezpečnejšiemu CoW, možnosti vytvárať snapshoty a integrácii v kerneli. A ktovie, možno sa nakoniec dokopem k tomu, aby som napísal článok o dôvodoch, ktoré ma k tomu vedú, na čo som narazil a či to splnilo moje očakávania.
-
No, on to byl původně jeden článek, redakce jej rozdělila na 3 díly. Tedy původním cílem nebylo psát nějaké obecné vyčerpávající pojednání o ZFS. Navíc to už bylo napsáno.
Srovnávat s Btrfs obecně nemohu, neboť jej nepoužívám. A jsem si vědom toho, že je to hodně věc názorová a nechci tvrdit něco kontroverzního přímo v článku.
V době cca před deseti lety, kdy se rozhodovalo co použít, nebyl Btrfs rozhodně dostatečně odladěný pro intenzivní použití na serverech, včetně hodně zatěžovaných databází.
Tedy proto jsem začal používat ZFS. Nyní nemám důvod ZFS opouštět, zvláště když jsem kvůli ZFS začal používat i FreeBSD. Konfigurace ve FreeBSD je v mém případě mnohem přehlednější a přímočařejší, což výrazně usnadňuje správu kontejnerů.
ZFS se dá používat různě, jeden ze způsobů je možnost snadno dělat zálohy a např. klonovat jeden systém pro více různých počítačů či pracovníků. Je to podle mne dobrý způsob, jak ukázat něco praktického. Návod navíc potřebuji i pro sebe. Hlavní motivace je ta, že jednou za několik let rád začínám s čistou instalací. Se ZFS mohu instalaci novějšího systému udělat dříve, než odstraním ten starší. Nemusím fyzicky měnit disk. Starší instalaci mohu odstranit až poté, co se novější plně otestuje a zkopírují se ze staršího systému různé pomocné skripty a důležité soubory, které používají zaměstnanci.
O tom, jak jej používám na serverech, by se také dalo napsat. Ale čtenářů by bylo asi trochu méně a také je tam trochu omezení v tom, jaký nástroj na automatické inkrementální zálohování použít. Je jich ohromné množství. Každý má nějaká svá pro a proti a těžko říci, co je nejlepší. Na Linuxu používáme vlastní nástroj napsaný v Ruby, ale nejsem úplně spokojený. Na FreeBSD používám zrepl - https://zrepl.github.io/. Zrepl funguje samozřejmě i v Linuxu. Celkem dobrý. Snapshoty se dělají každých 5 minut jak na Linuxu, tak na FreeBSD a inkrementálně se přenášejí vždy na jiný stroj. Ta inkrementální synchronizace trvá vždy max. pár vteřin a je omezena rychlost, aby to nezahltilo linku. Funguje to roky spolehlivě.
Architektura je taková, že jsou vždy dva stroje, které se navzájem zálohují, a kdyby jeden vypadl, druhý je připraven zastat jeho práci. Jaily/kontejnery prostě spustím na tom druhém stroji se stejnou IP adresou během několika minut. Problémový stroj mohu vypnout. Tedy žádné zdlouhavé složité obnovy ze zálohy se nekonají.
Mám více času na to prozkoumat počítač či disk, který selhal.
Tedy všechny stroje jsou ve dvojicích, které se navzájem zálohují a zaskakují.
Až budou stroje s FreeBSD 3, budou se zálohovat všechno na všechny stroje. Většinu Linux strojů hodlám časem odstavit ve prospěch FreeBSD. Ale to z hlediska ZFS vůbec nic nemění, to se na Linuxu používá v podstatě stejně.
Dat nemáme tolik, aby to byl problém mít většinu záloh na všech strojích, hardware jsme naštěstí nakupovali před zdražením. Se ZFS žádný problém nikdy nebyl, nemá pro mne smysl zkoušet Btrfs, které navíc nefunguje na FreeBSD, které nyní také používáme a kvůli jednoduchosti nehodláme opouštět.
Jak dobře či podobným způsobem používat Btrfs by mne také zajímalo, ale psát o tom nemohu, neboť s tím nemám zkušenost. Je více způsobů, jak dělat něco dobře i jak dělat něco špatně. Že někdo něco dělá jinak, neznamená, že je to špatně a i tak je možné se něčím nechat inspirovat. Tedy moc nechápu nářky, jako že je FreeBSD nebo ZFS zastaralé a nemá smysl jej používat. Podobné věci nelze zobecňovat.
-
1. "možnost snadno dělat zálohy a např. klonovat jeden systém pro více různých počítačů či pracovníků"
btrfs-send, btrfs-receive, pripadne cp --reflink pokial by slo o image virtualov v ramci jedneho subvolume
2. Se ZFS mohu instalaci novějšího systému udělat dříve, než odstraním ten starší.
To mozete aj s btrfs. Staci novy system nainstalovat do subvolume a nabootovat z neho. Pripadne pokial sa nejedna o cistu instalaciu, ale upgrade existujuceho systemu, tak snapper alebo grub-btrfs atd...
3. Snapshoty se dělají každých 5 minut jak na Linuxu, tak na FreeBSD a inkrementálně se přenášejí vždy na jiný stroj
btrfs-send, btrfs-receive a https://github.com/digint/btrbk
4. Ta inkrementální synchronizace trvá vždy max. pár vteřin a je omezena rychlost, aby to nezahltilo linku.
Obmedzenie rychlosti som neskumal, ale ano, prenos snapshotov je (vie byt) inkrementalny.
5. Jak dobře či podobným způsobem používat Btrfs by mne také zajímalo, ale psát o tom nemohu, neboť s tím nemám zkušenost.
Myslim ze z toho o com pisete je to funkcne 1:1. Co si pamatam co ZFS malo naviac proti BTRFS (a teraz snad nekecam, je to 10-15 rokov) bola moznost na ZFS spravit block device (napr. pre virtualnu masinu). Na btrfs to vtedy neslo, aka je situacia dnes netusim, ale mam taky tusak, ze ked sa dokazal presunut na btrfs swap, tak to uz mozno poriesene bude.
-
Já bych vám dal odpověď ze svého pohledu na bod čtyři. Rovnou přiznávám, že operační systém provozuji na ext4 (protože jsem to tak jednou už nainstaloval a tím pádem to tak je a bude, dokud to neklekne) a ZFS jsem zvolil pro zálohování. Proč jsem zvolil ZFS a ne BtrFS?
1.) Zálohuji na jednom jednoduchém zrcadle tři počítače tří lidí. Každý má zvlášť dataset s vlastním šifrováním. Pokud vím, tak BtrFS neumí nastavit šifrování zvlášť pro každé subvolume a řeší ho pouze globálně. Jsem si 100% jisý, že toho i s BtrFS lze nějak docílit, ale ten postup bude složitější a samotný BtrFS to nedá sám. Snad nelžu. Kdyžtak se omlouvám a opravte mě. Šifrování samozřejmě může zajistit případně zálohovací software, ale tady je výhodou, že jeden nemá možnost narušit zálohu druhému, protože se k datům někoho jiného prostě nedostane. Já vím, je to zbytečná paranoia obzvlášť v rodinném prostředí, ale... Zároveň tím je zajištěno, že pokud dojde k narušení záloh, nemůže být nikdo nařčen ze sabotáže, protože je jasné, že do datasetu někoho jiného se nemohl nikdo cizí dostat (pokud zanedbám únik hesla).
2.) ZFS umí deduplikovat datové bloky za letu a sám. Není potřeba spouštět separé další program duperemove a pak dělat rebalanci, aby se uvolnilo místo. Obě tyhle operace zaberou dost času. Nicméně... ZFS DDT si bere dost RAMky a deduplikaci mi nyní řeší BorgBackup, takže jsem jí nakonec po dlouhé úvaze nepoužil a do teď přemýšlím nad tím, jestli to nebyla chyba. Ale zdá se, že jí v této konfiguraci fakt nepotřebuju, takže jedu pouze LZ komprimaci. Někdy se to ale určitě hodí - proto to zmiňuju.
3.) BtrFS je podstatně mladší, než ZFS. Tak předpokládám, že ZFS bude vyzrálejší.
4.) ZFS je prostě monolitičtější. Nabízí sám o sobě nástroje, které BtrFS nemá, ale musí se kombinovat s dalšími technologiemi.
5.) A to hlavně... ZFS byl pro mě novinkou a přišel mi prostě cool.Jinak BtrFS je podle mě naprosto vynikající FS a klobouček. Rozhodně si nechci hrát na chytráka. V podstatě o tom všem vím hodně málo - jen to, co jsem potřeboval. Kdybych neměl ZFS a použil BtrFS, necítil bych asi žádný technologický dluh ani potřebu něco měnit.
Nicméně... Startovat tímto způsobem (viz. článek) Linux přímo na ZFS je sice zajímavé, ale já vám ti jsem nakonec rád za normální GRUB a EXT4. Je to prostě ověřené a funkční řešení a já jsem uživatel. Potřebuju, aby to fungovalo. Cítím z toho intuitivně prostě problémy. Navíc já používám SecureBoot. Mně to takhle stačí. Ale je dobré vědět, že to jde. Netvrdím ale, že se to nemůže někdy hodit.
-
" Nicméně... Startovat tímto způsobem (viz. článek) Linux přímo na ZFS je sice zajímavé, ale já vám ti jsem nakonec rád za normální GRUB a EXT4. Je to prostě ověřené a funkční řešení a já jsem uživatel. Potřebuju, aby to fungovalo. Cítím z toho intuitivně prostě problémy. Navíc já používám SecureBoot. Mně to takhle stačí. Ale je dobré vědět, že to jde. Netvrdím ale, že se to nemůže někdy hodit."
Zvyk je železná košile. Mě přijde mnohem horší GRUB. Jeho konfiguráky sestavují přesložitělé skripty. Konfig samotný pak je uložen v adresáři /boot/grub2/grub.cfg jednoho ze systémů. Tedy grub má vždy jednu instalaci linuxu jako domácí, která když se smaže, tak nic nenastartuje. Jestli se tahle nepříjemná defaultní vlastnost dá nějak ohnout a kolik to dá práce, netuším.
ZfsBootmenu nepotřebuje žádný konfigurační soubor. Pokud bych chtěl nějaký speciální parametr pro bootování, mohu to nastavit pomocí ZFS properties při u zfs datasetu.
Např.
zfs set org.zfsbootmenu:commandline="quiet loglevel=3" zroot/ROOT
Lze toho nastavit hodně, ale protože jsou vhodně zvolené default hodnoty, zpravidla to není potřeba.
Defaultně se nastavuje jen tohle, což je součást toho návodu.:
zfs create -o mountpoint=none zroot/ROOT zfs create -o mountpoint=/ -o canmount=noauto zroot/ROOT/${ID} zfs create -o mountpoint=/home zroot/home zpool set bootfs=zroot/ROOT/${ID} zrootPomocí properties bootfs nastavím, co má bootovat defaultně, pokud si nevyberu něco jiného. To -o canmount=noauto se nastavuje jen dočasně pro dobu instalace, nakonec se to zruší, aby bylo možné při instalaci použít dočasně jiný mount point.
Může to vypadat jako nějaká magie, ale přitom je to mnohem čistší způsob, než kterým to stejné dělat GRUB.
A úplně nejlepší je instalace a aktualizace ZFSBootMenu, která spočívá v pouhém stáhnutí jediného souboru s obrazem ZFSBootMenu, který prostě umístím do UEFI oddílu.Za mě ZFSBootMenu je jeden z důvodů proč dát přednost ZFS před Btrfs. Umožní vám to zbavit se GRUBu. Je to prostě ta jednoduchost, co je běžná ve FreeBSD. Návod může vypadat ošklivě, ale pokud si jej projdete, nic ošklivého nebo co by bylo snadné nějak pokazit tam není.
5. 11. 2026, 17:40 editováno autorem komentáře
-
To je fakt supr používání vše při každým startu zadávat ručně. To ocení opravdu každý, nejvíce BFU.
Pro přehled stejně potřebujete vědět, co se má kam namountovat. ZFS má mnohem pohodlnější způsob než je fstab.
Pokud nenastavíte zpool set bootfs=zroot/ROOT/${ID} zroot, předpokládám, že vám dá ZFSBootMenu vybrat při každým startu.
6. 11. 2026, 11:16 editováno autorem komentáře
-
Ad GRUB a jeho konfigurace přes složité scripty - tak to funguje na Debianu. Já si GRUB buildím ve FreeBSD, zcela odděleně, bez vazby na operační systém. Instaluji ručně, grub.cfg píšu ručně. Dnes by ho asi mohl napsat LLM. Je to jednoduché a přímočaré. Moduly a grub.cfg leží na vyhrazené UFS2 partition, změny dělám a celé to spravuji z FreeBSD. Pokud bych do GRUB image přilinkoval modul pro ZFS, asi by mohly ležet na datasetu. To jsem ale nezkoušel, protože to používám v podstatě v embedded prostředí, kde je max. 512MB RAM a ZFS tam nepoužívám.
-
Multiboot. Je to laboratorní prostředí a bootuji různé verze FreeBSD i Linuxu. Ale i na produkčním serveru, kde je výhradně FreeBSD, mám GRUB, protože mohu bootovat různé verze a také používat nástroje v GRUBovském CLI. A je to starší, nonEFI hardware. Na mnoha jiných strojích, převážně vm, zase mám pouze BSD loader.
-
Moc děkuju za vyčerpávající reakci! A nemyslím to tak, že já bych z ní byl vyčerpán. Asi jste mě zlomil, že si to budu muset vyzkoušet alespoň ve virtuálu. Pravdou je, že jsem nikdy s GRUBem nic složitějšího neřešil. Maximálně ho občas přegeneruju, když je třeba, do konfiguráku jsem taky asi jednou něco ťupnul, ale vlastně ho téměř nechávám, jak je. A máte pravdu, je to ta železná košile. Nicméně kdybych seznal, že je boot do ZFS lepší řešení z hlediska udržitelnosti (už stávající řešení mi totiž přijde vlastně skvělé proti tomu, na co jsem byl ještě nedávno zvyklý), možná to pak opravdu udělám. Neříkám, že by se mi nelíbilo ZFS na systémovém disku mého Mintu... V tom případě bych použil přesně tento váš článek. Pro mě je důležité toto: Nechci systém znovu instalovat, protože jsem extrémně zabydlen. :-)
-
Deduplikacia na btrfs je osemetna tema. Su na to tooly a nejak to aj asi funguje, ale ja osobne som to opustil z roznych dovodov. Jednym z nich napriklad je, ze deduplikacia nefunguje na readonly snapshotoch. A readonly snapshoty potrebujete, pokial chcete pouzivat inkrementalne btrfs-send/receive a dumpovat snapshoty na iny stroj (backup). Ja som s tym bojoval dlhu dobu, vymyslal rozne ojeby ako to spravit nejak rozumnejsie, dokonca som si nascriptoval backup script tak, ze ako readonly drzal vzdy len posledne 3 snapshoty (aby slo v pripade pruseru pohodlne nadviazat zalohu inkrementalne) a historicke snapshoty som prepinal pred deduplikaciou do readwrite atd... Nakoniec som po roznych problemoch usudil, ze mi to za tych usetrenych 200 GB (to je zhruba to, co dokaze moja zena narobit rozkopirovavanim fotiek do roznych albumov a podadresarov) nestoji a deduplikaciu na hlavnom storage som opustil. Opustil som nakoniec aj zalohy pomocou snapshotov a presiel najprv na par rokov na borg - a v sucasnosti prechadzam na restic (kvoli potrebe zalohovat do exotickych cloudov (google)). Oba tieto tooly maju deduplikaciu, takze sice nesetrim miesto na primarnom storage, ale aspon na zalohach.
Spomnalo sa sifrovanie - to sa priznam ze je u mna neprebadana oblast a je mozne a asi aj vysoko pravdepodobne, ze toto bude mat zfs vyriesene lepsie.
5. 11. 2026, 20:44 editováno autorem komentáře
-
"Deduplikacia na btrfs je osemetna tema"
Ne, neni ..."Su na to tooly a nejak to aj asi funguje"
Zjevne nemas nejmensi paru o tom, jak to (ne)funguje.Ty tooly zadnou deduplikaci nedelaji. Je uplne jedno jakej pouzijes. Delaji jen to, ze ruznymi zpusoby hledaji identicky bloky, a pak reknou fs (btrfs) at je zdeduplikuje. S tim jestli je snap RO nebo RW to nema zhola nic spolecnyho.
Deduplikaci je pak uplne jedno kde mas jakej snap nebo subvolume ... probehne vramci tech oznacenych bloku dat pres cely fs.
A samozrejme, deduplikovat snapy typicky nedava zadnej smysl, protoze to jsou jen zmeny. Tudiz to deduplikovano je tak nejak od prirody.
-
Proč je helso pro šifrování disku uložené /etc/zfs/zroot.key ?
Dnes jsem opět postupoval podle mého vlastního návodu (těchto článků) a narazil jsem na to, že mi to nechtělo po přesunu na jiný stroj bootovat. A během bootování to psalo:
Disabling Lock debugging due to kernel taint zis nodule license taints kernel. Key load error: Incorrect key provided for 'zroot'. Command: mount.zfs-o zfsutil zroot/ROOT/debian /root//Message: zfs_mount_at() failed: encryption key not loaded Error: 2 Failed to mount zroot/ROOT/debian on /root//. Manually mount the filesystem and exit. BusyBox v1.37.0 (Debian 1:1.37.0-6+b9) built-in shell (ash) Enter 'help' for a list of built-in commands.
Udělal jsem dvě chyby:
Editoval jsem soubor /etc/zfs/zroot.key editorem vim, který za heslo přidal jeden neviditelný znak, tedy heslo bylo ve skutečnosti jiné, než jsem předpokládal.
Druhá chyba byla, že při změně hesla se musí nechat znovu vygenerovat initramfs. To heslo se totiž kopíruje do všech bootovacích obrazů. Proto při jeho změně je potřeba provést a je nutné initrd obrazy nechat znovu vygenerovat. Je to v návodu, ale nebylo mi zřejmé proč se to vlastně dělá. https://docs.zfsbootmenu.org/en/v3.1.x/guides/debian/uefi.html#rebuild-the-initramfs
lsinitramfs /boot/initrd.img-6.12.115+deb13.1-amd64 | grep zroot.key etc/zfs/zroot.key
update-initramfs -c -k all update-initramfs: Generating /boot/initrd.img-6.12.113+deb13-amd64 update-initramfs: Generating /boot/initrd.img-6.12.115+deb13.1-amd64
Proč to tak je? Zjevně není snadný a bezpečný způsob, jak by mohlo ZFSBootMenu předat heslo bootovacímu procesu. Heslo v plaintextu /etc/zfs/zroot.key a ve všech obrazech je zabezpečeno jen tím, že jej smí číst jen uživatel root. Heslo je uloženo na samotném zašifrovaném disku, tedy např. pokud ztratíte notebook, zůstane chráněno. Je dobré si být této nedokonalosti vědom a při změně nechat znovu vygenerovat bootovací obrazy.
-
panikaStříbrný podporovatelmuzes prosim nejak vic rozebrat to s tim vimem? ja pouzivam neovim a tohle rozhodne nedela, brzo bych na to narazil...
-
Tak je to trochu jinak. Ten znak navíc je ASCII 0x0A is Line Feed (LF)
a můj vim v Debianu i defaultní vim v live Debianu ho tam opravdu přidá nakonec.
Nicméně ZFS tento znak nevadí a ignoruje ho, protože jej vytoří i echo, které mají v návodu. Tedy jediná příčina proč to nebootovalo byla,
že jsem po změně hesla nevytvořil nový bootovací obraz kam se heslo kopíruje.Ten znak tam ale bývá, ale zjevně většinou ničemu nevadí. Rozumné je ho ignorovat, aby heslo bylo opravdu to, co je vidět, když ne jinak tak alespoň odskočením kurzoru.
echo 'SomeKeyphrase'>/tmp/heslo.txt od -An -tx1 /tmp/heslo.txt 53 6f 6d 65 4b 65 79 70 68 72 61 73 65 0a vim /tmp/heslo2.txt od -An -tx1 /tmp/heslo2.txt 61 68 6f 6a 0a
-
ČLÁNKY DO MAILU