Názory k článku Co umí souborový systém ZFS

Dokud bude ZFS dostupny pouze pod emulacni vrstvou fuse, neda se mluvit o souborovem systemu ani nema ni malou nadeji na uspech, jakekoli jine kvality muze mit.

Je nutne ho "propasovat", klidne i za cenu tainted, ale jako regulerni souborovy system, ma-li mit sanci...

To jako ze si udela neco jako RAID 0 pres vsechny dostupne disky? A da se to treba nejak kontrolovat nebo to opravdu dela samo? Tenhle clanek mi prijde nejak moc letem svetem ale i tak lepsi nez nic :-)

Samozrejme, ze se to kontrolovat da (a taky musi ;-). Prikazem zpool muzete OS rict, ze ma vytvorit pool z disku, ktere v tom prikaze vyjmenujete. Zaroven muzete urcit, jaky typ redundance se ma pouzit (RAID 0, mirror, RAID Z). A pak teprve muzete ve vytvorenem poolu zacit vytvaret filesystemy.

Priklad z man-page prikazu zpool:
The following command creates a pool with two mirrors, where each mirror contains two disks.

# zpool create tank mirror c0t0d0 c0t1d0 mirror c0t2d0 c0t3d0

Ak si dobre pamatam z minuleho roku, tak niekto na operacnych systemoch II za zapoctak mal prave doplnovanie funkcii do ZFS a tusim prave v linuxe, ale tiez to mohlo byt *bsd. Resp. ked je to uz POSIXove, tak asi na tom moc nezalezi (aj ked v kerneloch rozdiel je).

Inak viacerymi vlastnostami mi pripomina Spiralog FS. Ze to zatial nefunguje ako root fs by mi az tak nevadilo, pre tu srandu by som to vyskusal. Este by mozno stalo za to urobit nejake benchmarky rychlost/CPU/mem load na nejakych zakladnych fs operaciach simulujucich 'priemerne pouzivanie' a porovnat to s beznymi fs ako ext2/3, reiserfs, xfs...

Aha, dik :-) Tiez som si nebol isty -- zdalo sa mi, ze ten ZFS z OS II bol sietovy FS. To mnohe vysvetluje.

Jdou data ukládat na disky redundantně? Když se tedy nějaký disk odpojí (porucha apod.), přežije to systém a hlavně všechna data?

Ještě by mě zajímalo, když jsou všechny nebo alespoň většina informací 128bitových, neklade to o dost větší nároky na CPU?

"Ještě by mě zajímalo, když jsou všechny nebo alespoň většina informací 128bitových, neklade to o dost větší nároky na CPU?"

To si myslim osetri prekladac: na 32-bit architekture bude aj tak vacsina cisiel (snad okrem velkosti suborov) malych, teda staci napr. jednoduche scitanie jednou instrukciou ALU, resp. je mozne pouzit FPU na velke cisla (tusim na x86 je max. 80-bit integer), ale to sa mi zda je pomalsie.

nieco v zmysle:
ADD EAX,EBX
JNC bolo_male_cislo_ziadne_pretecenie_pokracujeme
ADC ECX,EDX

label bolo_male_cislo_ziadne_pretecenie_pokracujeme
call nejaka_pekna_funkcia

to je zajimava myslenka setrit jedno scitani jumpem. Na jake platforme programujes ?

Kedysi som patlal x86-asm. BTW, pisal som to 4:44 rano a myslienka bola setrit dalsie 3 scitania (128-bit cislo). Este si pamatam LEA, ta sa zneuzivala na podobne triky casto.

Otázka: Porusuje Jan 1. zakon termodynamiky?
Stroj říká: Spíše ANO

Uz pravdupovediac neviem, ako je to na x86/AMD64 atd. s branch penalties. Pri prichode Pentia a neskor MMX instrukcii ma to uz prestalo bavit. Nicmene, CMOV na x86 je a je to prave instrukcia, ktora na 'salamovych klonoch x86' ako VIA C3 sposobuje dost velky bordel (VIA C3 ju nepodporuje, haltne preventivne CPU). Jedina zaujimava vec, co som ohladne asm v poslednej dobe videl, je IOMMU.

Na Intel Pentium 4 je to rozumné (pokud je výsledek sčítání většinou menší než 2^32), protože ADC je tam mikrokódované (asi 10 tiků), zatímco správně předpovězený podmíněný skok je pouze 1/3 tiku. Na AMD se klidně může použít ADC, protože je stejně rychlý jako ADD.

Pokud čísla budou často větší než 2^32, tak je lepší používat ADC, protože penalta za špatně předpovězený skok je 30-40 tiků, což je mnohem méně než trvání ADC.

