Názory k článku ZFS nebo Btrfs: stabilita vs. podpora v distribucích

Ake vozitko preferujete? Nakladiak, osobak, traktor, autobus alebo dragster?

Treba sa spytat, na aky ucel:
Na /boot mi staci ext2,
na /tmp mam tmpfs,
na male subory na desktope s malou RAM pouzivam reiserfs,
na Linuxovych serveroch panovi Reiserovi a ani btrfs/ZFS az tak neverim a pouzivam ext4 nad LVM,
ako staru lasku zo Solarisu mam na datovej particii notebooku s viac RAM ZFS,
v Linux routeri JFFS2,
na velkom USB kluci NTFS,
na diskety a male USB kluce FAT,
na optickych mediach najviac UDF,
na viac pocitacov pre viac uzivatelov by som preferoval AFS

Tieto vybery su podla mojich preferencii na konkretne pouzitie. Co teda preferujem?

Jsi podle mě hračička, takže odpověď zní: všechno. :-)

Ne ma pravdu, i souborovy system je nastroj a je nutne si rict co od nej chci a jak ho budu pouzivat a pak pouzit ten spravny. Ano lze namitnout ze hrabema hrabik taky zatlucu ale kladivem to jde proste lip.

Krome velkych pametovych naroku jsem se nedocetl o zadnych negativech. Se ZFS jsem mel tu cest pracovat na Solarisu, ale Btrfs jsem zatim nezkousel. Jake mate kdo negativni zkusenosti?

S Btrfs som narazil ked dom chcel existujuci adresar presunut do subvolume, nedalo sa to inac nez prikazom mv ktory povazoval subvolume za iny suborovy system a teda zbytocne cital a zapisoval vsetky data nazad na disk.

ZFS som neskusal

Tohle bude opravene v novych coreutils (tam kde zije 'mv'), misto plne kopie se udela reflink, coz kopiruje jen metadata misto celych dat. Rucne se to da obejit jako 'cp --reflink=always from to' a potom 'rm -rf from'.

U ZFS koncept reflinku neni a mv mezi subvolumy musi delat plnou kopii vzdy.

V single threaded vykonu urcite ani ZFS ani BTRFS nejsou rychlejsi, nez EXT4 (ono jen malo co je, jestli vubec neco).
Kdyz se na ZFS povede hodne rozfragmentovat volne misto a to pak jeste zacne dochazet, umi se cely pool poradne zpomalit (nicmene na tom se pracuje, hlavne v Delphixu).
ZFS neumi jakoukoliv realokaci bloku, nejde odebrat device, odkomprimovat jednou ulozena data se zapnutou kompresi, atd. - on to jaksi navrh neumoznil snadno od zacatku a je to tak komplexni ukol, ze to mr. Ahrens slibuje uz od roku 2007 a porad nikde nic :)
Na dalsi nevyhody si ale neumim rozpomenout, kdyby mne neco napadlo, hodim to sem. Neni vsechno ruzove a vsechno ma svoje problemy/nevyhody, chce to je zminit, souhlasim.

Fragmentovane volne misto je problem pro vsechny filesystemy, obvykle se radi nechavat nejakych 10% mista nevyuzitych.

Bylo zmineno na prednasce, ze ZFS neumi shrink, coz souvi s tou absenci relokace. Zrejme se jedna o povestny "block pointer rewrite" :) (ne ze by btrfs nemelo svoje "are we there yet?" featury).

S LVM/mdadm jde udělat mdadm --grow, pvresize a vgresize

> Podobně bych postupoval, kdybych měl LVM, také bych si v mdadm složit z nových disků další pole a to bych strčil jako další PV do VG.

mdadm umí reshape. Můžeš tak třeba přidat další disk do RAID6, ale bohužel musí být stejně velký jako ty předchozí. Takže takové věci jako že „mám staré pole z 500GB disků a jak odcházejí, tak je postupně měním za 4TB“ s tím dělat nejdou.

Právě z toho důvodu jsem dával do raidu nikoli disky ale partišny. V tomto případě bych tedy měl starý raid na 500G partišnách a nový na 1.5G partišnách. Samozřejmě by to bylo zajímavé teprve od dvou nebo tří nových disků. (Do té doby ale mohou fungovat jako dočasné odložiště dat, která se smí podělat (logů, kopií záloh, ...)

Samozrejme ze jdou ;-))), az budou vsechny pryc, jde to zmenit, jeste lepsi je mit LVM2, dat tam cely novy RAID, pridat je do VG a pak stare pole odebrat, takz jmse migrovali za behu z FC pole na nove FC pole ;-)

