Btrfs vs ZFS – srovnání pro a proti

29.2.2016 01:05 | Přečteno: 8837× | Btrfs | | poslední úprava: 18.5.2016 10:16

Jsem fanda Btrfs, ale zajímá mne i jeho hlavní soupeř – ZFS. Nedávno se objevily zprávičky o přípravě toho, aby bylo ZFS (i přes problematické licencování) snadno použitelné v Ubuntu a Debianu. To mne přivedlo na (skvělý!) tutoriál Aarona Toponce o ZFS na Linuxu. Na základě něho a ještě několika dalších zdrojů se mi zdá, že Btrfs je v mnoha ohledech navrženo flexibilněji a vhodněji, i když samozřejmě má i své nevýhody. V tomto zápisku tedy zkusím stručně shrnout pro a proti, která u Btrfs a ZFS vidím.

Upozorňuji, že dost možná budu zápisek čas od času aktualizovat, takže se text může v průběhu času mírně měnit.

Aktualizace

• 2016-05-18: Přidána poznámka o kompatibilitě.
• 2016-04-18: Přidána sekce o integrovaném šifrování.

Obsah ¶

• Použité zdroje
  • Btrfs
  • ZFS
  • Btrfs a ZFS
• Srovnání Btrfs a ZFS
  • Licencování – vítězí Btrfs
  • Flexibilita zmenšování úložiště – vítězí Btrfs
  • Odolnost proti výpadkům (více) disků – vítězí ZFS
  • Flexibilita nastavení RAID konfigurace – vítězí Btrfs
  • Rychlé kopírování/přesouvání dat přes CoW – vítězí Btrfs
  • Přehled o stavu úložiště a možnosti ladění jeho konfigurace – vítězí ZFS
  • Výkon – vítězí ?ZFS?
  • Práce se snapshoty a subvolumes – vítězí Btrfs
  • Integrované šifrování – vítězí ?ZFS?
  • Defragmenatace – vítězí Btrfs
  • Export blokových zařízení (ZFS Volumes) – vítězí ZFS
  • „Integrované“ sdílení přes NFS/Sambu/iSCSI – vítězí ?ZFS?
  • Integrace s Linuxem – vítězí Btrfs
  • Stabilita a prověření praxí a časem – vítězí ZFS
  • Kompatibilita – vítězí ZFS
• Závěr

Použité zdroje ¶

Na začátek bych chtěl sepsat hlavní zdroje, ze kterých jsem čerpal, a které by mohly být zajímavé pro zájemce o Btrfs a ZFS.

Btrfs ¶

• Btrfs Kernel Wiki.
• Heronovy zápisky o Btrfs.
• Vlastní zkušenosti.

ZFS ¶

• Tutoriál Aarona Toponce o ZFS (na Linuxu).
• Nex7's zápisek o ZFS Intent Log.
  • Popis je tam myslím přesnější a jasnější než v blogu Aarona Toponce.
• Finanční vyčíslení ceny deduplikace v ZFS.
  • TL;TR: až na velmi specifické „patologické“ případy se to IMHO nemůže nikdy vyplatit. Když se započtou další paměťové nároky ZFS, tak se může lehce stát, že pro 12 TB úložiště budete potřebovat 240 GB paměti...

Btrfs a ZFS ¶

• A short history of btrfs [LWN.net]

Srovnání Btrfs a ZFS ¶

Licencování – vítězí Btrfs ¶

V oblasti licencování je myslím situace poměrně jednoznačná – GNU GPL kód Btrfs je mnohem příjemnější, než CDDL kód ZFS. Canonical tvrdí, že kernelový modul zfs.ko není problém distribuovat v Ubuntu v binární podobě, ale spousta lidí je jiného názoru a Debian nabídne jen zdrojáky, i když tedy nachystané tak, aby je bylo možné snadno zkompilovat a ZFS použít.

Na druhou stranu je otázka, jestli i GNU GPL nemůže být problém pro portaci Btrfs na jiný systém (BSD nebo podobná licence by byla šířeji přijatelná). Vzato kolem a kolem – z licenčního hlediska pro mne vítězí Btrfs, který je bezproblémový minimálně na Linuxu. ZFS je sice už portované na více systémech, ale licence je IMHO s otazníkem všude a člověk by si tedy měl velmi rozmyslet, jestli na ZFS založí svůj produkt, protože pak může mít velké problémy s tím, jestli ho takto bude moci distribuovat.