Jak uz nekdo poznamenal nize, ZFS v sobe kombinuje vlastnosti softwaroveho volume manageru a filesystemu. Takze samozrejme podporuje i redundanci. Na Solarisu 10 podporuje mirroring a RAID Z.
Mirroring ovsem nefunguje uplne presne tak, jak jsme zvykli z volume manageru, protoze se nemirroruji bloky disku. Misto toho mohou byt v metadatech souboru ulozene odkazy na vice kopii datovych bloku tvoricich soubor. Takze k dosazeni redundance staci, aby se pouzilo vice kopii techto datovych bloku a aby tyto datove bloky byly ulozeny na ruznych discich. Takze je to vlastne mirroring na urovni filesystemu.

RAID Z je format velmi podobny RAID 5, ale (na rozdil od RAID 5) mu nevadi vypadek proudu pri zapisu (coz je duvod, proc diskova pole s RAID 5 musi byt zalohovana baterkou).

Krome toho se pracovalo i na formatu, ktery umozni prezit bez ztraty dat vypadek libovolnych 2 disku v poolu, ten ale zatim neni v Solarisu 10. (Nevim, jak je na tom v soucasne dobe OpenSolaris.)

cdo ja vim, tak vsechny disky by ti mel ukazat treba prikaz format (interaktivni utilita pro vytvareni partici, kontrolu disku atp). Ja jsem si hral se Solarisem v qemu, kdyz pridas novy disk (vlastne jakekoliv zarizeni), musis dat #touch /reconfigure a restartovat - toto znovuvytvori vsechny spesl soubory. Pokud disky vidi VMware, reconfigure by melo pomoct v solarisu.

No letme, fdisk umi vse a kupodivu je zminen jako jediny v tarining course.
jinak klasicky:
dmesg
getdev
getdev type=disk
devattr -v {device}
drvconfig
devlinks (pokud nechces delat rekonfiguracni reboot ala touch /reconfigure, boot -r v openconsoli(ta na vmware asy nebude) etc.)

Hm, na Sparcu bych doporucil

# cfgadm -al
pripadne zapnout unconfigured SCSI zarizeni (cfgadm -c , viz man), stava se,
ze SCSI disky nevidis prave proto, ze radic neni zapnuty.

# devfsadm [-v]

a hotovo, ted uz ve format uvidis, co je v nabidce. Kazdopadne je lepsi
dat novym diskum alespon defaultni label.

Od Solarisu 8 vyse je asi zbytecne cokoli komplikovanejsiho, predpokladam,
ze na x86 Solarisu to pujde take :-)

To je slušná kapacita, doufám, že máš na šuplíku pořádný zámek.

No jo RAID6 je uz nejakou dobu, ale podle me bude zdrzovat i ruzna velikost bloku, cheksum bude super, ale zase bude zdrzovat. Takze s toho bude FS na FileServer, kde neni rychlost zase tak dulezita, zato na DB, kompilaci, multimedia nebude.

proste napad dobry, zaplnil diru, ale bude to minoritni FS na specificke veci.

jasne, bude minoritni, protoze se nejakymu izakovi nezda, ze mu na tom pekne pojede kompilovani a databaze. :)))))))) ok, ted vazne. na kompilaci bude asi nejidealnejsi fs v ram, tedy mfs, tmpfs atd., na ty databaze tu mame porad jeste ffs, kdyz se nekomu zfs nezda.

Nechci ryt, ale fileservery jsou docela klicove, ne minoritni. Ne vse je databaze, jak nam administratori databazi neustale tvrdi. Ano, pro databaze nejsou vsechny zalezitosti ze ZFS zajimave, na druhou stranu, pro databaze je casto zajimavy i jen raw device. Databazisti vzdy muzou sebrat ext2 nebo ufs s vypnutym loggingem (zurnalovanim) a muzou si spokojene chroupat.

Co se tyce kompilaci a multimedii, zrovna tam je udrzovani konzistence dat dost zajimava zalezitost.

Jedna z hezkych vlastnosti ZFS, ktere clanek nezminil je napr. snapshot v konstantnim case.
Diky tomu, ze ZFS funguje na principu Copy On Write staci pri vytvoreni snapshotu prestat uvolnovat zmenene bloky. Takze vytvoreni snapshotu je prakticky okamzite a navic pomerne prostorove efektivni, protoze misto, ktere takovy snapshot zabere je stejne, jako misto zabrane bloky, ktere se zmenily od doby, kdy byl tento snapshot vytvoren.
A takovych hezkych vlastnosti ma zfs vic.

Pooling mal uz aj AdvFS v Tru64 unixe (stary Compaqovy unix).

Presneji receno poolovani/multiple FS trees/snapshoty umel uz AdvFS na Digital Unixu v3.2 firmy Digital, nejpozdeji tak v roce 1997. Nebo to byl jeste Polycenter AdvFS na DEC OSF-1 ?? :-) Ale ZFS me zajima, myslim, ze ho budu pouzivat :-) Edheldil

