Názory k článku
Súborový systém ZFS - konzistentnosť dát

1) Volume manager + snapshoty - proč v rámci FS:

Protože při integraci těchto vrstev má volume manager informaci na úrovni souborů, a snapshoty (zejména ty zapisovatelné) mohou být nesrovnatelně výkonnější a flexibilnější. LVM2 snapshoty na linuxu jsou oproti ZFS totální tragédie. Další věc je globální sdílení volného prostoru, kdy klasický LVM prostě neví, kolik je na FS volného místa, a toto volné místo nelze sdílet mezi LV.

2) FS nezajistí úplnou konzistenci dat uvnitř souboru, ale zajistí, že se při hard-resetu samovolně nerozpadne, a nebude třeba dlouho trvající FSCK. Resp. nebude třeba žádný FSCK, protože v libovolném okamžiku i během zápisu je na disku konzistentní struktura FS; na konci se jednou atomickou(!) operací změní odkaz daného bloku na nová data. Kontrolní součty všeho a zároveň on-line kontrola na bázi RAID-Z je v době nezanedbatelné chybovost 1 TB+ disků také velmi rozumná vlastnost.

3) RAID a FS - RAID algoritmus může opět optimalizovat svou činnost s ohledem na výkon na základě znalosti o jednotilivých souborech. Lze dělat takové věci, že pro každý adresář máte jinou úroveň RAIDu (vyšší redundance / výkon), ale volný prostor je globálně sdílen. Rebuild RAIDu nebo přidání nového disku je také efektivnější, protože se počítá s nevyužitým místem na FS.

Bolo a je to mozne pre RAIDZ odjakziva a 'za jazdy'... man zpool. Samozrejme pod minimalny pocet sa neda ist...

Ma to i dalsi limity ... napr. raidz(raid5)3 disky, pridat jen 4ty fakt jen tak jednoduse nejde...

1) - snapshoty na úrovni FS přece můžu udělat i bez integrace s volume managerem. To že LVM neví kolik má FS volného místa je pravda, ale to by šlo vyřešit funkcí která to zjistí, ne tím, že VM zduplikuji do FS.
2) - konzistenci metadat řeší každý FS se žurnálem. Tohle má navíc kontrolní součty, které mohou pomoct (i když mě zrovna nenapadá žádný případ, kdy by žurnál selhal a kontrolní součty ne), ale v článku se píše o zaručené konzistenci _dat_, což prostě není pravda. Navíc je pochybné i to tvrzení o nepotřebnosti fsck - vývojáři některých jiných žurnálových FS si to mysleli také, než zjistili, že ho potřebují.
3) ano, rozdílné úrovně RAIDu pro různé části filesystému jsou asi tak jediné rozumné využití VM ve FS. Ale i to zvládne linuxový block device mapper, stačí ho použít.

1) Nejde o duplikování VM, ZFS nahrazuje tradiční VM. Na blokových zařízeních, která ZFS poskytuje si můžete vytvořit jakýkoli souborový systém chcete (klidně i další ZFS). Integrace fs a VM je nejsnažší způsob jak zajistit například to, že při synchronizaci mirroru nebudeme úplně zbytečně synchronizovat nepoužité bloky.

2) Jak vám žurnálování pomůže třeba proti silent data corruption? ZFS to zvládá docela dobře, viz třeba tenhle článek: http://www.cs.wisc.edu/wind/Publications/zfs-corruption-fast10.pdf
Čím byste zpochybnil tvrzení o nepotřebnosti fsck? Proč, když prostě není pravda tvrzení o zaručné konzistenci dat?

Jasně. Jenže v produkční kvalitě momentálně na Linuxu nic lepšího než ty LVM2 snapshoty není. Probíhající vývoj je jistě k užitku, ale jde o to, kdy se to dostane do stavu pro produkční nasazení.

Slibný je BTRFS, ale jak i píšete, je dobré mít možnost snapshotů i na blokovém zařízení (když ho třeba exportuju přes iSCSI). ZFS to řeší taky.

Snapshoty ve stylu ZFS jsou krom jiného fakt dobré pro zálohování. Používám snapshot-like zálohy pomocí rsyncu. Jenže jen smazání pár stovek tisíc souborů, což je jeden "snapshot", trvá na et3/etx4/xfs nechutně dlouho.

Tak implementace RAIDu uvnitř FS má své výhody - ostatně BTRFS se snaží dělat to samé. Navíc ve skutečnosti to není "unvnitř FS", spíš je to "nový RAID/LVM, který umí FS rozumněji používat" a funkcionalita RAID/LVM je dostupná přes zpool samostatně i bez ZFS.