Ano, ten sami problem, Oracle mi tuhle vytku smazal z diskuze, kdyz rikali, ze je to normalni, jak rekl ze ne neni.
Argumentoval jsem NetAppem a neprovokoval jsem tim, ze vim, ze ZFS je kompletne ukradeny netapp WAFL, jen jeste neni tak odladen ;-))

Takze umi to linux SW_RAID s LVM2, umi to BTRFS a umi to i enterprise reseni NetApp, je sice pravdou, ze vetsinou pridavam disky po 14 nebo 16, ale obcas se stane, se opravdu dochazi misto a zvetsim vsechny RAID grupy ze 14 na 16, nebo 18 disku ... na zalohy klidne i na 20.

Zadny raid nefunguje na manoha discich, to je znamy fakt, tech 20-24 uz je fakt limitni, idelani je neco mezi 14-16 disky mozna 18, nad kduz date do jednoho RAID 60 disku, tak bude pomali, proto i netapp i ZFS pouziva raid_grupy a spojuje do aggregatu/zpoolu

Takze netapp ma disky, z tedh dela raid grupy (raid DP, neco jak R6) a z tech teprve sklada aggregaty, na kterych delate volumy, kde pak davate data, nebo LUNy ... logicky podobne SW_RAID + LVM2 v linuxu.

Takze kdyz ZFS rikaji, ze to nikdo nepotrebuje, ja rikam ze ano a ze vzivote nevideli enterprise prostredi a zrovna Oracle netapp doporucuje pro beh OracleBD pres NFS.

Pro me domaci uziti je teda ZFS k nicemu, nebot ja dokoupuji disky po jednom, BTRFS se u me choval divne, ted uz je to opraveno, pak jsem nasel i nedokumetovany parametr, ktery to vyresil, nakonec jsem zustal u SW_RAID + LVM2 + ext4.

Co se rychlosti tyce, je zajimavy tez XFS a jeho vlastnost mit pro ruzne casti jine struktury, ale to jsem nikdy nepouzil, stailo mi, ze me byl rychly, stabilni, umel velke disky a mel ACL ... dnes uz ale spise pouzivam ext4

Jasně. XFS je v poslední verzi opět o něco lepší, aniž by se nedal s výhodou dosud používat. ZFS ani Btrfs nemají na domácích strojích důvod běhat, ext4 je spolehlivě výkonově i spolehlivostí předčí, a to není zdaleka na konci vývoje.

> U BTRFS je to jinak. Tam prostě přidám (nebo odeberu) disk kdykoliv se mi zachce, nechám rebalancovat a je to.

To ale máš jenom mirror, ne? Na wiki btrfs čtu o RAID5/6 dost děsivé věci z hlediska podpory. https://btrfs.wiki.kernel.org/index.php/RAID56

Sem stejneho nazoru: delat jednu vec, a delat ji poradne. Temto multifunkcnim "molochum" jako ZFS (nebo systemd) nemuzu prijit na chut...

Myslim, ze by vam nemelo nic branit v tom, dat tomu zfs nebo btrfs blockdevice z LVM, a tyto jeho featury nepouzivat.

Jenze uz jen to, ze tam ty ficury jsou zcela automaticky generuje vyssi pravdepodobnost, ze se neco podela, i kdyz je nebudes pouzivat. Naopak, pokud pod to jeste vrazis LVM, tak ta pravdepodobnost, ze se neco podela jen naroste.

To byl před lety argument linuxové komunity proti zfs. A hle najednou ten třívrstvý "moloch" bastlí taky ala btrfs.

Ono totiž ta záruka konzistence a integrity vyžaduje ty vrstvy mít slité - mohu říct, že zfs používám už všude, kde mi záleží na datech, používat prehistorické fs, ketré prakticky umí jen trapný žurnál a které neuchrání proti bitrotu, to už je v 21. století na pováženou.

Tak hlavně při TB úložištích na technologiích o vysoké hustotě zápisu dojde k samovolné degradaci dat téměř jistě. A většinou se to dostane i do záloh.

A to už je potom docela problém.

degradaci se mysli samovolne pretoceni bitu souboru, at uz pri cteni/zapisu na disku, kdy nahodou projde kontrolou Reed–Solomon, nebo kdyz je v RAM cache a pamet neni ECC, atd.