Flexibilita zmenšování úložiště – vítězí Btrfs ¶

Co mne asi na ZFS zatím zklamalo nejvíce, to je malá flexibilita práce s úložištěm. U Btrfs není problém úplně volně přidávat a odebírat disky do úložiště (za plného provozu). U ZFS je možné disky přidávat a nahrazovat starší disky za nové (větší nebo stejně velké), ale není možné z úložiště zařízení odebrat! Jsou tam nějaké drobné výjimky u zrcadlených zařízení, ale s flexibilitou Btrfs se to vůbec nedá srovnávat.

Z mého pohledu to tedy vyžaduje hodně dobré plánování, jak bude úložiště i do budoucna vypadat. Pokud se jednou rozhodnete, že budete mít v úložišti šest disků, tak není problém později přidat další disky. Pokud se ale naopak stane, že vám jeden disk odejde a vy nebudete mít po ruce náhradní, tak u ZFS máte problém, pokud se nejedná o jeden z těch pár speciálních případů. U Btrfs byste disk jednoduše z úložiště odebrali a dál používali disků pět (samozřejmě za předpokladu, že na zbývajících discích máte dost místa pro všechna data a konfigurace úložiště [typ RAIDu] může fungovat s daným počtem disků).

V OpenZFS projektu se před časem objevil zápisek o implementaci odebírání zařízení v ZFS, ale nevím o tom, že by to bylo někde prakticky dostupné. V zápisku uvedený plán zařazení do mainstreamu se asi nerealizoval.

Jeden z inženýrů, který u Sunu několik let pracoval na ZFS, obecně označuje návrh Btrfs za vhodnější pro úložiště, než design ZFS, který vznikl dříve a vycházel z analogie správy virtuální paměti.

Odolnost proti výpadkům (více) disků – vítězí ZFS ¶

V předchozím bodu jsem kritizoval problémy se zmenšením ZFS úložiště, ale při zvětšování už není situace tak jednoznačná.

Pokud budete mít úložiště, které ze startovních např. 4 disků postupem času naroste na třeba 24 disků, tak u Btrfs jste z hlediska spolehlivosti limitováni dostupnými RAID konfiguracemi. Krom RAID1/5/10, který přežije výpadek jednoho disku, máte k dispozici jen RAID6, který přežije výpadek dvou disků (RAID5 a 6 je navíc v Btrfs stále relativně experimentální). Cokoliv jiného přímo z Btrfs nyní nemáte šanci dostat. U 24 disků už je docela nepříjemné spoléhat na to, že při výpadku jednoho disku už vám další disk neselže, než stačíte redundanci všech dat obnovit.

U ZFS by pravděpodobně růst probíhal jinak. Iniciální 4 disky by tvořily např. jedno VDEV v nějaké RAID konfiguraci. Další disky by se do ZFS poolu přidaly tak, že by se např. z dalších šesti disků udělalo další VDEV v RAID konfiguraci a přidalo do poolu, kdy by pak ZFS provádělo stripping přes původní a nové VDEV zařízení. Další růst by probíhal obdobně. Oproti Btrfs ale musíte u ZFS dávat pozor na použití stejně velkých disků, jinak nevyužijete jejich plnou kapacitu. Btrfs je v tomto mnohem gumovější.

Z toho plyne, že v případě ZFS je redundance zajištěna přes každé VDEV, výpadek jedno disku v prvním VDEV neomezí vůbec redundanci ve druhém VDEV. Selhané disky se nekumulují přes celé úložiště. Navíc ZFS poskytuje krom obdoby RAID5 (RAIDZ1) a RAID6 (RAIDZ2) i RAIDZ3, který toleruje výpadek 3 disků. Případně můžete dělat zrcadlené VDEV z libovolného počtu disků (tj. počtu kopií), které uznáte za vhodné.