Jinak ale článek je dost nahouby. Například výčet "hlavní výhody ZFS" obsahuje nic neříkající buzzwords (první dvě položky - reálně nikdo neviděl v jednom stroji FS větší než 2^48 bloků a asi ani v dohledné době neuvidí; cokoli nad 2^64 je jen zbytečný marketspeak), duplikovanou informaci zbytečně rozkecanou (poslední dvě položky), čísla vycucaná z prstu (chybovost dat) i obyčejné lži (snadnost ovládání: ZFS _není_ snadněji ovladatelný než jiné FS, protože minimálně musíte navíc vytvářet ten pool). A naopak tam není to co považuji za nejvíc "cool feature" posledních let - deduplikace bloků se stejným obsahem.

Patentovaná funkce Oraclu "copy-on-write"? Vždyť C-O-W využívá skoro každý operační systém uvnitř virtuální paměti, a úplně každý volume manager pro snapshoty.

ARC: Solarisu se konečně podařilo využívat dostupnou paměť jako cache? To je jen asi 12 let pozadu za Linuxem :-) Teda ne tak úplně, slyšel jsem že ZFS je stále ještě hodně náchylný na low-memory deadlock, přičemž "low memory" může znamenat "cokoli pod 2 GB".

Je pravda že opravdu technických informací o ZFS je pomálu, ale určitě stojí za přečtení článek http://lwn.net/Articles/342892/ (A Short History of BTRFS), který je sice primárně zaměřený na BTRFS, ale obsahuje sekci porovnávající architekturu ZFS a BTRFS. Takže je tam vidět které vlastnosti architektury jsou skutečně unikátní a které je možno dělat taky úplně jinak.

-Yenya, http://www.fi.muni.cz/~kas/blog/

Deduplikace je v ZFS k dispozici od verze 21. Co se týče snadnosti používání, je to asi hodně subjektivní otázka; mě osobně se ovládání ZFS zdá mnohem jednodušší a intuitivnější, než ovládání klasického LVM + FS, ale respektuji, že na to někdo může mít jiný názor.

Co se týče ARC a paměťové náročnosti ZFS, podle mých zkušeností není hlavní problém v ARC, ale ve vyrovnávacích pamětech pro zápis (které v případě potřeby nejdou tak snadno a rychle uvolnit). Při velkém objemu zapisovaných dat se skutečně obsazená paměť může vyšplhat až na stovky megabajtů. Osobně jsem se s tím setkal v podstatě jenom u mého domácího počítače, který slouží jako domácí fileserver a zároveň jeko desktopový počítač a vzhledem jeho stáří disponuje pouze omezenou pamětí (tuším že 1 GB). Ale dá se to řešit přenastavením některých parametrů ZFS nebo kernelu.

Největší problém ZFS ale spatřuji v tom, že Oracle uzavřel další vývoj Solarisu včetně ZFS a zdrojové kódy nejnovějších verzí už nejsou k dispozici pod žádnou svobodnou licencí. Takže nejnovější vlastnosti (např. šifrování, bezpečné mazání apod.) jsou k dispozici pouze pro uzavřené systémy společnosti Oracle (např. Solaris 11 Express) a jejich podporu v ostatních systémech (FreeBSD, OpenIndiana, apod.) lze očekávat pouze za cenu jejich reimplementace a pravděpodobné nekompatibility s originální implementací společnosti Oracle.

Takže ačkoliv považuji ZFS za technicky nejdokonalejší FS současnosti (můj osobní názor, please no flame) a mám s ním ty nejlepší zkušenosti, do budoucna u svých počítačů a serverů počítám s přechodem ze Solarisu zpět na Linux a ze ZFS na BTRFS.

Však já si nestěžuju že by ZFS neuměl deduplikaci, ale že deduplikace není zmíněna v tom seznamu stěžejních vlastností ZFS v článku.

Ad snadnost použití. Já jsem hlavně měl na mysli situaci, že běžný FS je možno použít bez volume manageru jako takového.

Ad paměťová náročnost: například posledních několik verzí OpenSolarisu mi vůbec nešlo nainstalovat uvnitř virtuální mašiny s 1 GB paměti, musel jsem explicitně zvyšovat na 1500 MB. A to ne že by to spadlo a řeklo nemám paměť. Právěže nastal ten low-memory deadlock - stroj nic nedělal (ani neswapoval) a nic dalšího se nedělo.

K osobnímu výběru FS:

Já jsem nakonec pro nové ftp.linux.cz zvolil XFS - pro ext4 stále ještě nejsou e2fsprogs s podporou FS nad 16 TB, a BTRFS jsem zatím neprohlásil za stabilní ani rychlý.

Na pracovní stanici na záložním disku mám BTRFS, na některých testovacích virtuálních mašinách taky. Jinak ext4.

-Yenya, http://www.fi.muni.cz/~kas/blog/

XFS - nepreju Vam vypadek proudu a nasledny i nekolikadeni beh xfs_repair

Posledně co jsem se díval tak xfs_repair běží zhruba stejně dlouho jako e2fsck. A rozhodně není pravda že xfs_repair (ani e2fsck) by bylo potřeba spouštět po každém výpadku proudu.

Já zase uživatelům ZFS nepřeju, aby kvůli chybě operačního systému nebo čehokoli jiného co samoopravné mechanismy ZFS neodstíní potřebovali fsck.zfs, který neexistuje.

