Proč BTRFS a proč ne ZFS

Nedávno jsem tu psal o zkušenostech ze světa FreeBSD. Už v úvodu jsem se zmínil, že jsem před lety testoval ZFS a nakonec raději zvolil BTRFS. V tomto článku bych se pokusil vysvětlit proč. A rád bych hned na úvod napsal, že v žádném případě nepovažuji jeden FS za lepší a druhý za horší. Není to žádné něco versus něco jiného. Každý FS má jinou historii, jiné nasazení, jiné možnosti. Je proto velmi dobře, že máme na výběr mezi vícero technologiemi a můžeme si vybrat to, co nám pro dané nasazení vyhovuje.

Flexibilita

Ze světa blokových zařízení v linuxu jsem zvyklý na obrovskou svobodu v tom, co s blokovými zařízeními můžete dělat. Existuje spousta software, do kterého vstupují bloková zařízení a která bloková zařízení exportují.

Například můžete pomocí losetup exportovat soubor jako blokové zařízení, z tohoto zařízení udělat mdadm pole, nad to dát LVM a exportovat LV a to šifrovat pomocí dmcrypt a vytvořit na tom klidně fuse fs.

Tedy ne, že by tento setup dával nějaký smysl, v praxi spíše použijeme nástroje pro luks nad dmcrypt, ale možné to prostě je.

MultiDevice

Pokud ještě zůstaneme u flexibility, tak už i samotné md (ovládané nástrojem mdadm), umožňuje (nikoliv ovšem ve všech režimech) přidat disk do stávajícího pole (například rozšířit raid5 o další diskové zařízení), odebrat disk a v některých případech i změnit typ raidu (pokud je dostatek disků). Např raid1 na raid5, raid5 na raid6 apod.

LVM

U LVM jsme na tom ještě lépe. Vstupují do něj bloková zařízení (prakticky vždy buď md raid pole nebo rovnou disková zařízení) a exportuje bloková zařízení v podobě LV.

Disky (PV) můžeme kdykoliv přidat, kdykoliv je odpojit (pokud je ve skupině dostatek místa) – pomocí příkazu pvmove. To znamená, že do LVM můžeme kdykoliv přidat další disk a kdykoliv jakýkoliv disk odebrat. Vše za běhu. Stejně tak kdykoliv vytvořit nové LV (pokud je dostatek místa), a kdykoliv LV zrušit.

Na toto jsem v linuxu velmi zvyklý a přináší to možnost si storage kdykoliv přeuspořádat podle aktuální potřeby. Současně to klade mnohem menší požadavky na počáteční návrh storage. Na počátku klidně můžete začít s mirrorem v LVM, po čase se nároky na místo zvětší, přidáte do LVM další PV, dejme tomu raid5, původní mirror zrušíte a necháte zvětšit raid5 na plný počet disků, nebo jej cestou ještě zkonvertujete na raid6 – disků je více, je dobré se chránit před výpadkem dvou z nich.

BTRFS

No a potom přišlo BTRFS. Kdykoliv přidám další disk (a na rozdíl od md pole bez nutnosti zdlouhavého přepočítávání), kdykoliv další disk odeberu (tady už se data z tohoto disku musejí přesunout na ostatní, aby se zachoval zvolený typ redundance – používám raid1). Disků vůbec nemusí být sudý počet a dokonce vůbec nemusejí být stejně velké. BTRFS zkrátka zajistí jen to, že data jsou na dvou různých discích.

Potíž s návrhem storage na ZFS

Prakticky nic z výše uvedeného ZFS neumí. Pokud jednou do ZFS poolu přidáte další vdev, už je tam do konce života toho FS. Prostě vdev můžete jen přidávat, nikoliv odebírat.

Edit říjen 2018: Od FreeBSD 11.2 (léto 2018), lze vdevy i odstraňovat.

Vdev může být typu jeden disk, mirror, raidz (něco jako raid5), raidz2 (něco jako raid6), raidz3 (odolnost proti výpadku 3 zařízení). Nějaká flexibilita tady je, například ze single disk můžete udělat mirror a zpět. Toť vše. Raidz už nijak nezměníte.

