Btrfs vs ZFS – srovnání pro a proti (diskuse)

[AsciiWolf]

Skvělé srovnání! Tohle by si zasloužilo vyjít jako článek.

[miki.lbc]

+1

[Sváťa Pátek]

To ho redakce nemůže ocenit, pokud to nemá mezi Články?

[Cohen]

Na článek se to IMHO nehodí, není tam žádný rozumný širší úvod atd. Jsem dostatečně oceněn tím, že se to dostalo do výběru kvalitních linuxových blogpostů, má to solidní skóre v dobré:špatné hodnocení od čtenářů a kladné ohlasy v diskusi.

[Josef Kufner]

To je jeden odstavec navíc, kde řekneš, pro jakého čtenáře to je a co se od něj očekává za znalosti. Není nic špatného na odborném článku, kterému většina lidí neporozumí, neboť neznají to, o čem je. (Špatné by bylo, kdyby mu neporozuměli ani ti, pro které je určen.)

[Heron]

+1

[Michal Kubeček]

Anketa by byla zajímavější, kdyby tam byla i možnost "něco jiného". Kdyby mi někdo držel pistoli u hlavy, že si z těch dvou musím vybrat, tak bych tam holt BtrFS dal, ale zatím jsem se u svých systémů mohl rozhodovat svobodně, takže nikde není.

Ale i pak by ta otázka byla příliš obecná. Odpověď totiž může silně záviset na tom, k čemu a jak má být ten filesystém využíván.

[Sváťa Pátek]

Na druhou stranu, uživatele nízkolatenčních desktopů, to stejně nezajímá, protože třeba takové snapshoty berou spoustu výkonu. Uživatelé OpenSUSE 13.2 (btrfs default) proto používají raději EXT4.

[Jendа]

Nepřijde mi, že by btrfs snapshoty nějak zpomalovaly, ale nemám to na žádném stroji s extrémní I/O zátěží.

[Cohen]

Uživatelé OpenSUSE 13.2 (btrfs default) proto používají raději EXT4.

Tak to se uvádím jako protipříklad, openSUSE používám dlouhá léta na všech svých linuxových ne-serverových strojích a s Btrfs jsem tam začal s radostí experimentovat ještě (tuším o verzi) před tím, než se z něj stal defaultní filesystém.

Nevím, co přesně je myšleno vlivem snapshotů na výkon. Napadají mne jen dvě věci:

• Pořízení snapshotu samotného – to je prakticky zadarmo a téměř ihned. A v průběhu práce s filesystémem Btrfs tak jako tak dělá copy-on-write. Jestli při změně bloku odkaz na původní blok označí za volný nebo ne, protože je součástí snapshotu, to je prakticky jedno. Tj. pokud bylo myšleno toto, tak je to problém Btrfs jako takového (zejména CoW, jako základního principu jeho fungování), nikoliv konkrétně snapshotů.
• Vyrábění snapshotů při aktualizacích balíčků a změnách konfigurace systému – tohle už asi trošku zdržovat může, protože Snapper, který se k tomu používá, musí provést nějaké operace navíc, než jen samotné udělání snapshotů. To se ale děje jen sem tam (jen když se aktualizuje systém/něco mění přes Yast apod.) a navíc je to z mého pohledu stejně naprosto zanedbatelná cena v porovnání s tím, že můžu extrémně snadno rollbacknout nepovedené aktualizace systému, podívat se, co se kdy měnilo v konfiguraci atd.

[Sváťa Pátek]

Měl jsem to na plotnovém disku 7200ot/m. Ano ten pokles výkonu byl vždy kdy se spustil Snapper (dost často) a mluvil jsem o nízkolatenčním desktopu, třeba jsem sledoval tv a při této činnosti vypadával obraz někdy i zvuk. Takže kdybych chtěl něco (film) nahrát mohl bych to poté hned smazat. Když jsem spustlil snapper gui a chtěl tam něco vidět obě cpu 2x2.4GHz byly na 100%.

[Heron]