Ostatně "konečně nepotřebujete fsck" bylo i jednou z marketingových frází SGI v době, kdy přišli s XFS (IRIX 5, pamatuje si někdo?). A velmi rychle a tiše pak ten fsck přidali.

-Yenya, http://www.fi.muni.cz/~kas/blog/

fsck.zfs totiz z principu nema nejmensi vyznam uz z principu jakym ZFS pracuje. Pokud nahodou dojde k poruseni momentalniho stavu neni nejmensi problem vratit se o par transaction group zpatky a mit stav filesystemu (opet konzistnentni pred nekolika sekundami. Mam overeno na vlastni kuzi pri obnove dat porusenych chybou SCSI radice a je to opravdu pomoc k nezaplaceni!

To by ten slavnej xfs_repair musel taky ten fs nekdy opravdu opravit, ne opravovat pokazde jine chyby pri dalsim spusteni nebo skoncit na segfault. Pouzivani xfs je pro me nouze, protoze v Linuxu neni zadny pouzitelny fs pro svazky s kapacitou radove desitky TB (netahejte me za slovo s ext4, to, ze se neco slibuje, neznamena, ze to funguje).

"obyčejné lži (snadnost ovládání: ZFS _není_ snadněji ovladatelný než jiné FS, protože minimálně musíte navíc vytvářet ten pool)."

Obycejne lzi? Pracoval jste nekdy se ZFS? Ano, muzete samostatne vytvorit zpool bez fs. Ale proc?

# zpool create <nazev> <disk>

se postara o vytvoreni zpoolu a filesystemu a jeste vam ho rovnou i pripoji. Pokud chcete mirror, misto <disk> date mirror <disk1> <disk2>.

V cem je to tvrzeni tedy lzive? Oproti vetsina mkfs.xxx mi to prijde snadnejsi uz ve fazi vytvareni.

Me se taky nelibi nesystemovost toho reseni, ale bohuzel je to zrejme jediny zpusob jak dosahnout lepsich vlastnosti.. zadny jiny FS neimplementuje kontrolni soucty, natoz aby to opravoval na pozadi.

Si vemte (sw) RAID6 v Linuxu - chyba jednoho disku jde detekovat, ale neexistuje reseni, ktere by to opravovalo (ani offline ani online).

a v tom linuxu by to neslo takto? echo "repair" >> /sys/block/md0/md/syn­c_action

Tam je problém, že u běžného RAIDu (dvojcestný RAID-1, RAID-10, RAID-5, ale ne RAID-6) když se zjistí nekonzitence, tak RAID neví která z kopií je ta správná. Lidi od ZFS tomu říkají "RAID write hole" a nastává vždycky, pokud nemáte RAID kontroler s cache která je zálohovaná baterkou.

-Yenya, http://www.fi.muni.cz/~kas/blog/

Kontrolni soucty obsahuje kazdy disk na urovni fyzicke vrstvy, a kdyz disk precte spatne kontrolni soucet tak vrat read error. Disky (za normalnich okolnosti) nikdy nelzou. Jen obcas reknou, ze nevi. Takze data ktera by mela spratny FS kontrolni soucet a spravny diskovy kontrolni soucet muzou vzniknout pouze nasledujicimi zpusoby:
1. Chybny procesor, pamet nebo fatalni chyba v operacnim systemu: takova chyba ale muze ovlivnit data jeste pred spocitanim kontrolniho souctu, takze branit se takovym chybam je zbytecne.
2. Chyba "po ceste" - chyba pri komunikaci procesoru a disku. Tady uz to TEORETICKY smysl ma, hlavne pokud by to pomohlo deserializovat nektere operace, aby radic raidu nebo disku mohl "svobodneji" volit ktera data zapise drive a ktera pozdeji. Prakticky si ale myslim, ze to vyhody neprinese.

Takze vyhody kontrolnich souctu ve filesystemu bych videl jen kdyz se to bude cpat na media, ktera kontrolni soucty nemaji (za poslednich deset let jsem zadna takova nevidel), nebo kdyz se tim vyvojari filesystemu snazi zachranit chyby napachane tim samym filesystemem.

Těch způsobů je víc. Třeba ghost writes, ať už chybou operačního systému nebo třeba tím, že ten disk najednou někdo strčí do jiného počítače a pak ho vrátí zpátky.

Každopádně si nemyslím, že tvrzení "podobná chyba může ovlivnit data i před spočítáním kontrolního součtu" je argument, proč ten kontrolní součet nedělat vůbec.

Já mám distribuované úložiště, kde do metadat souboru patří i jeho kontrolní součet. A za těch několik let co to úložiště běží jsem několikrát zjistil, že některá replika dat má chybný soubor. Obvykle to byla jednobitová chyba. A to jsou téměř všechny cesty kudy data chodí nějakým způsobem zabezpečené - ať už ECC v paměti, CRC na ethernetu, TCP checksum, kontrolní součet na fyzických discích, atd.

Bohužel propagátoři ZFS v tomto mají pravdu - "bit rot" opravdu reálně existuje a pokud se podaří jeho dopad zmenšit, i když ne odstranit, bude to jen dobře.

-Yenya, http://www.fi.muni.cz/~kas/blog/

Je to argument, proc se zamyslet nad "robustnejsim" resenim. Pokud jsou data opravdu cenna, pak je dulezite mit je zdupliknovana, nejlepe nekolikrat, a to vcetne cest od procesoru az k plotnam - v pripade databazi jsou idealni mirory/replikace na aplikacni urovni. Pokud nejsou dulezita (treba obrazky nebo videa uzivatelu), takze si muzeme dovolit vypadek v radu miliardtin (z ekonomickeho pohledu), tak nema smysl resit kontrolni soucty. Proste si myslim, ze by kontrolni soucty meli byt implementovany ve (volitelne) vrstve mezi "fs" a "blok device".

Problem uvedenych kontrol je, ze nejsou "krizove". Tedy ta kontrola zaruci, ze se nestane chyba pri praci v dane oblasti. Ale nezaruci, ze se nestane chyba pri prechodu mezi oblastmi, tedy ve sbernici nebo procesoru. V tom jsou kontrolni soucty ve FS dobre.

Mne desi "samoopravovani" chyb. Veci co se "opravuji samy" zatim v mych zkusenostech selhaly zpusobem, ktery vyvojar necekal a naslednou "samoopravou" se dodrbaly.

"Disky (za normalnich okolnosti) nikdy nelzou. Jen obcas reknou, ze nevi."

Tak to je docela zajímavý názor, může se zeptat jak jste na to přišel? Stručné vysvětlení proč se mýlíte je třeba v tomhle článku. Je v něm i pár odkazů na několik starších experimentů, které na to téma proběhly.

No, byl jsem idealista. Nicmene stejne si myslim, ze by se ty checksumy meli vyresit "samostatne". A nezeslozitovat jimi FS. Myslim, ze wrapper okolo block-device by byl idealni.

Autoři ZFS tohle taky uvažovali (četl jsem to před par lety myslím na blogu jednoho z nich, teď se mi to už nedaří nelézt). Došli ale k následujícímu: proč počítat a kontrolovat nějaké super-hyper-drsné, zaručeně nekolizní checksumy pro každý blog na disku, který se čirou náhodou bude číst nebo zapisovat (tedy i pro mazané bloky, prázdné před prvním použitím atd.) když to může dělat souborový systém, který ví, co který blok je. Navíc to umožňuje mít fakt hustou funkci pro data, na kterých nám hodně záleží (třeba metadata, která když jsou načtena špatně způsobí v lepším přápadě panic) a nějakou lehčí a rychlejší verzi pro data, která tak důležitá nejsou nebo jsou třeba chráněna nějakým dalším způsobem na aplikační úrovni.

Imho spatna metadata by nikdy nemela zpusobit primo panic. Rozsekany disk (kvuli pripojeni k vadne verzi operacniho systemu) muze nekdo pripojit. Od toho je taky v pripade chyby filesystem odpojen nebo remountovan RO. Panic smi byt zpusoben pouze neprimo: napriklad vypadkem dulezite stranky a nemoznosti jejiho nacteni. Nicmene mas pravdu v tom, ze muzeme chtit samoopravovat metadata. Kontrolovat jen pouzite bloky lze udelat na urovni block-device, protoze muzeme predpokladat, ze se nepouzite bloky nepouzivaji, t.j. pokud chce fs zapsat neco do nepouziteho bloku, tak ho predtim nebude cist...

ad panic -- celkem bezne se to tak dela, u extX treba situace, kdy se nejak poskodi descriptory grup je dost tezke prejit do RO rezimu, protoze v takovem pripade se neda ani cist, natoz udelat page out stranek. V takove chvili bych ja, jako uzivatel os ocekaval, ze spanicuje. Na panicu neni vubec nic spatneho, podle me je to v mnoha situacich to nejlepsi reseni. Ale chapu, ze tohle je zrovna hodne subjektivni.
ad kontrola dat -- samozrejme ze to jde delat na urovni zarizeni (tak se to ostatne delat ted, v hw resp. ve firmware) a neni to vubec nic spatneho. Jen jsem tim chtel rict, ze ZFS jde o neco dal: jednak ruzna "uroven zabezpeceni" pro ruzne bloky, druhak to, ze napr. pro blok, ktery jsem prave smazali (a zapsali do nej nuly nebo neco jineho) uz nebudeme pocitat a ukladat nekam checksum, protoze je to zbytecne.

Aha, tady je rozdil mezi /smazanim/ a /wipovanim/. Kdyz blok 'smazu' tak bezna praxe je, ze ho proste jen prestanu pouzivat. Pouze v pripade 'wipe' ho prepisu, aby nekdo nahodou neprecetl (snadno) citliva data. Nevidel jsem ale, ze by nekdo optimalizoval rychlost wipe. Takze skutecne jen souhlasim s tim, ze ma smysl ruzne zabezpeceni pouzivanych bloku. Uvazovat o tom jak jsou zabezpece nepouzivane bloky je imho irelevanti.

Ad.
1. mozno tak nelinuxovy... medzi Unix-mi je to bezna vec...
2. tiez uplne bezna vec... staci si co-to precitat o reed-solomonovych opravnych kodoch. Doskrabane CD sa da tiez citat... dokym nie je doskrabane prilis.
3. treba pozorne citat... ale o pol tretej rano sa pozornost asi tazsie udrzuje.. ;-)
4. "nesporné výhody" objasni prakticke pouzivanie... snapshoty o ZFS su daaleko prepracovanejsie na temu bezna pouzitelnost ako snapshoty u "jako v LVM".