Což klade obrovské nároky na počáteční návrh storage. vdevy lze jen přidávat, typ vdevu se změnit nedá. (Opomíjím single, protože bez redundance se dnes nic nenavrhuje.)

Ke cti ZFS dlužno podotknout, že dělá stripe (raid0) přes všechny vdevy v poolu, takže pokud máte pool z několika raidz vdevů, tak je to něco jako raid 50. (Stripe set nad raid5.) Takto přes všechny vdevy nezávisle na jejich typu. Takže přidáním dalšího vdev do poolu, se současně FS zrychlí. (Toto platí pouze pro nová data, ZFS zatím neumí přeuspořádat stará data – jak to umí třeba příkaz btrfs balance.)

Jak to dělám já

Nevím, jak se toto řeší jinde. Možná existují nějaká návrhová pravidla, která nevidím (a nevidím je proto, že jsem zvyklý pracovat na zcela jiné úrovni možností). Pro sebe jsem si zvolil cestu postupného přidávání vdev typu mirror. Celé ZFS se tak chová jako raid10 a s rostoucím počet vdev mirror získávám stále větší rychlost. Jenže už je nikdy z poolu neodstraním.

Klady ZFS

ZFS má vlastnosti, které BTRFS nemá. Už jsem zde uvedl stripe set přes všechna vdev, což velmi pomáhá k rychlosti storage. (Na druhou stranu se to může stát i pastí. Chová se to jako raid0, takže pokud neopatrný admin přidá do poolu single disk vdev a tento selže, tak je celý pool ztracen.)

Další skvělou vlastností je možnost exportovat blokové zařízení – ZVOL. Tohle je skvělé, pokud to chcete použít jako podkladové zařízení pro virtuální stroje. Na linuxu by se použilo LV, tady je možnost ZVOL. ZVOL lze vytvořit i jako thin provisioning. (Ano vím, že LVM taky, ale ten postup považuju za velmi špatný vtip.)

ZVOL používám právě v kombinaci s iSCSI. Na linuxu lze mít iscsi target i nad souborem (fileio), lze to provozovat i na BTRFS (včetně thin provisioningu), ale mít to nad blokovým zařízením je lepší.

Dalším plusem na straně ZFS je možnost použít externí cache. Typicky tedy na SSD nebo jiném rychlém zařízení. SLOG (zápisová cache) v našich testech udělala z 5400rpm disků „v podstatě“ 15k RPM SASy. Nechytejte mě úplně za slovo. Testoval jsem to pgbenchem, což je jistě velmi specifický typ testu, na druhou stranu dobře ukazuje, jak se na daném storage bude chovat databázová aplikace podobného typu. A tady SSD v roli SLOG zafungovalo velmi dobře.

Pro mě je lepší BTRFS

Nemusím příliš přemýšlet nad počátečním uspořádáním disků, prostě to kdykoliv změním časem.

Naproti tomu ZFS nabízí funkce, které BTRFS neumí. Například slog / cache. Odpovědí vývojářů BTRFS v tom, že si máte dát BTRFS přímo nad SSD je sice vtipná (asi), ale pro běžného smrtelníka poměrně těžko realizovatelná. (Představa, že bych měl doma 33TB SSD disků je sice krásná, ale jak tak koukám do prasátka, tak zatím i poměrně vzdálená.)

Jenže toto pro mě osobně nevyváží ty vlastnosti, které považuji za negativní. Tedy nemožnost změnit pool, změnit vdevy apod.

Takže, na Linuxu je pro mě BTRFS výchozím FS. Pro data, na která se nehodí, je tady XFS.

Na FreeBSD je jednoznačnou volbou ZFS. UFS je sice skvělý FS, je fascinující si přečíst jeho vylepšování (které šlo úplně jinou cestou, než linuxový extX), ale ufs je jen obyčejný fs starého střihu. Na druhou stranu si jej můžete vytvořit nad zfs zvol.

Příspěvek byl publikován v rubrice BTRFS, FreeBSD, Linux, ZFS. Můžete si uložit jeho odkaz mezi své oblíbené záložky.