Proč by záruka konzistence a integrity to nutně vyžadovala mít slité? Jestli mám nespolehlivý HW, tak je jedno jestli mi selže přímo, nebo skrz LVM. Kontrolu integrity musím mít prostě v tom filesystému, tak aby přežil rozbití části toho blockdevice. Neříkám, že to půjde naimplementovat optimalizovaně, ale nevidím důvod, proč by to nemělo jít. (A pokud je potřeba znát topologii, tak Ext3 třeba obsahuje hint, jak velké jsou 'stripes' pod ním ležícího raidu. Pak záleží jen na nástrojích (mkfs a spol), aby takové hinty měly správnou hodnotu.)

To záleží, jestli pod zárukou konzistence máte na mysli detekci chyby nebo i její opravu. Pro to první úplně stačí LVM/mdadm, pro to druhé potřebuje souborový systém možnost načíst stejný blok z jiné kopie (či přes paritu), což s LVM/mdadm nejde.

To máte pravdu. Na druhou stranu přesně tohle je celkem snadno popsatelná funkce: chci jinou variantu bloku X. Pokud mám blokové zařízení, o kterém vím, že má kontrolu chyb, tak přeci mohu rozšířit rozhraní (ioctl?) o to, že mi takové zařízení bude schopno poskytnout (postupně) všechny varianty (až 16 v případě 4 paritních disků, dnes se ale pokud vím používají nejvýše 2 paritní disky), a může (a nemusí) je seřadit podle pravděpodobnosti správnosti.

Na vrstvovém modelu v zásadě nic špatného není. Bohužel ale některé funkce nenaimplementujete nebo je nenaimplementuje optimálně, respektive tak jak je to možné bez vrstev. Zkuste s LVM udělat pár set snapshotů na ne úplně malých datech. Změřte jak dlouho vám to trvalo a kolik místa to zabírá. A pak to zkuste s btrfs.

Nekonzistetni budes mit data, ne fs, v tom je problem. Protoze ty jeste musis nejak rict aplikaci, ze ma zapsat/pozastavit zapis/dokoncit transakce/...

Ale LVM nevie ci nad nim bezi FS ktory uz prirodzene robi ako svoju zakladnu funkcionalitu COW (btrfs) a preto to nevie robit tak optimalne ako to vie robit samotny btrfs.
To je samozrejme priklad, takych veci je viac, ked si viem riadit cely tok od disku az k sebe viem to urobit optimalnejsie ako ked sa to ma prevlakat cez N vrstiev, ktore nakoniec aj tak nerobia nic ine iba zabezpecuju aby sa dal zvacsit alebo zmensit FS (neberiem RAID level ten je obvykle HW)? ;-)

Další věc jsou synchronizace pole - když na pár minut vytáhnu disk z mirroru v LVM a pak ho vrátím, trvá někdy fakt dost dlouho, než je volume zase synchronizovaný. ZFS naproti tomu jen překopíruje data, ktera se během té doby změnila, což je pro velké disky pod zátěží dost zasadní úspora času.

Taky se se ZFS nestane, že se na disk s daty omylem nasynchronizuje nepořádek třeba ze spare disku, ZFS podle checksumů pozná, která data kam patří.

Proc bys mel kdy potrebu davat dohromady neco, co se proste ani nikdy nerozbije? Ve smyslu, ano, u toho slepence si muzes prepsat metadata, ale kdyz se podivas na layout ZFS na disku, no musel by ses docela snazit to odtamtud nahodou smaznout. A kdyz jo, tak slepenec by podobnou operaci neprezil taky tak.

Nejak nevidim duvod zustavat u slepence, jsou to proste jenom umely myslenkovy konstrukty v hlavach lidi, co se storage delaji - kdyz ty koncepty smaznem z hlav, v realnym svete to dopad bude mit jakej? Porad jsou tam ty samy disky, ty samy kabely, ty samy radice a ty samy desky s procesorama. K cemu umele vrstvit timhle zpusobem a zapouzdrovat funkcionalitu jednotlivejch vrstev, aby na sebe nevidely tak dobre?

Ono ZFS ten layered koncept trochu kopiruje, daly by se tam ty vrstvy taky najit, ale mnohem lip si navzajem rozumi.

Uz jenom napriklad RAID5 write hole je s RAID-Z na ZFS absolutni minulosti, nema k nemu jak dojit. Atd. atd. atd. Slepenec neni potreba a vyhodu ma IMHO jedinou, jako vsechny legacy technologie - uz s nim umis, protoze jsi se s nim proste musel naucit, protoze nic lepsiho nebylo.