Jestli při změně bloku odkaz na původní blok označí za volný nebo ne, protože je součástí snapshotu, to je prakticky jedno.

Není to jedno z hlediska fragmentace toho souboru. Pokud se soubor mění často, tak alokátor může ten blok umístit vedle (zvýší se fragmentace) a při jeho dalším update zase na původní místo (sníží se fragmentace). Pokud je původní blok stále odkazován z nějaké jiné kopie (reflink, snapshot), tak při dalším update musí mají další volný blok (který už může být na disku o hodně dál, než původní bloky souboru). (Jestli to takhle btrfs dělá nevím, takto se to někdy dělá v multigeneračních db.) V praxi potom pozoruji, že subvolume se snapshoty se updatuje o něco pomaleji, než sub bez snapshotů. (Což ale může být dáno i něčím jiným, alokátor může mít problém najít volné bloky.) Není to nijak významné, ale lze si toho všimnout. (A to se bavíme o sub, která má několik tisíc snapů a updatuje se poměrně často, takže těch kopií bloků tam bude hodně.)

navíc je to z mého pohledu stejně naprosto zanedbatelná cena

Asi tak.

[Heron]

Skvělý článek!!!

Flexibilita zmenšování úložiště

U mě před lety vyhrálo BtrFS nad ZFS právě z důvodu flexibility multidevice. Přidat, odebrat, kdykoliv, cokoliv (s podmínkou aktuálního typu raidu a volného místa).

Chystám se ještě na obecný potlach o "dokonalém" fs (z mého pohledu). Co bych velmi u btrfs ocenil by byla možnost vybrat si raid profil per subvolume. ZFS má tohle přesně naopak, tam je raid definován pro vdev, který se jako celek strká do zpoolu. Ale já bych rád FS, který disky bere jen jako "skladiště bloků" a redundanci si řeší tak, že bloky souboru umístí na příslušný počet zařízení. Takže mít subvolume typu raid1, raid0 apod. Nevím, jak daleko od toho btrfs je, toto už dnes v podstatě platí pro celý fs (za běhu lze měnit raid profil celého fs, to znamená, že během této operace jsou některá data uložena dle starého profilu a některá dle nového - a je to zcela konzistentní). Snad by nemuselo být tak těžké implementovat profil per subvolume (i když ten multidevice alokátor bloků různých profilů bych teda psát nechtěl).

[Filip Jirsák]

Jak je to s tou odolností proti výpadkům? Když se data rozdělují mezi jednotlivá VDEV, při výpadku jednoho VDEV stejně přijdu o bloky na něm uložené. Podle mne je ta pravděpodobnost ztráty dat stejná pro btrfs i ZFS – rozdíl je jenom v tom, že u ZFS je sice nižší pravděpodobnost, že vůbec přijdu o nějaká data, ale když už o ně přijdu, bude jich víc, než u btrfs. Třeba u ZFS je pravděpodobnost 1/x že přijdu o 1/y dat, zatímco u btrfs je pravděpodobnost 2/x, že přijdu o 1/2y dat. Nebo jsem něco přehlédl?

[Sten]

Rozdíl je v tom, že v rámci jednoho VDEV proběhne synchronizace mnohem rychleji, než když se dělá synchronizace nad obrovským RAIDem, takže se netráví mnoho času v degradovaném stavu, kdy hrozí fatální selhání druhého disku.

[Aleš Kapica]

ZFS je prasopes. Tím mám na mysli, že se snaží řešit bloková zařízení i souborový systém současně. Jenže otázka zní: Jaký má smysl používat jednu a tu samovou věc na všechno, když si bloková zařízení mohu řešit přes LVM a souborový systém zvlášť?

Je to čistě o osobních preferencích. Já preferuji aplikace, které nejsou všeobjímající, ale snaží se pokud možno maximálně dobře to co dělají. Je pak totiž mnohem snazší odhalit problémové místo. A také lze situaci mnohem flexibilněji řešit.

[Michal Kubeček]