Kompresia je pekna vec, ale stale len spomaluje a usetrene miesto nieje garantovane, cize skoro nepouzitelne.

Práve ta kompresia to bude najviac urýchľovať. Disky sú stále oveľa pomalšie ako CPU. Už dávnejšie som skúšal upx kompresiu OpenOfficu vo Windowse a čuduj sa svete, štartoval 3-krát rýchlejšie! Toto je o niečom inom, ale stále to bude primárne o urýchlení ako o šetrení miestom. BTW aj Oracle dokáže používať kompresiu tabuliek (a tiež to pekne urýchľuje čítanie).

"Sun ale se ale vyjádřil" ??

radeji snad 16 * 10^18

Prostě matematicky: 2^128 / 2^64 = 2^64 - tolikrát může ZFS adresovat více prostoru, než 64bitový FS. A 2^64 = (2^4)^16 = 16^16. Ovšem desítkově by to bylo asi takto: 2^64 = 10^(64/log2(10)) ~ 10^(19.266) = 10^(1.266) * 10^18 ~ 18 * 10^18. A nebo se to normálně umocní na kalkulačce :D

No jo, ale já si stejně pořád myslím, že tam má být 18 * 10^18. Čistě matematicky. Možná ale, že tam je počítaná nějaká ztráta v adresních tabulkách nebo co tam je :)

Souborovy system v sobe NEMA obsahovat funkce diskoveho manageru - ma pracovat nad danym blokovym zarizenim. Tohle je chyba koncepce. FS pres nekolik blokovych zarizeni je blbost neprilis slucitelna s UNIXovymi koncepcemi. Doufam, ze to nekdo oddeli.

Muzu vedet, proc? Myslite tu zalezitost, ktera se tyka systemu rozdel a panuj, tj. rozdelit praci na vice utilit, vice vrstev v tomhle pripade?

Ano, rozdelit to na diskmanager, ktery se da pouzit i s jinym FS, a na vlastni FS. Kdyz bude kazdy FS obsahovat vlastni diskmanager, prijdeme o moznost pouzit na ruzne adresare ruzne FS, kde kazdy je vhodnejsi na neco jineho, a sdilet stejny prostor. Takze to nakonec bude jako udelat RAID0, a na vznikle blokove zarizeni hodit ZFS, nebo spis horsi - zbytecny kod v jadre, zbytecna administrace, jedina vyhoda v existenci nekolika root adresaru. Proste zakladni filosofie Unixu je mit jednoduche nezavisle programy/moduly, ktere delaji dobre jedinou ulohu, a jdou snadno kombinovat.

Nebudu zde argumentovat pro a proti, spise se pokusim presvedcit v rozumnem horizontu nektereho z tvurcu ZFS na navstevu republiky a pak na diskuzi s nim vas :-) Sam mam koncepci rozdel a panuj docela rad, i kdyz jejich argumenty pro jejich koncept take chapu, jde o to, co je vyhodne pro uzivatele.

http://mail-index.netbsd.org/tech-kern/2005/12/14/0009.html

To neni chyba koncepce. To je odklon od koncepce stare a prichod koncepce nove, ktera umoznuje delat i veci, ktere predtim mozne nebyly. Diskovy manager se zkratka nemuze chovat inteligentne pokud funguje jenom na urovni diskovych bloku.

Pak mi to prijde jako krok spatnym smerem, ma-li mit kazdy FS vlastni diskmanager...

Na druhou stranu je to jediná možnost, jak udělat efektivní diskmanager využívající všechny funkce systému.

Ano, v tomhle smeru jdou opravdu zakladni argumenty tvurcu ZFS, ale ne kazdy s nimi souhlasi. Na druhou stranu, je opravdu nutne, aby kazdy diskovy oddil obsahoval jiny filesystem? Vynechame-li databaze jako pripad sam pro sebe, tak jeste jiny typ obecnych dat je na tolik zvlastnim pripadem? Takze, je opravdu treba, aby diskmanager a filesystem manager musely byt oddelene? V ZFS se koncepcne prolinaji, bez diskmanageru by ZFS nemohlo obsahovat mnoho podstatnych ficur, vcetne zajistene konzistence, nejspise. Nebo, spise, mohlo by, ale prace diskmanagera by byla dublovana :-)

Taky mi to prijde jako bastl, ale na druhou stranu ZFS pool (nebo jak to nazvat, proste ta cast ZFS co je ekvivalentni volume manageru) umi byt pristupny nejen jako POSIXovy filesystem, ale i treba jako blokove zarizeni (takze je tam mozno pouzivat i ty snapshoty a self-healing a podobne nesmysly, a nad tim mit treba Oracle nebo i mozna UFS).

