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

1. Volume manager by neměl být součástí filesystému. Koncept, že si každý FS znovu naimplementuje RAID, je - mírně řečeno - neunixový.

2. Tvrdit, že FS zajistí konzistenci dat je trochu odvážné - stačí pád aplikace uprostřed zápisu, a žádný filesystém nemá šanci. Pomohly by jedině FS transakce, ale nevím o žádném FS, který by je podporoval.

3. Mělo by se říct, že ZFS ARC je obdobou linuxové buffer cache, ZFS intent log je klasický žurnál, a vysvětlit, k čemu je L2ARC (tak jak je popsaný by to byla jen zbytečná duplikace funkce ZFS ARC)

4. Nenašel jsem ty "nesporné výhody" ZFS, snad jen podporu hodně velkých disků, ale to se využije jen v extrémním případě. Tuším, že snad snapshoty na úrovni FS by mohly mít nějaké výhody proti snapshotům na úrovni volume manageru (jako v LVM), ale z povrchního článku jsem se moc nedozvěděl.

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.

RAID - pokial viem tak pridanie noveho disku do existujuceho RAID-u v ZFS mozne nie je.. ale ak sa mylim alebo sa nieco zmenilo budem iba rad :)

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

"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.

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ě.

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...

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.

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..