Taky mám radši univerzální řešení, ale v tomhle případě má integrace své výhody, např. u snapshotu na úrovni blokového zařízení nelze garantovat, že bude obsahovat konzistentní obraz filesystému. U takového RAIDu už jsem ale o vhodnosti implementace na úrovni filesystému přesvědčen výrazně méně.

[Václav Vanc]

RAID tam musí být integrován, kvůli opravě dat při špatném kontrolním součtu.

[Jendа]

Ne, stačilo by, kdyby FS uměl blokovému RAIDu říct, že tohle je špatně, a jestli nemá druhou kopii. Nebo by checksumy mohl řešit rovnou blokový RAID, jako to má IBM v AS400.

Mimochodem už jste někdo viděl nějakou silent data corruption, pokud možno na počítači s ECC?

[Cohen]

Mimochodem už jste někdo viděl nějakou silent data corruption, pokud možno na počítači s ECC?

Právě že možná viděl...

[Jendа]

Na non-ECC počítači bych už nevěřil ničemu…

[Cohen]

Před chvílí jsem četl tohle, a řeknu vám, ta čísla tam uváděná jsou děsivá. Docela žasnu, že běžné desktopy a notebooky bez ECC RAM vůbec nějak fungují.

Do příštího desktopu se budu snažit dostat ECC paměť, ale bojím se, že to narazí hlavně na omezeném výběru desek. :-/ U notebooku je to prakticky marné (krom pár modelů superdrahých mobilních pracovních stanic).

[Grunt]

Ono obecně jak to jde s produkční kvalitou médií stále víc a víc z kopce bych se vůbec nedivil kdyby procesor měl třeba na add <1>, 1 jednou za milion instrukcí povoleno vrátit třeba 3. A nebo taky -2147483648. To bych asi bral radši ten co vrací na 1+1 ty trojky

[Heron]

Takových děsivých čísel po světě chodí.

Hromadu let kontroluju svá data přes sha512 (jak šel čas tak přes různé fce) a zatím přesně 0 změn. Dlouho na FS typu extX, potom XFS (takže bez vlastního csum), teď 5 let btrfs. Objem dat postupně roste, aktuálně něco přes 10TB. Za nějakých už skoro 15 let vůbec nic.

Co se týče ECC, na serverech máme pochopitelně jen ECC, hodně přes 1TB RAM celkem a chyby z ECC chodí tak 3x do roka vždy jen z jednoho modulu, který dřív nebo později odejde (resp. naopak: pokud chodí chyby ECC, tak to zatím vždy znamenalo chybu modulu paměti).

Doma ECC nemám, btrfs křičelo chyby csum jen jednou a memtest okamžitě odhalil vadnou ram (takže díky btrfs jsem na to přišel relativně rychle, modul vyměnil a data zkontroloval proti záloze).

CPU zahlásil ECC chybu za poslední 3 roky jen 2x (L3 cache).

Takže tak. Chápu, že zkušenosti z řádů desítek TB diskového prostoru a jednotek TB RAM se (obzvláště na českém fóru) mohou zdát směšná, ale nám ten HW stačí.

Tohle je spíš návod jak k tomu přistupovat. Hlášení ECC chyb mnohem víc než jako systém pro korekci dat funguje jako včasné varování, podobně jako smart u disku. Pokud se objeví první ecc chyba (nebo první realocated sector), je na čase ten hw vyměnit a na nic nečekat.

[pasky]

Že ta čísla nedávají žádný smysl snad potvrdí každý, kdo si nově koupený počítač či RAMky pravidelně testuje několik hodin až dní memtestem.

Mýtus pochází z jednoho známého paperu "z Google" (i když hlavní autor z Google není), který není moc dobrý (resp. z naměřených dat nedochází ke správným závěrům) - http://research.google.com/pubs/pub35162.html. Problém je, že ta studie je dělaná nad ECC DIMMkami a naivní čtenář si přečte, že pokud pro ECC DIMMky platí, že "our per-DIMM rates of correctable errors translate to an average of 25,000–75,000 FIT (failures in time per billion hours of operation) per Mbit," je to zároveň počet chyb, které se odehrávají na DIMMkách, které ECC nemají!