Cili na jednu stranu je to trochu bastl/layering violation, ale na druhou stranu ty jednotlive vrstvy jsou asi pristupne i separatne. Dovedu si pak predstavit, ze tim ze FS vi, co je pod tim za disky, muze lepe rozkladat zatez (ostatne tohle delalo treba i XFS nad SW RAIDem - sam filesystem vedel, z kolika disku se RAID sklada a jaka je velikost stripu, a podle toho dokazal posilat operace paralelne).

Ted nekdy Sun predstavil nejake zelezo se dvema opterony a strasne moc disky (28?) ktere by se pekne na takoveto velke ZFS hodilo.

-Yenya

Pravdepodobne mate na mysli thumper.

Jak je na tom tento FS s rychlosti?

Dobre, dekujeme za optani.

Ne, ted vazne, zalezi na nasazeni a s cim to srovnavate.

Delal jsem nejake drobne testy na Netre T1/Solaris 10 se ctyrma 18G diskama v mirroru 2x2 pod SVM a ZFS. Test pomoci utility tiotest, 1 thread, 4096 blocks

Used file system     |  Seq. Write | Random Write |   Seq. Read | Random Read |
---------------------+-------------+--------------+-------------+-------------+
UFS/SVM              | 13.711 MB/s |   0.458 MB/s | 33.694 MB/s |  0.793 MB/s |
ZFS compression off  |  9.607 MB/s |   0.247 MB/s | 22.014 MB/s |  0.506 MB/s |
ZFS compression on   | 25.669 MB/s |   1.896 MB/s | 19.756 MB/s | 14.966 MB/s |
---------------------+-------------+--------------+-------------+-------------+
UFS/SVM raw device   |  7.278 MB/s |   1.467 MB/s |  9.387 MB/s |  0.802 MB/s |
ZFS com. on, raw dev.|  0.548 MB/s |   0.548 MB/s | 34.555 MB/s | 28.256 MB/s |

Mne by stacilo keby sa dalo zo ZFS bootnut na sparcoch ;-)

Pokud se soubor na disku nikdy nepřepisuje, tak to musí příšerně fragmentovat soubory, do jejichž vnitřku se často náhodně zapisuje (třeba databáze). Jak se to řeší?

IMHO pro db mas pouzivat raw device, nebo co nejprimitivnejsi filesystem (jak jiz nekdo zminoval, treba ext2, tzn. neco bez journalovani).

Filesystem primarne slouzi k jinym ucelum, kde typicka operace je otevrit soubor, potencionalne presun na nejakou pozici (ale krome EOF znacne netypicky) a nasledny zapis/prepis az do konce filu. Tady u ZFS fragmentovani prilis nehrozi.

IMHO jsou pro databaze velmi vhodne extent-based filesystemy. To jsou takove, ktere soubor popisuji jako pole ukazatelu na extenty. Extent je velke mnozstvi po sobe nasledujicich diskovych bloku. Takze potom staci (v idealnim pripade ;-) rict, ze soubor zacina na disku na bloku cislo x a je y bloku dlouhy. A to jsou veskera potrebna metadata. Samozrejme, ze v realu to potom zdegeneruje na pole ukazatelu, navic je pro takovy filesytem nevyhodne, pokud ma prilis plny disk, pripadne pokud se na disku jiz nevyskytuji dostatecne dlouhe extenty. Pokud se ale databaze chova tak, ze si na zacatku naalokuje velky soubor, ve kterem pak operuje, je tento pristup vyhodny. Nastesti se tak vetsina databazi skutecne chova :-). V Oracle jde i nastavit, po jakych kusech se ma ten soubor zvetsovat, pokud zacne dochazet misto. Tusim, ze default tam byl kdysi neco kolem 20 MB, ale nevim, jak to DB admini nastavuji dnes.
Naopak se pro databaze nijak zvlast nehodi tradicni unixove filesystemy zalozene na konceptu inodu. A mam pocit, ze takovym systemem je i ext2. (Kdyz tak mne prosim opravte.) Tento druh filesystemu byl pro zmenu vyvinut pro "normalni" praci ;-).

Ja bych to rekl takhle: Filesystem je specializovana implementace databaze. Je specializovana na konkretni typy ulozenych dat ("soubory") a konkretni operace ("open, creat, ...").

Psat databazi nad databazi (tj. DB, ktera pracuje nad vrstvou filesystemu) je proto povetsinou blbost. A stejne tak je povetsinou blbost pouzivat obecnou DB jako filesystem (select obsah_souboru from tabulka where jmeno_souboru='...' apod.).

Samozrejme, kazde pravidlo ma sve vyjimky :-)

Dost dobrý článek. Byla by aktualizace?