1. "neunixovy" ... "unixovy" pristup znamena, ze je spousta malych programku, kdy kazdy dela jen svou praci a dela ji dobre. To, ze se to na dnesnich unixech casto nedodrzuje je vec druha.

2. Jak jsem jiz psal, disk ma crccka na fyzicke urovni. To jak je popsana "samoopravnost" na obrazku v clanku zase ukazuje jen na detekci chyb a ne na reed-solomona. Vtip je v tom, ze crc se da spocitat rychle, reed-solomon je vyrazne pomalejsi.

3. No popravde tam je L2ARC popsano tak vagne, ze opravdu nevim jestli je to vylepseni oproti "beznemu filesystemu" (t.j. nikoli o proti stavu kdy tam L2ARC neni). Pokud se popisuji /vyhody/ tak se srovnavat musi.

4. To je ta jedina vyhoda ZFS o ktere vim. Snapshoty, ktere na disku zabiraji jen tolik, o kolik se lisi od nasledujiciho snapshotu/aktu­alniho stavu. Vse ostatni je, pokud vim, jiz dlouhou dobu implementovano v jinych FS a casto lepe.

A rebuildoval jste nekdy pole o velikosti nekolika desitek TB? Protoze ZFS rebuilduje na rozdil od hloupeho RAID pouze skutecne obsazene misto.