Takové paměti jsou ale k ničemu a evidentně to nemá žádný odraz v realitě. Když jsem spravoval síť několika desítek pracovních stanic, ECC DIMM jsme nepoužívali, ale každou novou stanici či server jsme nechali memtestovat 3-7 dní (stejně se nakupuje před Vánoci :) a v případě chyby se šlo na reklamaci (tak 10% případů). To bychom moc počítačů neměli...

Jaké je alternativní rozuzlení? Že QA u ECC DIMM projdou i ty trochu vadné, pokud dělají konzistentně opravitelné chyby, zatímco ne-ECC DIMM neprojdou.

Výhoda ECC tedy spočívá v tom, že pokud už se chyba stane, dozvíte se o tom (a s tím může být přeci jen spojená trochu menší frekvence neopravitelných chyb, ale rozhodně ne tak výrazná).

[Jendа]

A já se divil když jsem tam nedávno přišel a vypadalo to, že staví memtest cluster

každou novou stanici či server jsme nechali memtestovat 3-7 dní

Nemůže se ta chyba projevit jen tehdy, když se to zapíše, nechá chvíli odležet, a pak přečte? Přičemž memtest zapisuje a čte menší bloky.

Jinak já se u non-ECC počítačů nebojím ani tak náhodných chyb občas, jako spíš toho, že od náhodných bitflipů ke spuštění memtestu většinou vede spousta debugování ve skutečnosti funkčního softwaru.

[Michal Kubeček]

Nemůže se ta chyba projevit jen tehdy, když se to zapíše, nechá chvíli odležet, a pak přečte? Přičemž memtest zapisuje a čte menší bloky.

Vzpomínám si, že memtest míval i nějaký "decay" test (defaultně se nespouštěl), kde se IIRC popsala celá paměť, pak se 90 minut nedělo nic a potom se obsah zkontroloval.

[alkoholik]

A studii o ovlivnovani sousednich bitu znete?

[Jendа]

Ano, a nový memtest tohle zkouší taky (test se jmenuje Rowhammer).

[Grunt]

Tohle jsem nějak minul a možná se od posledně něco změnilo ale nevisí náhodou u btrfs takový obří červený rámeček a ještě vykřičník nebo dva v něm s nápisem: „Btrfs je vývojovém stádiu! NEPOUŽÍVEJTE BTRFS NA PRODUKČNÍM SYSTÉMU POKUD NECHCETE PŘIJÍT O DATA!“ nebo tak něco?

[Cohen]

Tak strašné už to není. V Btrfs Wiki je psáno:

The status of btrfs was experimental for a long time, but the the core functionality is considered good enough for daily use.

Ano, doporučuje se mít poslední kernel, a je tam zdůrazněné mít zálohy a být připraven je použít, to ale snad platí vždy, ne?

Taky pomalu roste počet „produkčních“ uživatelů.

Výše popsané tedy rozhodně nepovažuji za něco, co by Btrfs neměl přežít (a však to taky data nijak neohrozilo).

[Grunt]

No já jen že se stejnou chybou jsem se setkal taky když jsem si jen tak z radosti testoval Btrfs na flash disku. Systém šlapal jak hodinky, najednou z ničeho nic corrupted data na disku, za chvíli ještě víc chyb, zpanikařilo jádro, po pokusu data obnovit jsem se dostal do situace kdy jsem to radši celé naformátoval a vrátil si zpět ext4 který bez problémů fungoval nějaký ten další rok. Přisoudil jsem to vlastní blbosti, protože ty obří červené rámečky na možnost tohoto chování tam opravdu jsou.

[Sten]

Ne, je tam, že má některé vlastnosti, které jsou ve vývojovém stádiu (např. paritní RAIDy), pokud je nebudete používat, je btrfs (s dostatečně novým jádrem) stabilní.

[Roger]

Nevím, jestli se to počítá jako "silent data corruption", ale mně už takhle btrfs v RAID1 zachránilo data, když přidání testovacího disku rozhodilo ty existující a začala se poškozovat data.