Výše uvedené Btrfs neumí, tam si vyberete RAID konfiguraci, která platí pro všechny disky v celém poolu. Dělat tedy pool z hodně zařízení asi není v Btrfs zase tak moc dobrý nápad. Řešení by mohlo být, pokud by Btrfs umožňoval definovat např. RAID1/10 s tím, že se nebudou ukládat jen dvě kopie dat na dvou zařízeních, ale tři nebo více kopií na třech nebo více zařízeních. (Něco podobného ostatně ZFS umí v podobě ZFS Ditto Blocks. Mimochodem, Btrfs nedávno zpřístupnilo možnost režimu DUP pro data, tj. pokud máte Btrfs na jediném disku, můžete nejen pro metadata, ale i pro data nařídit ukládání dvou kopií. Pokud se tedy na disku objeví vadný sektor, tak s trochou štěstí přečtete dobrá data z jiného místa disku, i když nemáte přímo RAID.)

Na druhou stranu musíte v ZFS pečlivě zvažovat, jestli do poolu další zařízení přidáte, protože pokud to jednou uděláte, tak už je z poolu nedostanete a už napořád budete muset mít pool tvořený tolika zařízeními, i když byste třeba koupili několik málo disků, které by kapacitně převýšili daleko větší počet disků stávajících.

Výše uvedené chování ZFS by se asi dalo do jisté míry simulovat na Btrfs použitím např. Linux software RAID zařízení místo disků samotných, ale tím (v závislosti na konfiguraci) můžete přijít o schopnost Btrfs samoléčení filesystému – Btrfs nebude mít přehled o redundantních datech zajištěných níže ležící vrstvou (a nebude pro ně mít samostatně napočítané kontrolní součty), takže je nebude moci použít k automatické opravě zjištěných chyb. (Tohle je příklad toho, proč nechcete mít RAID/LVM/filesystém jako tři oddělené vrstvy, které o sobě nic neví...)

Další zvýšení bezpečnosti dat poskytuje ZFS Intent Log, který se dá využít k tomu, aby se minimalizovala pravděpodobnost ztráty dat mezi commity na disk (nyní se v ZFS v defaultním nastavení dělá tuším po pěti sekundách a uvažuje se o změně defaultu na 10 sekund) při výpadku napájení.

Flexibilita nastavení RAID konfigurace – vítězí Btrfs ¶

ZFS je sice možné nakonfigurovat pro větší odolnost proti výpadkům disků, na druhou stranu je jednou provedené rozhodnutí „napořád“. Pokud se rozhodnete, že VDEV bude RAIDZ2, už z něj jiný typ RAID konfigurace neuděláte (a ani ho z poolu neodstraníte :-/).

Btrfs je v tomto mnohem flexibilnější, mezi RAID konfiguracemi je možné za plného provozu úložiště volně přecházet. Máte nyní úložiště v RAID1 konfiguraci a dochází vám místo?

btrfs balance start -dconvert=raid5 -mconvert=raid5 /mnt/btrfs-pool/

Chvíli počkáte a máte více volného místa při zachování odolnosti proti výpadku jednoho disku, protože RAID5 to řeší paritou a nesežere vám celou polovinu kapacity jako RAID1. Potřebujete větší odolnost?

btrfs balance start -dconvert=raid6 -mconvert=raid6 /mnt/btrfs-pool/

Chvíli počkáte a máte RAID6 odolný proti výpadku dvou disků.

Rychlé kopírování/přesouvání dat přes CoW – vítězí Btrfs ¶

Pod Linuxem můžete copy-on-write vlastností Btrfs (CoW používá i ZFS) využít k rychlému kopírování a přesouvání dat na Btrfs filesystému:

cp --reflink=auto /cesta/ke/zdroji /cesta/k/cíli

Program cp se pak místo kopírování dat pokusí jen vyrobit kopii inode, ale samotná data odkáže na bloky původního souboru (neztrácí se tedy čas ani místo na disku jejich duplikací). Na rozdíl od hardlinku se ale původní a nový soubor opravdu chovají jako dva nezávislé soubory, protože při změně kteréhokoliv z nich nejsou data druhého souboru přepsána, ale změněné bloky zapsány na jiné místo na disku a odkázány, což je stejně způsob, jak by Btrfs při přepisu souboru postupoval tak jako tak, protože na copy-on-write je Btrfs založený.