Mam tak trochu jiny pohled na vec. Takovy hodne filozoficky: Co slozitost?
Mysleno zcela vseobecne. Celkem verim, ze ZFS je nabuseny FS a nechci upadnou do
flamu zda je lepsi, rychlejsi, krasnejsi tohle ci ono.
Jde mi o takovou tu ideu cistoty navrhu a rozumne dekompozice reseni. Nemohu se totiz zbavit dojmu, ze soucasne implementace fs jsou stale vetsi a slozitejsi bumbrlicci, coz ma (dle meho nazoru) tyto dusledky:
* vic kodu = vice chyb. Napr. ext3 je asi mene nabusena nez zfs, ale je tu s nami uz dost dlouho a nemam pocit, ze by byla "definitivne" odladena nebo ze by na ni delalo zrovna malo lidi. Z popisu ZFS, BTRFS, ... je jasne, ze jsou jeste slozitejsi a statisticky receno asi i chybovejsi.
* slozitejsi fs - vetsi problem s bezpecnosti (opravdu vyuzijete vsechny moznosti toho fs?, znate je vubec vsechny?, a mate je vsechny spravne nastavene...?)
* dekompozice - je hezke, ze "monolity" funguji, ale je take treba aby je nekdo umel pojmout (pro ucely administrace), aby bylo mozne je prizpusobovat okolnostem.

Mozna pisu malinko nejasne. Jde mi o to, ze veci zacinaji byt kvuli efektivite a ruznym killer-feature prilis velke a slozite a paradoxne je to pak kontraproduktivni, protoze se pak stavaji nezvladatelnymi (z hlediska vyvoje, udrzby, administrace, ...). Tenhle problem je samozrejme obecny, a lidstvo se s nim potyka dnes asi vsude. Podle me v oblasti fs stale neni dotazena dekompozice.

Priklad: kritika toho "RAIDU uvnitr fs". Pravdu maji oba tabory.
Ano RAID by nemel byt zadratovan spolu se spravou souboru a adresaru.
Na druhou stranu, toto spojeni umoznuje delat zajimave veci, ktere za to urcite stoji. Mno, podle me je spravne reseni a la sitovy stack - tzn. neco jako "vrstveny model" fs - tzn. vede to asi k vylepseni VFS. Podle me je to v tomto
konkretnim pripade jen a jen o tom, ze rozhrani mezi "vrstvami" s touto moznosti (ze "RAID neco vi o souborech/adre­sarich") ted momentalne nepocita.
Vtip je v tom, ze
1) lide by se v tom vyznali - co ktera "vrstva" dela a s kym si "povida"
2) bylo by mozne silne(=uzitecne) prizpusobit reseni podminkam (vynechani vrstvy, nahrazeni vhodnejsim resenim pro danou vrstvu (fuuj, konkurence. Linuxaci maj prece radi monopol :-) ),...)

