ZFS: Desať dôvodov na reformat vašich diskov (diskuse)

[..... Izak .....]

No, standard ... akorat jestli jsem to dobre pochopil, tak umi pri rozpadnuti mirroru opravit jen dany blok a ne jako ostatni celi disk, nenutnost fsck jsou kecy a muze to rict jen debil, protoze i ext3 a jeste vic XFS to obcas potrebuje, nekdy dokonce vadna pamet provede rozhaseni FS a pak se opravuje blok po bloku.

Jinak je to standardni SW Raid, mozna i s LVM2 .... akorat ze v unixu neni tak bezne, ze kdyz se disk premisti, ze si jej OS najde, v linuxu je to normalni a UNIX zvrhlosti s nenabehnutim systemu a pres STRING zistovat obsah volum grupy, export, import a hledani v bordelu ala "/dev/rdev/sdkhnfgb3u8y583" at zie VeritasVolumeManager .... takze vitam Solaris ve 20 stoleti (ovsem se zpodzdenim az v 21)

Trochu mi to pripomina M$, prijde z necim co jiz davno jini pouzivaji, a dela s toho velky boom, dokonce vetsi nez IBM s JFS a enterprise volume manager, ktery umi sam dinamicky pridavat misto kdyz dochazi.

[ajikdpoe]

Plne s tebou suhlasim, uz len dodam ze klucovym problemom je zvolit dostatocne "cool" nazov produktu a napumpovat dost prachov do marketingu.

[Lukáš Cirkva]

Doporučuji číst příště pozorněji. ZFS není LVM ani SW RAID. Zettabyte File System (ZFS) je 128 bitový open-source souborový systém s funkcemi LVM a SW RAID. V nedávné době byl ZFS vydán pro Solaris x86 a SPARC platformu, ale je natolik zajímavý, že je vyvíjen pro BSD a plánuje se pro OS od Applů. Několik základních vlastností ZFS, které nebudu nijak komentovat, protože uživatelé sami ukáží, zda je ZFS na trhu potřeba.

• 128-bit file system 16 billion billion times the capacity of 32- or 64-bit file system
• all data is protected by 64-bit checksums, consistency of data is maintained at all times
• eliminates the need for a volume manager, GUI automates administrator intent

ZFS achieves its impressive performance through a number of techniques:

• Dynamic striping across all devices to maximize throughput
• Copy-on-write design makes most disk writes sequential
• Multiple block sizes, automatically chosen to match workload
• Explicit I/O priority with deadline scheduling
• Globally optimal I/O sorting and aggregation
• Multiple independent prefetch streams with automatic length and stride detection
• Unlimited, instantaneous read/write snapshots
• Parallel, constant-time directory operations

... akorat ze v unixu neni tak bezne, ze kdyz se disk premisti, ze si jej OS najde, v linuxu je to normalni a UNIX zvrhlosti s nenabehnutim systemu a pres STRING zistovat obsah volum grupy, export, import...

Není pravda co píšete.
V Solarisu lze pro LVM využít Solaris Volume Management (SVM) nebo Veritas Volume Manager. Veritas značkuje disk a mění rozložení disků, SVM to nedělá. S Veritasem lze premísťovat disk, disk je označkovany a pokud má systém s LVM databázi rozložení, pozná i značky - identifikuje disk. SVM tento systém nepoužívá. Ovšem u SVM to má tu obrovskou výhodu, že je bez problémů čitelný souborový systém bez nutnosti volume manageru. Takže migrace mezi LVM a bez LVM je triviální. Což se velmi často hodí.

...hledani v bordelu ala "/dev/rdev/sdkhnfgb3u8y583"...

/dev/dsk/c2t1d0s0 jednoznačně identifikuje diskovou oblast v systému. Linuxová identifikace /dev/hdX /dev/sdX je moc pěkná věc do několika zařízení, ale v případě několika desítek nebo dokonce i stovek zařízení přes různé řadiče je nevhodná.
Při identifikaci diskové oblasti v Solarisu (v HP-UXu je podobný systém) je jednoznačně dáno, kde se disková oblast nachází, v jakém diskovém poli, na jakém disku v něm, přes jaký řadič a port je toto diskové pole přípojeno.

[michich]

Linuxová identifikace /dev/hdX /dev/sdX je moc pěkná věc do několika zařízení, ale v případě několika desítek nebo dokonce i stovek zařízení přes různé řadiče je nevhodná.
Při identifikaci diskové oblasti v Solarisu (v HP-UXu je podobný systém) je jednoznačně dáno, kde se disková oblast nachází, v jakém diskovém poli, na jakém disku v něm, přes jaký řadič a port je toto diskové pole přípojeno.

Používáte-li v Linuxu udev, viz /dev/disk/by-{path,id,uuid,label}/...

[..... Izak .....]

No, ja spise pouzivam .rules, pro vytvareni specifickych nazvy, na FC poli staci pojmenovat dany RAID/stripe a pres /sys lze zjistit pod jakou promenou ten nazev ma.

Jinak u Unixu je nejvetsi sranda FC, protoze oni pouzivaji celou FC adresu a prehozeni kabliku v portu dela obrovskou neplechu a boot do single modu a oprava je konkreten u Veritasu velmi znama, HP-UX dokonce nelze ani vypnout a musi se zhodit natvrdo, nebo vratit kabel pole.