Obdobný parametr --reflink má i program mv. Jen musíte mít dostatečně novou verzi coreutils.

Přehled o stavu úložiště a možnosti ladění jeho konfigurace – vítězí ZFS ¶

ZFS asi poskytuje jasnější a rychlejší přehled o tom, jaký je nyní stav úložiště a jaké akce je případně třeba provést. Včetně např. see sekce s odkazy do průběžně aktualizované knowledge base na webu.

# zpool status tank
  pool: tank
 state: ONLINE
status: One or more devices is currently being resilvered.  The pool will
        continue to function, possibly in a degraded state.
action: Wait for the resilver to complete.
 scrub: resilver in progress for 0h2m, 16.43% done, 0h13m to go
config:

        NAME          STATE       READ WRITE CKSUM
        tank          DEGRADED       0     0     0
          mirror-0    DEGRADED       0     0     0
            replacing DEGRADED       0     0     0
            sde       ONLINE         0     0     0
            sdf       ONLINE         0     0     0
          mirror-1    ONLINE         0     0     0
            sdg       ONLINE         0     0     0
            sdh       ONLINE         0     0     0
          mirror-2    ONLINE         0     0     0
            sdi       ONLINE         0     0     0
            sdj       ONLINE         0     0     0

U Btrfs spíše koukáte přes dmesg do ring bufferu jádra, což není zdaleka tak příjemné, přehledné a můžete případně něco minout.

Ladění různých vlastností a konfigurace úložiště jsou také o něco podrobnější u ZFS než už Btrfs.

# zpool get all tank
NAME  PROPERTY       VALUE       SOURCE
tank  size           208G        -
tank  capacity       15%         -
tank  altroot        -           default
tank  health         ONLINE      -
tank  guid           1695112377970346970  default
tank  version        28          default
tank  bootfs         -           default
tank  delegation     on          default
tank  autoreplace    off         default
tank  cachefile      -           default
tank  failmode       wait        default
tank  listsnapshots  off         default
tank  autoexpand     off         default
tank  dedupditto     0           default
tank  dedupratio     1.00x       -
tank  free           176G        -
tank  allocated      32.2G       -
tank  readonly       off         -
tank  ashift         0           default
tank  comment        -           default
tank  expandsize     0           -

Z read-only proměnných na datasetech můžete mimo jiné získat informace o obsazeném místě na datasetu, jeho potomcích, snapshotech apod. Získání přesných informací o obsazeném a volném místě na Btrfs je dlouhodobě problematické.

Nastavení proměnných na datasetech se kaskádově dědí. Pokud tedy nastavíte např. algoritmus komprese na kořenovém datasetu, vnořené datasety jej zdědí. Kompresní algoritmus však můžete pro každý dataset ručně změnit (přepsat zděděnou hodnotu) nastavením příslušné proměnné na konkrétním datasetu.

Btrfs vlastnosti implementuje také. Zatím jich je ale prakticky používáno jen několik málo, navíc spousta věcí se stejně dá nastavit jen globálně pro celý filesystém, nikoliv per subvolume. Obecný mechanismus tu však je, oproti ZFS navíc rozlišuje vlastnosti samostatně pro subvolume, filesystem, inode a zařízení.

Výkon – vítězí ?ZFS? ¶

Jak Btrfs, tak ZFS je projektované zejména na spolehlivé uložení velkého množství dat, výkon není priorita. A popravdě řečeno výkon Btrfs ani ZFS nebývá úplně oslňující. Nemám žádný vlastní benchmark ani jsem se nesnažil zjišťovat, jestli lepší výkon poskytuje Btrfs nebo ZFS.

U ZFS mne ale zaujal koncept Adjustable Replacement Cache (ARC), včetně možnosti přidání rychlých zařízení (dobrého rychlého SSD apod.) jako druhé úrovně ARC mimo RAM. Tohle myslím dává daleko lepší potenciál pro ladění výkonu, než co poskytuje Btrfs.

Pokud se používá ZFS Intent Log (což se dá použít pro další zvýšení bezpečnosti uložení dat), dá se výkon ladit také jeho umístěním na samostatné rychlé disky.