Samozrejme objevuji kolo, ona ta dekompozice je v ramci os, fs, ... samozrejme
nejak udelana (jinak uz by se to davno rozpadlo), problem je ale v tom, ze ne asi dostatecne obecne a soucasne siroce (aby se tam vesly vsechny mozne implementace fs).
Coz pak vede na velka moniliticka reseni fs, ktera "umi vsechno". Ja bych radsi mnozinu komponent fs z ruznych zdroju, ktere si poskladam do znameho obecne uznavaneho fs-stacku. Samozrejme nic se nema prehanet. Je to otazka miry a ja si jen myslim, ze soucasna reseni nam
zacinaji prerustat pres hlavu.

Jo a nepiste mi, ze prizpusobit si muzu i soucasne fs (napr. si vypnout zurnalovani kdyz bych to treba nechtel (z duvodu vykonosti?)). To totiz proste
neni totez jako pouzit fs, ktery to napr. zurnalovani nema.

Mimochodem obdobna situace je podle me napr. ve svete J2EE, kde jsem tuhle cetl zabavny a neskutecne presny popis: "svet J2EE je ekosystem". Je to smesne a pritom nemilosrdne presne. Jave zdar! :-)

Jde o to pro jaky segment je ZFS primarne urceno a tim neni Desktop a dokonce ani ne servery nizsi stredni tridy. Vyhody tohote reseni se projevi stejne jako nasazeni "velkych" unixu az na velke clustery v Enterprise sfere. Tyto killer feature se zda totiz pomalu stavaji nutnosti.

Stejne jako zde bylo napsano ze ZFS zere stovky mega pameti, "muj" nejslabsi server se ZFS ma 20 GB pameti a v tehle sfere zacina byt nejaky ten GB pameti fuk.:-) Je nedoporucovano mit 32-bit architekturu a min jak 4GB pameti.

Jinak rozdelit ZFS na vrstvy asi neni uplne spatna myslenka, jen pak je ten problem, ze nemate pri te ktere konkretni konfiguraci garanci, ze to bude fungovat, coz u tohole mate od vyrobce.

S tou slozitosti je to pravda, ani na skoleni Solaris internals primo v SUNu nebylo mozne ukazat, jak se v debuggeru dostat od cesty k souboru k binarni podobe dat na disku. Pricinou je prilis mnoho mezivrstev a odkazu na odkazy + zasmodrchani mezivrstev (zejmena kompresi) a neexistujici nastroje, ktere by tuhle slozitost skryvaly.

Slozitost ZFS pri trivialnim desktopovem pouziti je neadekvatni, slozitost serveroveho pouziti je srovnatelna nebo vetsi, nez u LVM a VxVM, debugovatelnost je minimalni (blackbox). Debugovatelnost LVM je naopak velmi vysoka, u VxVM je to hure dokumentovane, ale stale se daji delat i rozsahlejsi rucni zasahy. U ZFS preji hodne stesti.

Pametova narocnost ZFS je tragicka, licence a uzavrenost kodu je smrtici.

Jenže když budu chtít nasadit ZFS tam, kam je tak nějak mířen - mid-enterprise storage, tak mě tohle fakt vůbec nezajímá. Jestli jde něco v debuggeru.

LVM nebo VxVM se ZFS snad nelze srovnávat, poskytuje podstatně jinou úroveň funkcí (velmi dobré snapshoty, RAID-Z).

Já si od Oracle koupím licenci a support ZFS, za to očekávám, že to mají otestované a v případě problému ho budou řešit. Ale nespoléhám na to, takže mám i kompletní zálohy, ideálně na jiné technologii. Až se ZFS podělá, fakt to nebudu debugovat a doufat, že ty data co z něj dostanu budou OK. Na to mám ty zálohy.

Paměťová náročnost - nezájem, v reálu to prostě funguje tam kde potřebuju za X peněz. Licence a uzavřenost - proč smrtící? Co mi poradíte použít místo ZFS, pokud chci strovnatelné vlastnosti? IBM GPFS je taky uzavřený, ale nabízí takové vlastnosti, že na smrt to teda nevypadá. Když se přes ten HW a SW točí peníze, tak fakt není problém ho koupit, pokud mi pomůže vydělat víc.

Složitosti bych se s ohledem na spolehlivnost nebál. Co jsem viděl nějaké whitepapery o vývoji ZFS, tak veškeré funkce jsou pokryty automatickými testy, na které se používají stovky serverů a tisíce kusů disků. Testuje se i chování při tvrdém výpadku napájení, poškození dat na některém disku atd. Samozřejmě to nebude úplně dokonalé. Ale který linuxový FS je takto systematicky testován?

Když nahlédnete do nějakých přednášek o ZFS, tak zjistíte, že ten RAID-Z algoritmus je poměrně hodně provázán s funkcemi vlastního FS. Oddělení těchto věcí do samostatných vrstev by pravděpodobně mělo negativní dopad na výkon, a pro dosažení srovnatelných funkcí by musely být obě části stejně vyvíjené synchronně.

