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/adresarich") 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...
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).