Práce se snapshoty a subvolumes – vítězí Btrfs ¶

Práce se snapshoty je pro mne asi druhé největší zklamání ze ZFS. Způsob fungování Btrfs mi přijde jednodušší a přitom minimálně stejně flexibilní.

V Btrfs vypadá snapshot úplně identicky jako subvolume (vlastně mi není úplně jasné, proč je to vůbec na uživatelskou úroveň vytaženo jako dva rozdílné pojmy; chápu, že implementačně tam asi rozdíly budou, ale uživateli by to myslím mohlo být jedno a je to dost možná dáno jen historickým vývojem obslužné utility btrfs). Po vytvoření read-only nebo read-write snapshotu ze subvolume je tento na původním subvolume nezávislý (minimálně tedy z uživatelského hlediska).

V ZFS toto ale neplatí. Pokud vytvoříte snapshot, nemůžete dataset smazat, dokud nesmažete všechny snapshoty. Navíc je snapshot tak nějak napůl skrytý. 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í. Nebo vlastně tak napůl: 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 (což mimochodem znamená smazat případné všechny mezilehlé snapshoty!).

Způsobu práce Btrfs se v ZFS více podobá použití operace klonování datasetu, což se dá udělat i z libovolného snapshotu, opět tam ale je závislost, takže není možné zdrojový snapshot smazat, než se smaže z něj vytvořený klon. Respektive se to asi dá obejít použitím operace promote.

Co naopak považuji za velké plus ZFS (a dost chybí v Btrfs) je rekurzivní režim tvorby/mazání snapshotů. Pokud potřebujete vytvořit snapshot datasetu, kde jsou níže ležící další datasety, tak to ZFS obslužná utilita zvládne sama jediným příkazem. Rychle jsem nenašel, jestli to funguje i pro klonování datasetů, doufal bych, že ano. Rekurzivní režim je totiž dostupný i pro ZFS send/receive (kde pro Btrfs send/receive opět chybí), takže u ZFS se na to asi obecně myslelo.

Integrované šifrování – vítězí ?ZFS? ¶

Zajímavou funkcí moderního filesystému může být integrované šifrování. U Btrfs je šifrování plánováno, ovšem zatím se na něm asi vůbec pracovat nezačalo a zbývají tak jiné nástroje, na které je člověk stejně odkázán u většiny linuxových filesystémů, protože integrovaná podpora šifrování u nich prakticky neexistuje.

ZFS je na tom lépe, tam je šifrování implementováno. Ovšem záleží na verzi. Vývoj ZFS se začíná štěpit a je třeba rozlišovat Oracle ZFS na Solarisu a open-source OpenZFS, které se typicky používá jinde. Šifrování je dostupné od ZFS pool revision 30 v Oracle implementaci. Pokud jsem ale správně vyrozuměl, tak OpenZFS se oddělilo zhruba na pool revision 28 (dále je to složitější, protože OpenZFS zavádí feature flags a pool revision vystřelil na 5000, aby nedocházelo ke konfliktům s původním číslováním, které Oracle dále používá) a podpora šifrování v něm není.

Osobně bych se divil, pokud by k přenosu této implementace do OpenZFS došlo (vzhledem k „povaze“ Oracle a faktu, že v ZFS má hromadu peněz a považuje jej za součást svého firemního business). Spíš bych očekával, že pokud se šifrování v OpenZFS objeví, tak to bude jiná implementace než ta od Oracle. Třeba se ale pletu a budu mile překvapen.

ZFS tedy v oblasti šifrování vítězí, pokud se bavíme o použití Oracle Solarisu, kdekoliv jinde je na tom prakticky stejně jako Btrfs – šifrování integrované není.

Defragmenatace – vítězí Btrfs ¶

Jak Btrfs, tak ZFS jsou copy-on-write filesystémy, takže fragmentace dat při jejich průběžné změně je problém. Jak Btrfs, tak ZFS se tomu snaží různými technikami bránit. U ZFS ale neexistuje příkaz pro defragmentaci (pokud vím, tak se jako workaround používá zkopírování dat), u Btrfs je k dispozici on-line defragmentace pomocí btrfs filesystem defragment. Dá se přitom pustit na vybraných souborech, nebo rekurzivně na celém vybraném podstromu filesystému.

