Vlákno názorů k článku Súborový systém ZFS – konzistentnosť dát od VM - 1. Volume manager by neměl být součástí filesystému....

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.