Všiml jsem si toho v kernelovém logu, kam si btrfs stěžovalo (a vzniklé problémy řešilo přes kopii dat v onom RAIDu).

[Jendа]

Poškozovat jakým způsobem?

[Roger]

Pokud mi pamět slouží, chyby při čtení - neseděly checksumy.

[Cohen]

Nehlásil ovšem chyby už disk, tj. nebylo z logu poznat, že došlo k chybě čtení z hardware? Nebo to opravdu chytal až Btrfs přes nesedící kontrolní součty?

[snajpa]

Jo, vcelku bezna vec - aspon na zaloznim poli, kde uz je nejakych 40 3TB disku, 2-3 bloky za cca pul roku.

[Jendа]

A to fakt přečte jiná data a nehodí to žádnou chybu?

To pole je SATA přímo do počítače, a je tam ECC?

[Jendа]

Nešlo by, prosím prosím, přidat do jaderného modulu, že to kromě chyby vypíše i hexdump toho bloku? fakt by mě zajímalo, jestli jsou to flipy jednoho bitu, nebo je třeba celý blok nulový.

[snajpa]

To je zajimavy napad, az se v tom budu zas vrtat, zkusim se podivat, kam by se to dalo placnout. Nejaky vhodne umisteny printk() by mohl stacit. Jinak jsou to asi nejvetsi sh*t disky, co jsem potkal od WD - RED edice, 3TB kapacita, pres SAS2 expandery pripojeny na SAS2 PCIe HBA k jednomu z dvou socketu. Jsou tam ECC DDR3 pameti.

[Michal2]

Já zatím čekám. 8 kusu 3TB WD RED v RAIDZ2, zaplněno 14TB, 3 roky, scrub každý měsíc. Doposud 0 odhalených chyb. Statisticky by jich už mělo být spoustu (unrecoverable error rate 10^14).

[trekker.dk]

např. u snapshotu na úrovni blokového zařízení nelze garantovat, že bude obsahovat konzistentní obraz filesystému

Jaktože ne? Filesystém se dá ručně zmrazit a podle manuálové stránky fsfreeze to dokonce LVM dělá automaticky, když se po něm chce vytvoření snapshotu.

[cezz]

Oprav ma ak sa mylim, ale pokial viem toto silno zavisi na podpore konkretneho filesystemu, cize nie kazdy FS vie LVM takto zmrazit.

[trekker.dk]

To jasně, ale třeba ext4 a xfs (které - hádám - mají na Linuxu docela velký podíl) to umí.

[Sten]

Až na FAT to umí snad každý. Snapshot na úrovni blokového zařízení je totéž, jako když vypadne proud. Každý moderní souborový systém se s tím umí vyrovnat tak, aby zůstal konzistentní.

[cezz]

Crash consistency a fsfreeze su dve odlisne veci. Ale inak mas pravdu, vacsina beznych FS fsfreeze podporuje.

[VSi]

Jaký má smysl používat jednu a tu samovou věc na všechno, když si bloková zařízení mohu řešit přes LVM a souborový systém zvlášť?

LVM snapshoty jsou výkonnostně nepoužitelné. Jak mdraid tak LVM neumí pracovat s informací o neobsazeném místě (mohlo by to asi fungovat přes TRIM, ale není to tam). RAID zas dokáže těžit z kontrolních součtů, pokud o nich ví.

Velkou část věcí by asi šlo nějak vyřešit i přes oddělené vrstvy, ale integrace přináší výkonnostní a implementační výhody.

[Aleš Kapica]

A kdo tady psal o snapshotování na úrovni LVM? Jednak jak správně píšeš, je to výkonostně pro kočku a pak - je to zbytečné.

[Jindra]

GNU GPL kód Btrfs je mnohem příjemnější,

... jestli na ZFS založí svůj produkt,

Z uvedeného myslím jasně vyplývá, že Btrfs i ZFS mají svoje silné a slabé stránky. Jako obvykle tedy musíte zvážit svoje potřeby, vybrat vhodnější řešení a vypořádat se s jeho omezeními.