Na Btrfs je navíc v případě potřeby možné aplikovat nodatacow mount volbu (platná pro celý filesystém), respektive nastavit rozšířený atribut C na vybraném souboru/adresáři (musí být nastaveno, dokud je ještě soubor/adresář prázdný): chattr +C /cesta/k/souboru To pak způsobí vypnutí copy-on-write pro daná data (což může znamenat velký výkonností přínos pro specifické typy zátěže, např. datové soubory databázových serverů, jde je mnoho náhodných zápisů do velkých souborů), ale na druhou stranu znamená i automatické vypnutí počítání checksumů na těchto datech, vypnutí komprese a zvýšení pravděpodobnosti nekonzistentních dat na disku při výpadku napájení apod., takže je potřeba velmi dobře zvážit, jestli nám to opravdu stojí za riziko.

Export blokových zařízení (ZFS Volumes) – vítězí ZFS ¶

Export blokových zařízená je velmi zajímavá vlastnost, kde ZFS vítězí jednoduše proto, že v Btrfs žádná obdoba této funkce neexistuje.

Přiznám se, že o ZFS Volumes jsem neměl tušení, než jsem na to teď narazil v tutoriálu Aarona Toponce. Přitom je to velice zajímavá funkce, která umožňuje v systému vytvořit plnohodnotné blokové zařízení v /dev, do něhož zapsaná data jsou uložena v ZFS filesystému.

Při vytváření ZVOL je třeba specifikovat jeho pevnou velikost, ale vytvoření je prakticky okamžité i pro velmi velké kapacity. Předpokládám, že ve skutečnosti není na filesystému žádné místo alokováno a udat velikost je nutné jen kvůli tomu, aby ZFS věděl, jakou velikost u vytvořeného blokového zařízení uživatelům hlásit.

# zfs create -V 1G tank/disk1
# ls -l /dev/zvol/tank/disk1
lrwxrwxrwx 1 root root 11 Dec 20 22:10 /dev/zvol/tank/disk1 -> ../../zd144
# ls -l /dev/tank/disk1
lrwxrwxrwx 1 root root 8 Dec 20 22:10 /dev/tank/disk1 -> ../zd144

Je to tedy obdoba vytvoření souboru ve filesystému, který pak navážete na nějaké /dev/loopx zařízení přes losetup.

ZFS volumes jsou tedy zajímavá možnost např. pro vytvoření úložiště pro virtuální stroje – místo ukládání dat do image souborů spravovaných hypervizorem může hypervizor použít ZVOL blokové zařízení, ZVOL můžete využít pro uložení swapu na ZFS apod. Přitom i pro ZFS volumes máte k dispozici kontrolu integrity, snapshotování, deduplikaci, kompresi, redundantní uložení a další vlastnosti, které ZFS na daném poolu poskytuje.

„Integrované“ sdílení přes NFS/Sambu/iSCSI – vítězí ?ZFS? ¶

V ZFS se dá mnoho věcí konfigurovat nastavením příslušných proměnných na poolu/datasetech. Mimo jiné se dá nastavením proměnné na datasetu zapnout jeho sdílení přes NFS/Sambu/iSCSI. Např. pro NFS to může vypadat takto:

# zfs set sharenfs="rw=@10.80.86.0/24" pool/srv
# zfs share pool/srv
# showmount -e hostname.example.com
Export list for hostname.example.com:
/srv 10.80.86.0/24

Do nadpisu jsem dal vítězství ZFS s otazníkem. Nejsem si totiž úplně jistý, jestli je tohle vlastnost, kterou u ZFS oceňuji, nebo je to prostě jen další položka na seznamu funkcí, které má, takže si za ni uděláme čárku.

Osobně bych sdílení dat přes NFS/Sambu/iSCSI nechal čistě na konfiguraci daných serverů. Ty totiž stejně musí běžet, přímo ZFS kód neobsahuje implementaci NFS/Samba/iSCSI serveru – proto ty uvozovky v nadpisu. Je to jen vytažení konfigurace sdílení z konfigurace serveru do nastavení vlastností filesystému. Nejsem si jistý, jestli je to nutné nebo dokonce vhodné ve filesystému mít.

