Vlákno názorů k článku
OpenZFS umí paralelně synchronizovat více objektů, zvýšila se rychlost zápisu od Izak - Kde sakra chodite na ty blaboly, ze rozsirovani...

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.