Citace: Ale který linuxový FS je takto systematicky testován?

To přesně nevím, ale před rokem Google si přemigroval tu svou půlmilionovou farmu z ext2 na ext4 a před tím dost testovali.

No myslim ze s tou slozitosti to nebude tak zhavy. Mozna spis naopak - tim ze pouziju novy koncept a napisu ho ciste znova a nove vlastnosti dostavam z vetsi casti zadarmo prave diky treba COW, nemusi byt slozitost vyssi.

Mozna by to mohlo byt i naopak kdyz si vezmete evoluci ext2->ext3->ext4. Jen uvazuju, ale mozna by sme se divili jak by dopadlo takove srovnani ext3/ext4 a napr. btrfs co do slozitosti kodu.

Musíte brát v úvahu pro jaké použití je ZFS navrženo -- určitě to není fs pro mobilní telefon a ani pro domácí počítače. Měla by to být náhrada za FFS/UFS/extX a spol v mid- a high-end, navržená tak, aby byla použitelná i za 20, 30, možná 40 let.
Je pravda, že je to docela dost kódu, když si ale dáte trochu té práce a podíváte se do něj, možná budete překvapen jak jednoduše a přirozeně spousta věcí funguje. Moc často se nemluví třeba o tom, jak (podle mě chytře) je řešena io pipeline, zkuste se zaměřit třeba jen na ní a srovnat to s tím, jak to samé vypadá třeba v ext4 a LVM. A pak si představte, že máte stroj třeba s 1024 CPU...

Samozřejmě že si v SUNu mohli říct, že zase jen trochu přiohnou 25+ let starý UFS, dolepí do něj extenty, trochu poladí volume manager a zkusí z toho vytřískat ještě pár dolarů. Ale myslím, že můžem být všichni rádi, že někdo měl odvahu vidět i trochu dál.

Mno, chtel jsem vlastne jen poukazat na klasicky problem modularita kontra intergrace, ktery se objevuje v ruznych variantach vsude mozne. Oboji ma
sve vyhody i nevyhody a nakonec je podle me cela diskuze o vhodne mire.
Osobne se nepohybuji ve sfere high-end entreprise a tudiz tezko posoudim pozici ZFS, ale z vasich komentaru soudim, ze stupen integrace u ZFS vam prilis nevadi, pokud to samozrejme prinasi vykonostni a jine vyhody.

Ja osobne si myslim, ze ZFS ma jiste budoucnost, ale myslim, ze jejich uzivatele
jeste ceka spousta legrace pri reseni ruznych obtizi.

Kazdopadne dekuji za nazory...

Co se té složitosti týče, máte nepochybně pravdu, že zfs je složitější než ext3. Na druhou stranu to nutně neznamená, že z té složitosti přímo plyne větší ohrožení dat. Je totiž složitější také proto, že přidává další ochrany.

Existují i daleko složitější systémy na ukládání dat, které desetiletí řeší daleko složitější věci, než jen ukládání souborů. Ano, mám na mysli databázové systémy. Před nimi je i zfs jen projekt na úrovni semestrální práce. Zrovna DB systémy jsou příkladem funkčního obrovského monolitu, který asi nikdo ani nechce dělit na kousky (jen proto, aby monolitem nebyl).

Problém také je, že některé požadované (či dnes spíše už nutné) vlastnosti pomocí rozdělení na vrstvy nedosáhnete. Sjednocením raidu, volume manageru a systému souborů do jedné vrstvy můžete dělat věci, které by se jinak dělaly jen velmi obtížně nebo značně neefektivně.

Nechci se pouštět do flame o to, jestli ext3 je nebo není odladěná. Prostě funguje. Vývojáři mají obrovskou kouli na noze v podobě kompatibility a všechny nové featury prostě musí budovat nad hotovým a neměnným "on disk" formátem dat (mimochodem, tuto binární kompatibilitu některé DB vůbec neřeší a přechod mezi verzemi je možný pouze přes SQL dump a load).

Nejak jsem nepochopil tu zminku o chybovosti:
Chybovost pod 0.01%. To znamena, ze jeden z 10000 files bude koruptnuty? Pri stovkach tisic files na disku vynasobenych frekvenci se kterou se files prepisuji, se mi to zda trosku moc. Kdyby to byla setina miliontiny, jeste stale by to bylo moc.
Krome toho, jestli je v tom patent od Oraclu (jak jiz nekdo zminoval, patent na vec co se ovsem pouziva desitky let), tak tento system bohuzel nema budoucnost.

To číslo je nesmysl pro novináře. Už jen ten znak procenta naznačuje, že to nemá s chybovostí ani spolehlivostí nic společného. Ta se u disků udává v úplně jiných jednotkách. A u FS samotného to ani nedává smysl, to je SW a buď funguje nebo ne. Jak chcete měřit spolehlivost kupříkladu OS, který funguje, ale při současném spuštění jistých dvou konkrétních programů padne na hubu? Podělíte dvojku počtem nainstalovaných programů? Nebo počtem všech existujících programů na světě? Možná snad po vzoru disků počítat průměrný počet kliků do vynuceného restartu :-)