No, lecktere veci by ale bylo hezke "backportovat" zpet do lvm a raid. At to mohou vyuzit i jini. Napriklad proti te write hole se da bojovat zpusobem, ze filesystem bude (zjednodusene receno) pracovat po celych stripech raidu, a proste nedovoli zapsat do zurnalu ze stripe je v poradku, dokud nevi jestli byl cely zapsan. Nastaveni velikosti stripu mela tusim uz ext2 (i kdyz jen kvuli vykonu).

Slepenec ma jeste druhou vyhodu. Praci odvedenou na raidu a na lvm muze vyuzit kterykoli dalsi filesystem, a nemusi si to implementovat sam. Spravce (jako nevyvojar) pak muze jednotlive casti vymenit a nechat ty okolo. Hlavni problem slepence je ten, ze pro nektere nove funkce by se muselo menit (rozsirovat) rozhrani/protokol kterym mezi sebou jednotlive vrstvy mluvi. A to je zdlouhavy proces, pri kterem je potreba promyslet i pozadavky, ktere by mohly vzniknout, aby se to nemuselo menit casto. Vnitrni protokoly v monolitu se mneni snadno.

S odstavcem 2 souhlasim. Pokud zije pohromade nekolik filesystemu, tak by obecne veci mely byt oddelene a k dispozici vsem. Vylepseni subsystemu pak muze pozitivne ovlivnit i ostatni, viz nedavna prace xfs vyvojaru na per-superblock shinkerech, ktere v dusledku zrychlily writeback u ostatnich filesystemu.

Ten zdlouhavy proces designovani API muze dost podstatne zbrzdit vyvoj, nevim jestli tohle nebyl jeden z duvodu proc to u btrfs proslo. Krome toho, interni raid management je jeho jedina layering violation. ZFS si tak trochu zije ve svem svete (vlastni pagecache, io scheduler, raid, block cache, block devicy) a nema pro nej smysl se ohlizet na nejake zobecnovani vlastnich subsystemu a davat je k dispozici ostatnim. Pro nej to znamena vice moznosti zmen bez nutnosti resit "vztahy se sousedy" a tunit veci ryze podle vlastnich potreb.

Ciste spekulativne, kdyby nahodou ZFS nekdo prelicencoval pro linux-compatible licenci, zacleneni do jadra by znamenalo peclive prekopat vsechny ty subsystemy, co si ZFS z historickych duvodu tahne s sebou a integrovat s temi linuxovymi. Je asi zrejme, ze by to provazelo mnoho diskusi s nejistym vysledkem, co se tyce zacleneni.

k resilveringu: stačilo by naučit linuxový md raid TRIM, ne aby ho forwardoval, ale aby ho interpretoval. To by bylo velmi užitečné nejen pro SSD raidy.

Tohle ale SW_RAID ma .... vi ktere bloky ma obsaseny a resynchronizuje jen je

"... Blízká budoucnost snad přinese online deduplikaci, zatím je k dispozici pouze offline varianta, kdy je třeba mít souborový systém odpojený. ..."

jak jako odpojeny? to tak neni, ne? jen se musi pustit bedup dedup rucne, nebo z cronu a k deduplikaci tedy nedochazi uz pri zapisu, jako u zfs (online deduplikace)

Neni to offline jako odmountovane, nekdo z publika to komentoval behem prednasky. Mysli se out-of-band deduplikace, tj. ze si uzivatel pusti deduplikaci na vybrane soubory. Lidove se sice rika off-line, ale jen to mate a novy termin se zatim neujal.

Ja si dokonce myslim, ze je to lepsi, ZFS mam deduplikaci k nicemu, nutnost mit hodne RAM a vse udrzovat tam + degradace vykonu pri onlinde deduplikaci je nejvesti foul jaky jsem kdy ve FS videl.

I takovy NetApp pousit proces sis (deduplikaci) schedulovane.

Na domacim serveru mam Solaris a ZFS, na notebooku Debian a ext4. Btrfs jsem zkousel zhruba pred dvema lety, kdyz jsem planoval domaci server, nakonec jsem zvolil ZFS.

> Btrfs není plánované pro tak velké nasazení jako ZFS, což je podle
> Halenky znát i podle maximálních velikostí podporovaných úložišť.

Limity velikosti jsou v radu exabajtu, VFS v linuxu ma navic jeste omezeni na 8 EiB velikost souboru, protoze se pouziva znamenkovy typ pro offset. Maximalni velikosti jsou sice nizsi nez u ZFS, ale z praktickeho pohledu to nehraje roli a v dohledne budoucnosti to stacit bude.

