Názory k článku
OpenZFS umí paralelně synchronizovat více objektů, zvýšila se rychlost zápisu

Další významná novinka ve vývoji ZFS je, že je přijatý dlouho vyvíjený patch na rozšiřování RAID-Z vdevů.

https://github.com/openzfs/zfs/pull/15022/commits/c3f8a291b12aae4b6864b0e48652d05130e96fcf

https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/1421193-openzfs-lands-exciting-raidz-expansion-feature

Velká spousta lidí, co provozuje nějaké menší, domácí, SOHO úložiště po tomhle hodně dlouho volala.

10. 11. 2023, 10:47 editováno autorem komentáře

díky přispění našich českých kolegů se tam zase dostala podpora overlayfs a linux containerů, https://github.com/openzfs/zfs/pull/12209, to už je součástí teď vydané 2.2.0 a to se chystám začít používat.

Správně jsi napsal, že to rozšiřování raidz je spíše pro SOHO, také to tak vidím.

V diskuzi pod mým článkem (shameless plug) jsem o tomto vývoji psal: https://www.root.cz/clanky/konverze-debianu-ze-souboroveho-systemu-ext4-na-moderni-zfs/
AFAIK to rozšíření funguje stejně jako řada jiných věcí jen pro nově zapsaná data. Pro využití celé kapacity/ správné rozdělení bude nutné data zkopírovat/ znovu zapsat.

Ano, to jsme jim rikal uz pred 10 lety - pry zadne enterprise reseni tohle nema - tak jsme dal jen odpoved "Treba NetApp ?" - a smazali me, nebot co na to chteji rict, nebot NetApp je jediny enterprise NAS a nic jineho v tehle tride neexistuje a ten RG=raid-grupu samozrejme rozsirovat umi a to za behu a pak prikazem umi vybalancovat data

Ja ale tuhle nepovedenou kopii NetApp WaflFS moc nemusim, nebot ZFS si umi hezky znicit data a pak to neumi opravit, to byl dalsi muj pozadavek, opravna utilita, pry neni potreba - kdyz jsme argumentoval ze nemaji pravdu, ze uz jsem zhrouceny ZFS videl - tak pry jsme mel smejd HW - rikam OK HPE prolaint s ECC, brocade SAn switch a IBM DS400 diskove pole - ano je to stredni trida, ale i tak ze pole byla na UPS, diskove pole OK, ram nic znicit nemohla - el. vypadek serveru a ZFS uz nesel opravit - obonovovalo se to z pasek - a pak jsme jeste videl vice zhrouceny ZFS co nesly nicim opravit

Dekuji to mi staci ;-)) zlaty BTRFS - pokud nepouzivate RAID - btw. BTRFS pry uz umi stabilen RAID5/6 - teda muze bezne spadnout a vyzaduje opravu, ale pry kdyz nedam metadata do RAID, ale necham je kopirovat na kazdy HDD - tak nemudu mit problem - no ja mam na domacim NAS SW-RAID a nad nim BTRFS - kvuli dedupliaci, kompresi, reflinkum - mozna casem i sub volumy a snapshoty - a umi blokove replikovat data ale NetApp - snpavault/snap­mirror - vlastne BTRFS pridava kupu funcki z NetAppu - co se divit, ZFS i BTRFS jsou kopii NetApp Wafl_FS

Jenom se zeptám, to IBM DS400 je SAN a ne DAS, že? Neumí ZFS sdělit např. hodnoty SMART jednotlivých disků a celése to exportuje jako nějaký LUN?
Já jen, že ZFS je dost explicitní v tom, že chce vidět přímo na disky, přesně protože různé řadiče RAID atd. mají tendenci lhát.

Samozřejmě i ZFS má chyby a třeba to i způsobilo ztrátu dat, ale tím, že řeknu jen velmi obecně, jak vypadal setup, ale nenapíšu, jaké byly verze čeho, nedám žádné logy/ výstupy ze zdb apod. se ty chyby najít nepodaří.

Jinak zrovna reflinky teď podporuje i ZFS (https://github.com/openzfs/zfs/releases/tag/zfs-2.2.0 viz "Block cloning"). Jinak některé problémy by mohl opravit tzv. 'Corrective "zfs receive"', který taky nově přibyl.

Kazdy ma asi jine zkusenosti... Videl jsem uz hodne dlouhodobe nasazenych velkych (desitky disku) ZFS poli vcetne ruznych kombinaci mene pouzivanych ficur jako Z3, dedup, metadata vdev,... a zatim, zaklepat, zadne rozpadle. Oproti tomu velkych BTRFS jsem videl podstatne mene ale nejake rozpadle jsem uz zazil. Nastesti to nebyl muj problem a sledoval jsem zoufale adminy rozhodujici se na zaklade zahadneho chovani a/nebo neurcite chybove hlasky mezi tim, zda se to pokouset opravit nebo obnovit zalohu pojidaje popcorn ;-)