To je len po novom napísane 99.99% ...

souborový systém, který při nedostatku paměti pro svou činnost vyvolá kernel panic, bych raději nepoužíval

Presne a hlavne v tej Enterprise sfere kde aplikacie pracuju zo stovkami GB dat...
Povodne sa FS navrhovali aby OS skor podporovali a nie ho davali dole ked ide do tuheho - no proste mne tu XFS nikto z hlavy/ disku nevybije :)
Na druhu stranu je pravda ze pre mna nejake snapshoty FS naozaj nemaju vyznam - niekto to ale moze povazovat za velmi dolezitu funkciu ktora mu zjednodusuje zivot.

Stovky GB dat jsou jeste v pohode, na to opravdu nema cenu mit specialni FS. Predtavte si treba situaci, kdy mate file server z 50 TB dat nebo neco podobneho. V takovem pripade mate problem uz jen se zalohami a je neocenitelne mit na to vsechno hodne inteligentni volume manager s FS.

Ty snaphoty jsou idealni napr. pokud mate databazi uvedete ji do konzistentniho stavu, udelate snapshot, reknete, ze muze dal zapisovat a v klidu na pozadi si zaloho odlejete. Toto se casto resi ingraci ruznych agentu na urovni diskoveho pole, kdyz to pak jede rovnou na pasku nebo VTL. Dlasi prima fuknce je, ze pokud Vam jede na ZFS cely system, tak proste pred upgradem udelate snapshot a nabootujete do noveho prostredi, kdyz neco nefunguje jste okamzite schopny se vratit(takto to ma napr. OpenSolaris pri aktualizacich automaticky), ale toto se da zese udelat pres pole pokud bootujete po fiberu, ale to nei vzdy zadouci.

Nejako mi nesedia tie čísla - podľa mňa má 1 zettabyt miliardu terabytov, a podľa wikipédie je limit ZFS (na jeden zpool) 256 zettabytov, a nie 256 <b>quadriliónov zettabytov</b> - to by bolo 2¹⁰² bytov, čo mi pripadá "trošku veľa"

Jsou to kecy mne to jede v **400MB RAM** Vmware ESX masine s timhle nastavenim co mi dodal spolu s predpripravenou masinou muj freebsd admin. Zamestnavam schopny lidi, za 2-3 hodiny mi to dodal. S mene nez 400MB Ram je to pry opravdu nestabilni, nenalezl vhodnou konfiguraci.

FBSD 8.2RC2 32 bit

vm.kmem_size=330m
vm.kmem_size_max=330m
vfs.zfs.arc_max=200m
vfs.zfs.arc_min=32m
zfs_load=yes
vfs.root.mountfrom="zfs:­root"

Prekompiloval jsem si na v tom gnome z portu a ted mi v tom bezi gnome. Nepada to na nedostatek pameti. Kdyz spustim kompilaci www/libxul (coz je dost pametove narocne) tak to opraskne jen ten c++ prekladac a neslozi to cely system.

==
Vy jste tady jeden neschopnejsi nez druhej. Neustale tu knourate jenom nejde, nejde, na destkop to nejde. Takovi ubreceny lidi jsou mi k nicemu. U nas si nehrajeme na delku praxe a tituly - u nas hrajeme na vysledky.

Vysledek je ze zatimco vy jste tady vymysleli duvody proc to nejde my jsme pracovali na tom abychom to udelali. Proto mame vysledky a vy mate seznam 10 ti duvodu proc ZFS nejde pouzit.

My jsme v IT uspesni, vy jste nuly.

Plně s Tebou souhlasím, soudruhu.
Ale nezapomeň - 100 procentní Lenin jsem jenom já.

Čest potírání nepřátel pokroku :DDDDDDDDDDDDDDDDDD

Ja mam na jednom servery ZFS, este na FreeBSD 7.1 a mam s nim mierne povedane problem. Masina ma 4GB RAM. Problem je v tom, ze par dni to ide v pohode (je to v podstate iba file server), ale potom to zacne spomalovat, az to skonci v zalostnych cislach. Inak je to stabilne, len ten performance impact je zly. Ma s tym niekto podobny problem, alebo pozna niekto riesenie? Po reboote to zase par dni ide normalne, a tak dalej...

Tu je nieco z loader.conf-u:

vm.kmem_size_max="1536M"
vm.kmem_size="1536M"
vfs.zfs.arc_min="128M"
vfs.zfs.arc_max="768M"
vfs.zfs.prefetch_disable="1"

pokud slouzi masina opravdu jenom jako file server, zvysil bych arc_max na 2GB. Pokud jde o ZFS, plati zde 3 pravidla: pamet, pamet, pamet..