[Heron]

Pokud vím, tak se ZFS není dobře integrovatelný s linuxovým VFS

To někdy ani btrfs. Pokud je subvolume s daty, udělá se její snapshot (takže subvolume a její snapshot vede na zcela stejné bloky), tak při čtení subvolume a následně jejího snapshotu se ty bloky čtou z disku znovu (nedostanou se do žádné iocache, resp se tam dostanou 2x - jednou pro tu subvolume a podruhé pro snapshot - pokud je dostatek paměti).

Toto není problém při běžném používání, ale pokud někdo intenzivně pracuje napříč snapshoty (které se příliš nemění, takže souboru odkazují na tytéž bloky), tak je to mnohem pomalejší, než by to mohlo být. Stejně tak (nepřekvapivě) pro kopie pomocí reflinků.

[Cohen]

Díky, přidal jsem do textu odkaz na ukázku z minula.

[integrace s OS]

Krom domovského Solarisu je ZFS dobře integrováno (už dlouho) třeba do FreeBSD (údajně, na zdrojáky sem nekoukal). FreeNAS je tuším postaven nad FreeBSD (a lidi zhusta ZFS ve FreeNASu používají).

[Adam]

Nevíte jak je to s výkonem a podporou pro SSD? Vím, že SSD mívaly problémy se zápisem a čtením velkého množství malých souborů. Je tu nějaký pozorovatelný rozdíl?

[Sten]

Nevím, jak je to u ZFS, ale btrfs podporuje TRIM, COW je obecně mnohem příjemnější pro SSD disky než přepisy in-place, malé zápisy jsou clusterované, čtení nepoužívá optimalizace seeků a velké množství malých souborů řeší tím, že malé soubory jsou uloženy v bloku se svými metadaty.

[Adam]

To tak nějak souhlasí s mým hrubým odhadem situace :)

[snajpa]

ZFS ma jine cile, nez BTRFS. ZFS chce byt storage system, ne filesystem. Cili si resi i svoje cachovani, scheduling IO operaci a dalsi veci. BTRFS v tomhle zustava pri zemi, pokud vim. A nejlepsi je, ze se ZFS nesnazi s BTRFS soutezit, chlapci proste delaji svoji vec a neresi, co si kde linuxaci matlaji po svem s jejich typickym vyvojovym modelem. Vyvojari ZFS resi efektivni ukladani a manipulaci se stovkami TB dat v nejruznejsich hierarchiich. ZFS vzniklo na zaklade potreby ukladat data, BTRFS je historicky hracka cmasona nad modifikovanymi B stromy, z ktere chtel vytriskat featury, ktere linuxaci zavideli ZFSkarum. Pro nejblizsich X let verim OpenZFS a jeho vyvojarske bazi. BTRFS planuju zkusit (a tim nemyslim na jednom disku) az tak v RHEL 8.

[Aleš Kapica]

Řešit storage v rámci jednoho fyzického stroje je přežitek. Budoucnost mají distribuovaná úložiště. A pro ně je vyvíjený jiný prasopes - Ceph. A pro účely distribuovaného úložiště je vhodnější mít na těch nodech Btrfs, než ZFSm protože je flexibilnější. Distribuované systémy totiž mají datové objekty uloženy jako soubory.

[snajpa]

Zrovnatak, jako nikdy nebudu pouzivat Docker, protoze je zrovna hyper in a cool, nebudu pouzivat ani ty object story, ktere jsou podle tebe budoucnost. Stackovat takhle vrstvy nad sebe, delejte si to kdo chcete, ale mne z toho vynechte, ja maximum, co jsem ochotny prijmout, vidim na DRBD. Urcite ne filesystemy, ktere jsou rozdelene na soubory a ulozene na dalsich filesystemech. A uz vubec ne puvodem linuxove FS, pac saji vsechny do jednoho.

[snajpa]