Integrace s Linuxem – vítězí Btrfs ¶

Tady opět jasně vítězí Btrfs, protože ZFS je na Linuxu tak trochu vetřelec. Pokud vím, tak ZFS není dobře integrovatelný s linuxovým VFS (na druhou stranu by integrace s VFS mohla být lepší i u Btrfs, jak už dříve poznamenal Heron), správa paměti a cachování je v ZFS docela komplikovaná a dělaná „po vlastní ose“ (což ale nemusí být nutně špatně, je to optimalizace pro účel, kterému to slouží), POSIX ACL jsou ukládány jako rozšířené atributy, protože nejsou podporovány na ostatních platformách a nemohou tak přepsat nativní ZFS/NFSv4 ACL apod.

Z uživatelského hlediska asi překvapí, že se nic nepíše do /etc/fstab a nefunguje mount, protože i toto má ZFS řešeno jinak – přes zfs mount/unmount a zpool import/export. Přitom korektní export úložiště je podstatný i jen před tím, než budete disky přenášet do jiného serveru, jinak tam ZFS pool korektně nerozběháte. (A např. ZFSonLinux init skripty na Debianu prý při vypínání stroje dělají jen umount, nikoliv export!)

Obecně se mi zdá, že je u ZFS na discích je méně metadat, než by člověk čekal, protože v tutoriálu Aarona Toponce je na několika místech varování, ať se nepoužívají potenciálně se měnící odkazy na disky přes /dev/sdx, ale perzistentní /dev/disk/by-id/y, aby nedošlo k záměně zařízení ZFS. Pokud vím, tak u Btrfs je to jedno a jádro si disky najde a správně identifikuje přímo z metadat na blokových zařízeních.

Stabilita a prověření praxí a časem – vítězí ZFS ¶

Z vlastní zkušenosti vím, že u Btrfs se dá celkem snadno narazit na problém, který by v produkčním prostředí člověk řešit nechtěl. Faktem je, že stabilizace, ladění a vychytání software chce čas, takže mezi Btrfs, vyvíjeným od roku 2009 (od 2013 označený za stabilní), a ZFS, zdrojové kódy uvolněné 2005 (což tedy byla nějaká ne úplně raná verze), jistě rozdíl ve vyspělosti bude.

Na druhou stranu je otázka, jak moc se dá spoléhat na vyspělost ZFS na jiných platformách, než domovském Solarisu. Nemám přehled, jak velké procento kódu je sdíleno. A i tak je adaptace kódu z jednoho systému na jiný systém vždycky spojená se zavlečením chyb. ZFS začíná mít má mnoho verzí, a to i z hlediska formátu filesystému na disku.

To ale nic nemění na faktu, že ZFS je výrazně dospělejší a lépe ověřený (i produkčním provozem) než Btrfs.

Kompatibilita – vítězí ZFS ¶

Pod zprávičkou o začlenění ZFS balíčku do Debianu se objevila dobrá poznámka v diskusi, že ZFS tak vlastně začíná být pěkný jednotící filesystém z hlediska kompatibility napříč různými operačními systémy. Btrfs je sice licenčně čistý a dobře integrovaný s Linuxem, ovšem na jiných systémech budete mít s jeho zpřístupněním problém. (I když doufám, že by třeba nakonec něco mohlo být z projektu WinBtrfs.) V případě ZFS s filesystémem budete schopni pracovat na Linuxu, FreeBSD, MacOS X a dalších (modulo případná nekompatibilita verzí formátu ZFS).

Závěr ¶

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.

Vývoj, stabilizace a přijetí Btrfs jde ale pomaleji, než bych si přál. V současnosti, kdy se ZFS chystá do Ubuntu a Debianu, se začínám trošku bát, aby se ZFS nezačal na Linuxu používat tak masivně, že potřeba next-gen filesystému pod Linuxem jím bude více méně uspokojena a vývoj Btrfs úplně ustrne. Byla by to velká škoda – jak můžete vidět výše, Btrfs má co nabídnout a ZFS je přece jen na Linuxu tak trošku veřelec.

       

Anketa

Komentáře

[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.