ZOL jsem zkoušel dvakrát. Naposledy asi před rokem. Vždy při odchodu jednoho disku šlo do háje celé pole (bylo vytvořené jako raidz2). Možná byla chyba někde mezi klávesnicí a židlí, ale nakonec jsem se zase vrátil k xfs na mdraidu.

"Zajímavá je také L2ARCcache, která umožňuje zapisovaná data uložit nejprve na rychlé úložiště (typicky SSD) a až později je zapsat na pole. Podobně existuje log pro synchronní zápisy, které je možné rychle odhazovat na zařízení s nízkou latencí."

Bud som to zle pochopil, alebo je to nespravne napisane. L2ARC je read cache, cize v principe uplne to iste ako cache v pamati, ale nad SSD. Samozrejme, ze tie data sa tam musia nejako zapisat, ale v zasade sa tie data dostanu na L2ARC pri citani.

Pre zapis sluzi ZIL, pri ktorom sa zapis ulozi v RAM a v ZIL (na SSD) a nasledne sa neskor (v pravidelnych intervaloch, tusim 5 sekund) "splachne" na disky (pouziju sa data z RAM, ZIL samotne je write-only a vyuzije sa iba v pripade necakaneho restartu)

Do L2ARC se dostanou data pri evictovani z mru_ghost_listu a z mfu_ghost_listu, da se tunit pres l2arc_*, viz zfs-module-parameters(5).

Kdyz uz jsme u toho upresnovani, ZIL je nazev mechanismu, ZFS Intent Log, ten muze byt v poolu, nebo na dedikovanem zarizeni/mirroru => dedicated SLOG (synchronous log) device.

Do SLOGu jdou jenom synchronni zapisy do urcite velikosti, vetsi se pisou primo do poolu; da se to nastavit spolu s tendenci uprednostnovat pool pred SLOGem per dataset - v pripade, ze ma pool vyssi propustnost nez SSD a delaji se na dany dataset vetsi synchronni zapisy je vyhodne logbias nastavit na throughput.

No kdyz je ZFS vykradeny NetApp wafl, tak ja rikam, ze to nebude fungovat ;-)))

NetApp ma taky flex pool s SSD cache a to prosim v raidu s vice tisku, tedy radove TB dat a chova se to tak, ze kdyz prekrocite kapacitu cache a zarovne delate velke I/O tak prenos bloku mezi SSD a klaickymi HDD ty HDD vytizi ak, ze je lepsi tam ty SSD nemit ... teoretikcy je to skvela vec, prakticky to moc nefunguje.

Zato Flash cache, coz je PCI-E karta plna DDR a je pouze pro cteni, ne pro zapis funguje skvele a drasticky zvysuje I/O pri cteni, pokud si ji date nekolik TB, tak dosahujete skvelych vykonu, zapisovat data rychle, neni problem, pisou se nove, ale dolovat z disku ano ....

Dalsi vec je defragenatce, clovek by neveril, jak zfragemntovany FS dava zabrat CPU, kdyz z nej pres NFS jede ~5.000 virtualek ;-)))

Vyzera, ze to co opisujes funguje na trosku inom principe. Pri ZFS sa v zasade neprenasaju data medzi SSD a HDD priamo.

L2ARC obsahuje data, ktore su casom vytlacene z RAM cache,

ZIL je zas v podstate write-only - data sa ulozia do RAM a ZIL zaroven, neskor sa zapisu z RAM na HDD. ZIL sa pouzije iba v pripade nahleho vypadku elektriny, ked si stratil data v RAM.

Rad sa necham opravit ak sa mylim.

Oracle tvrdi ze ZFS nepotrebuje fsck ... ja videl korupnuty a neprimountovaltelny ZFS, kde neslo o vadne RAM ani chybu FC raid pole, takze je to FS k nicemu, leda by si clovek zaridil replikaci jinam, backup je k nicemu, backup je pro nouzove situace, ne pro obnovu 80TB dat ... a ja sparvuji PB dat a udelat ze snapshotu flexclone je presne to, co potrebuji, kdyz mam obnovit ze zalozni lokality produkci ... a ne to tyden tahat zpet ;-)))

Pokud budu mit vadnou RAM, dojde k poskozeni jeste snaze ... a pak je mi ZFS k cemu, kdyz se pozkodi a nepujde ani precist a zkopiroat jinam ????

ZFS je tedy nepouzitelny pro enterprise nasazeni, proze takovych kecu, ze se neco nemuze poskodit uz jse slysel ... ale taky videl pozkozenych ... a prave i ZFS, ktere nejde uz nikdy opravit ...

kdyz tedy prestane byt ZFS netaverze pro testovani a pridaji opravu FS ???