[Lukáš Cirkva]

Běžně v Solarisu přídávám zařízení, přesunuji FC karty, přípojuji na jiné porty apod. Když je třeba tak i bez rebootu. Žádný problém s tím není, samozřejmě je třeba mít podporovaný HW, dobře nainstalovaný SW a trochu tomu rozumět.

Pokud máte nějaké problémy, nebojte se mne kontaktovat, rád pomohu.

[Tomas Dzik]

Dovolim si vas opravit.

1) Resynchronizovat disk takovym zpusobem, ze se kopiruji pouze zmenene bloky umi i Veritas. Staci mit zapnute DRL (dirty region log) ve kterem je ulozena bitmapa zmenenych regionu. To by nebylo nic noveho, ani prevratneho.

2) Nutnost fsck u ext3 je dana tim, ze ext3 pouziva zurnal. A v pripade, ze dojde k vypadku napajeni, padu apod. se musi zurnal projit a aplikovat. Pokud je nutne na ext3 aplikovat uplne (ext2) fsck - coz se podle mych zkusenosti opravdu obcas musi - je to bug, ktery by mel byt opraven.

ZFS ale zurnal nepouziva. V ZFS je soubor reprezentovan jako strom bloku. Navic neni checksum bloku ulozen primo ve stejnem bloku, ale v bloku nadrazenem. Timto zpusobem se eliminuje spousta obvyklych chyb disku, radicu a driveru, kdy je checksum bloku spravne, ale precte se treba jiny blok. No a pri zmene bloku se nejprve zapisou zmenene bloky na disk a potom se teprve atomicky zmeni ukazatel na prislusny podstrom. Takze v pripade vypadku napajeni (nebo cehokoliv jineho) vidi uzivatel budto data pred zmenou, nebo po zmene, ale vzdycky jsou konzistentni.

Bohuzel jsem videl vnitrni strukturu ZFS jenom z rychliku, takze nevim uplne presne, jak se ty uzly ve stromu prepojuji, ale zhruba tohle by mel byt princip. (K dispozici jsou zdrojaky i nejaka dokumentace, takze by asi bylo mozne to nastudovat ) Jako nejvetsi uspech vidim to, ze se nekomu neco podobneho podarilo naimplementovat zpusobem, ktery je snesitelne rychly.

3) ZFS neni SW Raid, ZFS je filesystem, ktery v sobe implementuje redundanci. Hlavni rozdil je v tom, ze ZFS slucuje 2 vrstvy SW Raid + filesystem, protoze je vyhodnejsi, kdyz se filesystem muze prizpusobit typu diskoveho storage pod sebou, nez kdyz volume manager prezentuje RAID filesystemu jako jeden velky disk. Filesystem pak muze lepe optimalizovat.

[Pavel Janousek]

Asi jsem mel stesti, ale nutnost pouzit fsck nad ext3 po zruseni zurnalu mne za celou dobu co na vsech strojich pouzivam ext3 jaxi minula... Aplikace, resp. synchronizace obrazu disku a zurnalu OK, ale nic vice..

Atomicky muzeme menit cokoli, ale pouze v pameti, kdekoli jinde je to utopie a zalezi na spouste faktoru, ktere nemuze OS, natoz ovladac FS/VFS naprosto ovlivnit - marketingovych reci bych prosil byti usetren...

[Tomas Dzik]

Mate pravdu. Podival jsem se podrobneji, jak vlastne ZFS zajistuje atomicitu. Jde o to, ze zfs uklada data do listu stromu, metadata jsou pak ulozena ve vnitrnich uzlech (a vnitrni uzly s metadaty se nachazeji na disku vicekrat). V pripade update dat se nejprve zapisi na disk zmenena data a potom i zmenene vnitrni uzly stromu (ty puvodni bloky tam stale zustavaji). Jedinou kritickou operaci je potom update korene stromu (v ZFS se mu rika uberblock a mela by to byt alternativa superbloku). Tam je atomicita resena tak, ze na disku existuje 128 instanci uberblocku (kazdy ma tusim 1kB) a uberblock v sobe obsahuje cislo transakce (v podstate counter) a 256 bitovy hash. Jako aktivni se pak definuje uberblock s nejvyssim cislem transakce a platnym checksumem (hashem). Takze pokud se uberblock zapise spravne, je automaticky povazovan za aktivni, pokud ne, pouzije se predchozi korektni uberblock. Tech 128 uberblocku se pak zapisuje porad dokola (round robin).

Tedy jedine, co ZFS od hardware vyzaduje, je to, aby po navratu DKIOCFLUSHWRITECACHE ioctl byla data opravdu na disku a uberblock se mohl updatovat. (Vim, ze linux a ext3 meli v minulosti problemy s disky, ktere o sobe prohlasily ze zapsaly cache na plotny, ackoliv tomu tak nebylo.)

Ale jak jsem uz rikal vyse, nejsem odbornikem na ZFS (a ve spouste veci ohledne ZFS mam nejasnosti), takze doporucuji podivat se na http://www.opensolaris.org/os/community/zfs/docs/ + zdrojove kody.

[k3]

http://code.google.com/soc/opsol/appinfo.html?csaid=1EEF6B271FE5408B