11. 11. 2023, 16:39 editováno autorem komentáře

Ja som na svojich FreeBSD servroch este opatrny s OpenZFS i ked nemam uz moc moznosti - v decembri skonci support pre 12.4. Vyssie verzie uz maju OpenZFS.

Nie som FS developer, moj nazor, alebo skor pocit, je teda skutocne subjektivny.

Mne pride ten patch ako riadna prasacina. Uz teraz sa daju zvacsit raidz device tak, ze sa postupne kazdy device v raidz vymeni za vacsi. Cena diskov pre SOHO riesenia skutocne nie prilis vysoka.
Pri vytvarani raidzN device sa kladol doraz na pocet device pre dany raidz kvoli optimalizacii. Ten mix pred a po extende mi pride ako problem, ktory este sposobi vela bolesti.
Mozno som asi viac konzervativny, preto mi ten pristup SUNu vyhovoval.

Tady jde o počet, ne velikost zařízení. Ale ano, máte pravdu, že případným rozšířením RAID-Z za běhu vznikne takový hybridní stav, kdy stará data jsou na menším počtu zařízení.

Jinak bych se asi kódu nebál. V posledních letech do OpenZFS buší např. i AWS s jejich variantou FSx (https://www.youtube.com/watch?v=6Jt9LQcobXM), což asi měřitelně pomáhá s testováním.

Jinak bych i doma zvážil, jestli náhodou není lepší použít mirror vdevy místo raid-z (https://jrs-s.net/2015/02/06/zfs-you-should-use-mirror-vdevs-not-raidz/).

Ano, tomu rozumiem, ze v tom patchi ide o pocet zariadeni. To je to, co sa mne osobne nepaci. Expand vdev-u pridanim vacsich diskov mi pride postacujuci.

Burlivy vyvoj ma svoje pozitiva. Ale pri FS som viac opatrny. Ano, opensolaris implementacii zacali chybat veci (napr. nativny crypto dataset). Len aby som nepreslo do druheho extremu - prilis vela veci za prilis malu dobu.

S hodou okolnosti ale dnes prave robim prve backupy na 13.2 a teda na openzfs implementacii.

Kde sakra chodite na ty blaboly, ze rozsirovani RAIDZ je pro SOHO ? - jako prijde vam nejvyssi rada NetApp treba v konfiguraci MetroCluster jako SOSHO ?

Dejme tomu ze mate stary scenar, koupite si 800 disku udelate aggregaty z nejakych RG - treba kazda 16 disku - protoze vam to tak pro dane disky vyslo a zbytek nechate spares - v Netappu je kazdy novy disk spare, nebo nezarazeny do poolu - no a pak chcte rozsirit, at uz ze stavajicih, nebo nakupem dalsich disku

No a treba vam nekde dochazi misto, bud muzete migrovat volumu na jiy aggeragat, nebo rozsirit, ale ac to netapp umi, nechcte tam dam RG treba o 10 discich - to je dost blbost - tak rozsirite stavajici RG kazdopu o 2 disky z 16 na 18.

Dnes kdyz mate SSD disky klidne i o kapacite 30-70 TB casto koupite nejakou kapacitu a az dochazi, prikoupite polici s disky, nebo dokoupite polici s disky - proc ? nebot cena disku neustale klesa - a pak zase dava smysl rozsirit stavajici RG a ne jen dalsi pridat - a ted zalezi, zda mate vice malych volum, nebo mate nejakou hodne velkou - je rozdil koupit dalsich X disku a 2-3 mit jako paritni, nebo rozsirit stavajici RG - zvlaste kdyz vam treba kacita vyjde do 24 disku v shelfu, pokud nebyl zcela plny.

takze jako profik ve storage oblasti, ktery spravoval opravdu drahe diskove pole a NASy pro kriticke zakazniky muzu rict, ze je to NUTNOST - krom netappu to umi kde co, treba 3par/primera a kupa dalsich.

Pri dobrem planovani a kdyz mate velky rozpocet se tomu popravde casto vyhnete, nebot vse spocitate tak jak potrebujete i s rezervou a fungujete - ale pak nastava ta situace, ze diskove pole/NAS je 6 let stary a migruje se na nove a migrace jsou snapshoty = je treba vice mista + uz vam tam nikdo nic nekoupi, sice je to pod supportem, nekdy pod rozsirenym v ramci dobrych vztahu gratis (firma koupila nove + ma dalsich 20 NetAppu - tak se nekupuje 1 rocni regulerni support - zvlaste pokud se cekalo na novy NetApp), nebot se vi, ze pole pujde za chvili na srotak - tak to se uplne bezne vyskrabou nouzove spare disky a casto je jedina rozumna moznost bez degradace vykonu prave rozsirit RG o dalsi 1-2 disky - vzdy zalezi, jasne ze to jde i bez toho, nejaka voluma se muze zmigrovat, nebo se neco zmigruje na jiny netapp.

Samozřejmě se to nevyvíjelo domácím uživatelům pro jejich modré oči, ale spíše pro větší nasazení, přesně jak píšete. Není vůbec nutné se rozčilovat.

jako SOHO uzivatel jsem rad za rozsiritelnost MD, LVM, EXT4 .. vyuzil jsem to nekolikrat.

Pokud ZFS by znamenalo mit stary pole + novy pole.. tak nasr*t. Nemam zajem.

Takze mozna tudy prameni cileni na SOHO.. kteri proste ocekavaji ze neco jako rozsirovani uloziste lze udelat online.

I ten nepovedenej BTRFS ma prece re-balance.

Ano, hodí se to v SOHO, ale obecně ZFS na SOHO historicky určitě necílí a to je prostě znát. Sun, ani Delphix, kde Matt Ahrens a jeho kolegové Don Brady či Mark Maybee pracují, ani iXSystems, ani FreeBSD Foundation nemají SOHO jako fokus. Dokonce TrueNAS, který je vyvíjen iXSystems má nejlevnější stroj bez disků za USD 1048. Jestli to je SOHO, tak rozhodně spíše vyšší příčky nabídky.

Toz u QNAP nebo Synology taky neni problem najit modely od 25k - pokud trvate na 10Gb/s, ECC pametech a alespon aktualnim procesoru.

"Kde sakra chodite na ty blaboly, ze rozsirovani RAIDZ je pro SOHO ? - jako prijde vam nejvyssi rada NetApp treba v konfiguraci MetroCluster jako SOSHO ?"

Netuším, jak jste došel k té konstrukci s NetAppem pro SOHO? Už v minulé diskuzi k článku o ZFS Vám víc lidí napsalo, že je to dost nesmyslné srovnávání.
Co si pamatuji, tak poslední, kdo tohle řešil, byl před 15 lety NetApp, když se neúspěšně soudil se Sunem.
Asi nikdo soudný v těchhle diskusích nebude tvrdit, že obecná dostupnost ZFS v Linuxu, FreeBSD znamená, že tu už není prostor pro integrovaná řešení a velké podnikové systémy třeba od NetAppu, ale i Isillonu, Hitachi, HP, IBM atp. A upřímně bylo by smutné, pokud by pak za ty peníze nedokázaly nabídnout nic navíc proti tomu, když si to poskládáte sám z OSS produktů a komoditního HW, což pro spousty užití samozřejmě neplatí.
Na stranu druhou tu máte segmenty trhu, kde už máte trochu jiné požadavky a spousty té funkcionality (clusterování, obecný reed-solomon nad něajkými chunky) řešíte v dalších vrstvách nad běžnými filesystémy a v rámci daného projektu může být třeba nějaý Ceph, GlusterFS nebo MinIO na S3 výrazně výhodnější a flexibilnější řešení ve větších nasazeních. Ale to už odbočuju.

...

...
ohledně toho rozšiřování vdevů, nebo RAID group, či jak tomu budeme říkat, u nějakých větších polí a podnikového nasazení. Já mám trochu jinou zkušenost, a přestože jsem pracoval se systémy, co tohle umožňovaly, tak jsem to použil velice zřídka a spíš v rámci testů. Rozhodně to v tomhle užití pro mě není fíčura, u které bych si řekl - to je naprostá nutnost.
Důvodem je to, že ve většině situací je ta granularita rozšiřování spíš po enclosurech než po jednotlivých discích. Pokud jde o nejčastější kapacitní rozšiřování, přidávaly se pak celé RG do nějakých svazků. Pár další disků do RG toho většinou kapacitně moc neřeší a pokud jsou RG velké, pak se to na většině systémů (pokud tam není nějaký dist. spare) projeví delší dobou potencionálních rebuildů. Navíc, a tam samozřejmě záleží na konkrétním systému, přidání nové RG je víceméně okamžitá operace v porovnání s rozšiřováním stávající RG s kompletním přečtením všech dat a zapsáním nové parity.
Samozřejmě jsou i výhody toho rozšíření RG, po dokončení takového rozšíření (třeba z 4+2 na 8+2) se zvýší výkon i pro data, co byla předtím zapsána v RG bez nutnosti nějakého dodatečného balancingu.
Takže to je důvod, proč si myslím, že tahle nová funkcionalita najde uplatnění primárně v menších (SOHO) uložištích, kde máte typicky relativně málo slotů pro disky a výkon není až zas tak podstatný jako kapacita (poměr paritních/datových disků).

Jinak já osobně nejsem nekritický propagátor ZFS, mám z něj radost (nemá v OSS víceméně ekvivalent), ale beru to realisticky. A je tam určitě spousta věcí k vylepšení, které bych ocenil. Např. bych z hlediska větších úložišť viděl raději než rozšiřování RAID-Z vdevů možnost jejich odebírání včetně přesunu obsazených dat do jiných vdevů (v tuhle chvíli sice odebírat jde ale jen jednoduché vdevy, nebo mirrory a navíc tam je už navždy vnitřní přesměrování). Tohle jsem v praxi zažil častěji, třeba při náhradě celého enclosure, resp. disků v něm.
Podobně třeba integrované in place re-balancování (místo send-receive, které sežere 2x tolik místa, nebo hacků s externími skripty) by bylo fajn.

Vážně to někdo používá v seriózním podnikovém prostředí s ostrými daty? Když mám stovky disků a vysoké nároky, pak přece nepoužiju neco bez podpory někoho seriózního, ale použiju opravdové podnikové řešení. Ano, i za cenu kompromisů.

12. 11. 2023, 15:26 editováno autorem komentáře

Jo, AWS FSx má variantu, která běží s OpenZFS. Nebo rsync.net využívá OpenZFS na prakticky vše. No a potom jsou tu různé výzkumné laboratoře, které mají celé řady racků, kde běží OpenZFS. Např. Modirum používá OpenZFS/ FreeBSD a na jejich strojích se realizuje část workflow kolem platebních karet. To mi přijde jako docela kritické.

A nakonec třeba OrgPad provozujeme taky kompletně nad OpenZFS. Co do počtu a intenzity přístupů se rozhodně můžeme s některými systémy ve velkém korporátu měřit.

Díky za reakci.

O AWS FSx for OpenZFS jsem nevěděl. Asi proto, že jsem spíš hledal support pro řešení o kterých se píše tady v diskuzi (desítky disků) potažmo o řešení on-premises. Podobné je to s ostatními:

rsync.net je cloudová služba a velice malá firma.

Modirum nikde nepublikuje co na zfs dělá a zrovna to by mě zajímalo.

OrgPad v pohodě, spadá do kategorie o které jsem psal - malá firma pro pár TB.

0xide, to je USA crowdfundovaný startup, to na produkční data banky nebude stačit ještě plno let.

Zajímavé je tedy jen to AWS, kde to vypadá, že tomu někdo věří. Sice jsem se dočetl o technických a supportních limitech, ale i přesto je to dobrá reference, nicméně pro mojí hypotetickou banku to není, ta si "instaluje zfs na svůj hv inhouse a chce support". Btw. AWS nabízí SLA 99.5 %.

Zcela jasně píšu, že Oxide Computer věří i finanční instituce. Oxide opravdu není crowdfundovaný, nevím, kde jste na to přišel. Je to velmi slušně zafinancovaný startup pro který pracují matadoři v odvětví. Celý jejich produkt je od začátku hodně zafokusovaný na bezpečnost od hardwaru až po virtuálky. Však si můžete poslechnout jejich podcast, kde spoustu věcí vysvětlují do poměrně velké hloubky, nebo projít jejich dokumentaci.

Modirum provozuje desítky TB MySQL nad FreeBSD/ OpenZFS pokud vím. Hodně je zajímaly kompresní poměry atd. S Eirikem Øverbym jsem se bavil na vícero EuroBSDConech, existují záznamy z jeho přednášek, tak se můžete podívat, jaké výzvy řeší.

rsync.net je možná malá firma, ale z hlediska úložné kapacity předpokládám, že budou mít možná desítky PB dat zákazníků. Na trhu jsou skoro 20 let. Nepodařilo se mi dohledat nějaké konkrétní číslo, ale myslím si, že když kupují JBODy po 45/60 discích, že ty PB poskládají poměrně rychle.

Mimochodem, jestli znáte Nexentu nebo Delphix, tak ti poskytují kritický storage pro spíše větší a největší zákazníky. Polská firma FUDO Security třeba aspoň historicky dělala jump hosty se zaznamenáváním trafficu. Celé to bylo kryptograficky atestované a data se ukládala pomocí ZFS. Setup podle mě bude dost podobný jako u Modirum, protože FUDO PAM běželo také nad FreeBSD. https://download.fudosecurity.com/documentation/fudo/5_0/online_help/en/main/en/hardware.html
Zrovna FUDO u minulého zaměstnavatele pěkně sloužilo, byl jsem s tím dost spokojený.

Máte pravdu, 0xide není crowd-fundovaný, je to start-up. 0xide dodává appliance, což je fajn, ale není to podpora jako taková. Na ty finanční instituce bych se chtěl podívat - nenašel jsem žádnou referenci a jsem přesvědčen o tom, že ta reference nebude znít nějak jako: "využíváme 0xide pro kritická data", ale třeba se pletu.

Delphix jako největší přispěvovatel a tahoun vývoje zfs věřit musí. Přesto nenabízí support jako takový. Od Delphixu bych totiž té podpoře byl ochotný věřit (ne zcela, ale dost).

Celkově jsem mile překvapen, kolik firem nabízí nějaká řešení nad zfs, to jsem nečekal. Těším se (marně z mnoha důvodů) až bude zfs podporované stejně jako třeba ext, xfs nebo jako kdejaká databáze nebo aplikáč.

Btw. sám na zfs provozuju několik storage s kapacitou třeba 24TB a 16. disky. Stojí mi na tom byznys a živím se tím. Nicméně až budu dělat další rozšíření, bude to něco tradičnějšího, zfs prostě nevyužiju a přináší mi jen problémy.

Nemyslím to jako flame, opravdu mě to zajímá. Chápu skvělé vlastnosti toho systému a chápu, že si to klidně někdo dá na desktop, domácí archiv kdečeho, nějaká smb firma na produkční data pro pár TB, možná nějaká hostingovka, tu a tam pár systémů pro nekritická data v korporacích někde bokem pro dev-test asi taky běží, ale ptám se na nasazení, při kterém na tom systému stojí kritická data. To fakt někde v bance běží OpenZFS na *bsd* a chodí kolem toho spokojeně enterprise architekt a CTO vrtí palcema jak ušetřil?

Jestli to ale nebude take trosku tim, ze spousta tech tzv. architektu jsou ve skutecnosti hlavne alibisti, co potrebuji mit jakekoliv pripadne problemy na koho hodit :-) Samotna samolepka "enterprise" (aka podnikove reseni) vam zrovnatak negarantuje bezchybnost dodaneho software zrovnatak.

To je možná pravda, ale stejně by mě zajímalo, jestli to někdo používá.

offtopic: Na tzv. alibismu je mnoho velkých společností postavených. V určitou chvíli přeroste společnost hranici, kdy všichni zaměstnanci vnímají shodně společný cíl, a místo rizika volí bezpečnost. Vznikají normy, předpisy, procesy a na nich postavený alibismus. Není sice tak výkonný jako jinými motivacemi hnané společnosti, ale ukazuje se, že dokáže udržet v chodu a v růstu obrovské molochy, které se už "společným vědomím cíle" nedají vést.

Samozřejmě OpenZFS nemusí běžet vůbec na BSD (nejspíše FreeBSD), ale třeba Debianu nebo Ubuntu, které na to snad i poskytuje jakousi podporu.
Nově je třeba možné objednat si celý rack od Oxide Computer, které Vám dodá až 32 "sledů" vždy s až 64 jádrovými procesory, 1 TiB RAM, 2x 100 Gbps NIC a ~32 TB SSD. (10 ks á ~3,2 TB, ale možná osazují větší SSD a tohle je už skutečně užitná kapacita) https://oxide.computer/product/specifications
To celé běží s OpenZFS pod odnoží Illumosu pod názvem Helios. Data se rozkládají mezi jednotlivé sledy a jejich instance OpenZFS pomocí Crucible, což si můžete rozjet i doma s trochou práce: https://artemis.sh/2022/06/14/oxide-crucible.html

Jelikož zákazníci asi budou mít slušný překryv s bývalými zákazníku Sunu, tak si myslím, že o "mission critical" nouze nebude. Department of Energy, nějaká známá instituce ve finančnictví a další F1000 firmy, to je asi celkem slušná řada solventních zákazníků.