A uz vubec ne Gluster, abych jeste lital 40x pres userspace, kdyz chci dostat data. Muj pozadavek je, aby to, co postavim ted, bylo pouzitelne i s NVMe SSD. Gluster neni ani zda-le-ka. A malo co je, jedine svetlo na konci tunelu aktualne vypada byt DRBD 9. Cekam na 40GE a IB QDR karty, abych si to mohl poradneji osahat.

[Aleš Kapica]

Pleteš si jabka s hruškama. Není jenom GlusterFS. Nad jedním fyzickým strojem rychlé úložiště s kapacitou v petabajtech prostě nepostavíš.

[snajpa]

Prd si pletu. Ty mi vnucujes use-case, ktery nemam. Ja chci clustered storage pro kontejnery, kontejnery chci mit nad ZFS protoze XY duvodu a na to potrebuju distribuovany block storage. Neco, co mi da blockdev ve finale, nad kterym muzu jet ZFS. DRBD. Nebo co chlapci ze SUSE vymysli s network RAIDem, az se dostanou k implementaci 5/6, to by mohla byt sranda. Ty tvrdis, ze co resi ZFS/BTRFS stejne neni relevantni, protoze ~cca kazdy bude chtit ukladat distribuovane PB dat idealne po velkych souborech. Ja to tedy vidim uplne jinak, ja potrebuju ukladat stamiliony malinkych souboru a mit k nim pristup tak rychly, ze nepoznam, jestli je to pod na siti nebo ne. Da se to udelat, ale ne s nicim, co tu prohlasujes za budoucnost ukladani dat.

[Aleš Kapica]

V neděli by ses mohl dozvědět víc. Mám s DRBD několikaleté zkušenosti, a cestu kterou chtějí prošlapat chlapci ze SUSE jsem prošel ještě předtím, takže vím, že to nemá budoucnost.

[snajpa]

Urcite se prijdu podivat, tesim se

[Aleš Kapica]

Jo a Linbit znovu vymýšlí kolo. Koukni se na Sheepdog a Accelio.

[trekker.dk]

ja maximum, co jsem ochotny prijmout, vidim na DRBD

Jo tak to bych zrovna teď nejradši vzal a vyhodil z okna. Náhodné vytuhnutí drbdsetup v kernelu na 10 minut fakt nepotěší.

[melkors]

Dovolil bych si upozornit take na SheepDog - sice jeste neprosel do stable, ale konce brezna by melo byt 1.0-rc0

[kralyk z abclinuxu]

V Btrfs je snapshot vlastně další podadresář (nebo možná spíše mountpoint) někde v adresářové struktuře. V ZFS běžně vidět není.

Snapshoty jsou v ZFS vidět pomocí zfs list -t snap nebo zfs list -t all.

Jinak jak je na tom btrfs s řízením, který uživatel může co dělat? Tzn. vytvářet subvolumes / snapshoty apod.

[Cohen]

V Btrfs je snapshot vlastně další podadresář (nebo možná spíše mountpoint) někde v adresářové struktuře. V ZFS běžně vidět není.

Snapshoty jsou v ZFS vidět pomocí zfs list -t snap nebo zfs list -t all.

Jasně, ale tady mi šlo o to, aby to bylo dostupné jako běžné soubory, které si prohlédnu libovolným programem pracujícím se soubory na disku.

Jinak jak je na tom btrfs s řízením, který uživatel může co dělat? Tzn. vytvářet subvolumes / snapshoty apod.

Tohle má možnosti jen triviální. Bez nahlédnutí do dokumentace: Každý uživatel smí vytvořit subvolume/snapshot, ale jen root ho smí smazat. Mazání snapshotů lze povolit i pro běžné uživatele přes mount volbu. Myslím, že nic další ani nakonfigurovat nelze (ale do dokumentace jsme nekoukal).

[Michal2]

Kazdy snapshot v ZFS je pristupny jako podasresar v (implicitne zcela skrytem) podadtresari /pool/subvolume/.zfs/snapshots

cd /data/virtual/.zfs

