Vlákno názorů k článku
Více detailů k projektu Red Hat Stratis, který má nahradit Btrfs a ZFS
od pepik - Super - pokud to dotáhnou k bootovaní a...
-
pepik (neregistrovaný)
Super - pokud to dotáhnou k bootovaní a zavedou něco jako beadm v Solarisu/FreeBSD, tak to bude dávat velký smysl.
Držím palce, určitě to ve Fedoře důkladně otestuju. Sunu/Oraclu trvalou hodně dlouho, než ZFS vyladili - v Solarisu 11.4 je to zase o hodně dál. Uvidíme, jak se bude dařit RedHatu 'feature parity' dohánět. Filesystémy stylu ZFS nejsou nic jednoduchýho.
-
Miroslave, v cem vidite prekazky v navrhu ZFS? Pokud se podivam na ZFS jako na enterprise FS, tak me tech veci moc nenapada, rad bych videl pohled nekoho jineho.
Např. ne ideální je deduplikace, její výkon a spotřeba paměti. Špatně se s tím pracuje, limituje a měří výkon. Když to srovnám s použitelností deduplikace nad NTFS, ZFS prohrává. Poměrně nevysvětlitelný je znatelný rozdíl ve výkonu práce při poolu type=filesystem vs type=volume, a to i po vypnutí checksumování.
Z funkčností chybí změna (povýšení) levelu redundance.
-
Kkt1 (neregistrovaný)
Povyseni levelu redundance je vec ktera me taky jiz zaskocila. Na druhou stranu to nepouzivam. Co se tyce deduplikace, netusim jak dobra je ntfs deduplikace, nebo jak funguje, ale zfs deduplikace dle mych zkusenosti je nenazrana a u vetsich poolu jsem se dostal nad 600GB RAM. Z pohledu performance ma zfs sve omezeni, naprosty souhlas. Dekuji za nazor.
-
Co se tyce deduplikace, netusim jak dobra je ntfs deduplikace, nebo jak funguje,
Deduplikace ve Windows serveru je prováděná offline, podle nastaveného plánu. Lze exkludovat určité typy souborů nebo adresáře. Lze nastavit, že deduplikace se provede (pokusí provést) až na souborech starších X dní. To všechno jsou velmi jednoduché a efektivní volby. Nastavíte si schedule deduplikace na čas, kdy Vám výkon nechybí a vyloučíte soubory, u kterých to nedává smysl. Často měněné soubory (mladší než X dní) nezatíží deduplikaci vůbec. Díky tomu se dá v produkci dosáhnout použitelnosti.
Proti tomu ZFS má deduplikaci buďto úplně vypnutou, nebo úplně zapnutou, a zásadně ji provádí v reálném čase. Proto je spotřeba paměti i úbytek výkonu enormní.
BTW spotřeba paměti a úbytek výkonu jsou u ZFS podle mě také nevysvětlitelné, bude to nějaká vlastnost by design - hlouběji jsem to nezkoumal, ale smysl to nedává.
-
Zalezi od dat, ale zfs deduplikace muze byt v nekterych pripadech uzitecna.
Jednoznačně ano, sám ji někde používám, ale tam, kde mi vůbec nejde o rychlost.
Např. offline deduplikace nebo i zpětná do-de-duplikace :)) by byla docela užitečná funkce. Přes den by byla vypnutá a v noci by se to spustilo - to mi třeba na ZFS chybí. Stejně jako možnost rekomprimovat data novým algoritmem. Když změníte algo komprese, týká se jen nových zápisů. Staré zůstanou nekomprimované, nebo komprimované po staru. -
JSe (neregistrovaný)
Např. ne ideální je deduplikace, její výkon a spotřeba paměti. Špatně se s tím pracuje, limituje a měří výkon.
Zkuste Solaris 11.4 -- deduplikace byla kompletně předělána. Mimo jiné je teď třeba možné nastavit limit velikosti deduplikačních metadat a/nebo pro ně vyhradit speciální vdev v poolu (třeba nějaké NVMe), aby k nim byl rychlý přístup i pokud se už nevejdou do paměti.Poměrně nevysvětlitelný je znatelný rozdíl ve výkonu práce při poolu type=filesystem vs type=volume
Tohle mě zajímá, máte číslo chyby? Minimálně vysvětlitelné by to mělo být snadno :-)Z funkčností chybí změna (povýšení) levelu redundance.
Opět zkuste Solaris 11.4, tam se to dá řešit odebráním vdevu (třeba mirroru) a vložením jiného (např. raidz). V minulosti se diskutovala i přímá transformace (např. z raidz1 na raidz3), nakonec to bylo ale zavrženo. Hlavní problém bylo, jak nějak srozumitelně reportovat množství obsazeného a volného místa na poolu během transformace parit.překonat překážky v návrhu ZFS
Nic z toho bych rozhodně nenazval překážkou v návrhu ZFS, jsou to prostě jen vlastnosti nebo nedostatky současné implementace -
Trident (neregistrovaný)
Nezapomeňte že zfs bylo primárně navrženo jako backend fs pro storage dodávané sun microsystems/oracle. Proto se třeba jinak chová setup na fs a na volume. Proto je rozdíl mezi deduplikaci na bázi fs a na bázi volumu. Offline dedup měl být také implementován ale nebyl to primární cil. Zbytek nemůžu komentovat(NDA).
-
Nezapomeňte že zfs bylo primárně navrženo jako backend fs pro storage dodávané sun microsystems/oracle. Proto se třeba jinak chová setup na fs a na volume.
Jéžiš, já ZFS vůbec nekritizuji a používám ho s oblibou. Jen jsme diskutovali o tom, že ne všechny jeho vlastnosti musí každý považovat za ideální - a proto je prostor pro vznik nových filesystémů (+volume managerů). ZFS jsem se dotknout nechtěl a nesahejte mi na něj :).
-
Trident (neregistrovaný)
O tom žádná. I takový FAT12 má stále své aplikace kde je nezastupitelny:) Mám také pro ZFS slabost:) Jen mne slo o to poukázat že navrh byl a počítal s různými metodami dedupu. Ale holt projekt není závislý jen na inzenyrech(skoro všichni odesli) ale hlavně na řízení a prioritách vývoje. ZFS je velmi složité a jakkekoliv zdokonalení komunitou je závislé jen na pár lidech.
Vzhledem k tomu ze vzpominam na práci v Sunu jako nejlepší profesní léta, tak připouštím že jsem podjaty, zaujatý, stranny a emocionálně ovlivneny:)
ČLÁNKY DO MAILU