root@zfs:/data/virtual/.zfs/snapshot# ls
snap_daily-2016-02-23-0002   snap_hourly-2016-02-29-1601
snap_daily-2016-02-24-0002   snap_hourly-2016-02-29-1701
snap_daily-2016-02-25-0002   snap_hourly-2016-02-29-1801
snap_daily-2016-02-26-0002   snap_hourly-2016-02-29-1901
snap_daily-2016-02-27-0002   snap_hourly-2016-02-29-2001
snap_daily-2016-02-28-0002   snap_initial-2014-06-29-0003
snap_daily-2016-02-29-0002   snap_monthly-2015-03-01-0204
snap_hourly-2016-02-28-2101  snap_monthly-2015-04-01-0104
snap_hourly-2016-02-28-2201  snap_monthly-2015-05-01-0104
snap_hourly-2016-02-28-2301  snap_monthly-2015-06-01-0104
snap_hourly-2016-02-29-0001  snap_monthly-2015-07-01-0104
snap_hourly-2016-02-29-0101  snap_monthly-2015-08-01-0104
snap_hourly-2016-02-29-0201  snap_monthly-2015-09-01-0104
snap_hourly-2016-02-29-0301  snap_monthly-2015-10-01-0104
snap_hourly-2016-02-29-0401  snap_monthly-2015-11-01-0204
snap_hourly-2016-02-29-0501  snap_monthly-2015-12-01-0204
snap_hourly-2016-02-29-0601  snap_monthly-2016-01-01-0204
snap_hourly-2016-02-29-0701  snap_monthly-2016-02-01-0204
snap_hourly-2016-02-29-0801  snap_weekly-2016-01-31-0103
snap_hourly-2016-02-29-0901  snap_weekly-2016-02-07-0103
snap_hourly-2016-02-29-1001  snap_weekly-2016-02-14-0103
snap_hourly-2016-02-29-1101  snap_weekly-2016-02-21-0103
snap_hourly-2016-02-29-1201  snap_weekly-2016-02-28-0103
snap_hourly-2016-02-29-1301  snap_yearly-2015-01-01-0305
snap_hourly-2016-02-29-1401  snap_yearly-2016-01-01-0305
snap_hourly-2016-02-29-1501

Normalne to funguje. Fakt nechapu, proc v tom clanku pises takove veci. To klade dost vylky otaznik i na ostatni zjisteni.

[Cohen]

Ale vždyť to tam napsané je:

existuje skrytý adresář .zfs, který je ale ve výchozí konfiguraci ZFS skrytý více, než by člověk čekal, nevypíše ho ani utilita ls, i když se do adresáře dá vstoupit:

# ls -a /tank/test
./  ../  boot.tar  text.tar  text.tar.2
# cd /tank/test/.zfs/
# ls -a
./  ../  shares/  snapshot/
# zfs set snapdir=visible tank/test
# ls -a /tank/test
./  ../  boot.tar  text.tar  text.tar.2  .zfs/

Přes obsah .zfs se tedy asi člověk k jednotlivým souborům dostane, aniž by musel provést vyloženě rollback datasetu k danému snapshotu

[snajpa]

.zfs je skryty ve vypisu adresaru defaultne kvuli zalohovacim nastrojum. Jinak v nem taky funguje rmdir/mkdir na vyrabeni/mazani snapshotu.

[Bystroushaak]

V čem jsi to psal, že to máš tak pěkně naformátované?

[Cohen]

Bohužel musím zklamat, žádné pěkné automatické řešení – jen ruční práce + grep & vim pro výběr položek obsahu a jeho naformátování. :-/

[Bedňa]

Ale aj tak dík za prácu. Je veľa rozsiahlich blogov kde to človek spraí Tl;DR, ale tento fakt zaujal.

[Sten]

Snapshot není něco jiného než pododdíl, ale je to druh pododdílu, který vznikl jako snapshot jiného pododdílu místo jako prázdný strom (btrfs subvolume create) nebo z jiného souborového systému.

[kyknos]

To je jako vybírat si mezi shnilými fugu jatýrky a plesnivou kulajdou z Amanita phalloides.