{"id":83582,"date":"2020-06-01T19:42:21","date_gmt":"2020-06-01T17:42:21","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/osnovy-zfs-sistema-hraneniya-i-proizvoditelnost"},"modified":"2020-06-01T19:42:21","modified_gmt":"2020-06-01T17:42:21","slug":"osnovy-zfs-sistema-hraneniya-i-proizvoditelnost","status":"publish","type":"post","link":"https:\/\/prohoster.info\/cs\/blog\/administrirovanie\/osnovy-zfs-sistema-hraneniya-i-proizvoditelnost","title":{"rendered":"Z\u00e1klady ZFS: \u00falo\u017ei\u0161t\u011b a v\u00fdkon","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Z\u00e1klady
\n
\nToto jaro jsme ji\u017e probrali n\u011bkter\u00e1 \u00favodn\u00ed t\u00e9mata, nap\u0159\u00edklad, jak zkontrolovat rychlost va\u0161ich disk\u016f<\/a><\/noindex> a co je to RAID<\/a><\/noindex>. V druh\u00e9m z nich jsme dokonce sl\u00edbili pokra\u010dovat ve zkoum\u00e1n\u00ed v\u00fdkonu r\u016fzn\u00fdch v\u00edcirdiskov\u00fdch topologi\u00ed v ZFS. To je souborov\u00fd syst\u00e9m nov\u00e9 generace, kter\u00fd se nyn\u00ed zav\u00e1d\u00ed v\u0161ude: od Apple<\/a><\/noindex> do Ubuntu<\/a><\/noindex>.
\n<\/a><\/noindex>
\nNo co, dnes je ten nejvhodn\u011bj\u0161\u00ed den pro sezn\u00e1men\u00ed s ZFS, zv\u00eddav\u00ed \u010dten\u00e1\u0159i. Jen v\u011bzte, \u017ee podle skromn\u00e9ho odhadu v\u00fdvoj\u00e1\u0159e OpenZFS Matta Arense, \"to je opravdu slo\u017eit\u00e9\".<\/p>\n

Ale ne\u017e se dostaneme k \u010d\u00edsl\u016fm \u2013 a ta p\u0159ijdou, slibuji \u2013 pro v\u0161echny varianty osmn\u00e1ctiskladov\u00e9 konfigurace ZFS, mus\u00edme si promluvit o tom, jak<\/i> jak ZFS obecn\u011b uchov\u00e1v\u00e1 data na disku.<\/p>\n

Zpool, vdev a device<\/h1>\n

\n\"Z\u00e1klady
\nTento diagram celkov\u00e9ho poolu zahrnuje t\u0159i pomocn\u00e9 vdevy, po jednom z ka\u017ed\u00e9 t\u0159\u00eddy, a \u010dty\u0159i pro RAIDz2.<\/i><\/p>\n

\"Z\u00e1klady
\nObvykle nen\u00ed d\u016fvod vytv\u00e1\u0159et pool z nesourod\u00fdch typ\u016f a velikost\u00ed vdevu \u2013 ale pokud chcete, nic v\u00e1m v tom nebr\u00e1n\u00ed<\/i><\/p>\n

Abychom skute\u010dn\u011b porozum\u011bli souborov\u00e9mu syst\u00e9mu ZFS, mus\u00edme se pod\u00edvat na jeho skute\u010dnou strukturu. Za prv\u00e9, ZFS kombinuje tradi\u010dn\u00ed \u00farovn\u011b spr\u00e1vy svazk\u016f a souborov\u00e9ho syst\u00e9mu. Za druh\u00e9, pou\u017e\u00edv\u00e1 transak\u010dn\u00ed mechanismus kop\u00edrov\u00e1n\u00ed p\u0159i z\u00e1pisu. Tyto rysy znamenaj\u00ed, \u017ee syst\u00e9m je struktur\u00e1ln\u011b velmi odli\u0161n\u00fd od b\u011b\u017en\u00fdch souborov\u00fdch syst\u00e9m\u016f a RAID pol\u00ed. Prvn\u00ed sada z\u00e1kladn\u00edch stavebn\u00edch blok\u016f pro pochopen\u00ed: to je pool \u00falo\u017ei\u0161t\u011b (zpool), virtu\u00e1ln\u00ed za\u0159\u00edzen\u00ed (vdev) a skute\u010dn\u00e9 za\u0159\u00edzen\u00ed (device).<\/p>\n

zpool<\/h3>\n

\nPool \u00falo\u017ei\u0161t\u011b zpool \u2013 nejvy\u0161\u0161\u00ed struktura ZFS. Ka\u017ed\u00fd pool obsahuje jedno nebo v\u00edce virtu\u00e1ln\u00edch za\u0159\u00edzen\u00ed. Ka\u017ed\u00e9 z nich zase obsahuje jedno nebo v\u00edce skute\u010dn\u00fdch za\u0159\u00edzen\u00ed (device). Virtu\u00e1ln\u00ed pooly jsou samostatn\u00e9 bloky. Jeden fyzick\u00fd po\u010d\u00edta\u010d m\u016f\u017ee obsahovat dva nebo v\u00edce samostatn\u00fdch pool\u016f, ale ka\u017ed\u00fd je zcela nez\u00e1visl\u00fd na ostatn\u00edch. Pooly nemohou spole\u010dn\u011b pou\u017e\u00edvat virtu\u00e1ln\u00ed za\u0159\u00edzen\u00ed.<\/p>\n

Redundance ZFS je na \u00farovni virtu\u00e1ln\u00edch za\u0159\u00edzen\u00ed, nikoli na \u00farovni pool\u016f. Na \u00farovni pool\u016f nen\u00ed \u017e\u00e1dn\u00e1 redundance \u2013 pokud jak\u00fdkoli disk vdev nebo speci\u00e1ln\u00ed vdev ztrat\u00edte, ztrat\u00edte i cel\u00fd pool.<\/p>\n

Modern\u00ed \u00falo\u017en\u00e9 pooly mohou p\u0159e\u017e\u00edt ztr\u00e1tu cache nebo \u017eurn\u00e1lu virtu\u00e1ln\u00edho za\u0159\u00edzen\u00ed \u2013 a\u010dkoli mohou ztratit mal\u00e9 mno\u017estv\u00ed za\u0161pin\u011bn\u00fdch dat, pokud b\u011bhem v\u00fdpadku energie nebo selh\u00e1n\u00ed syst\u00e9mu ztrat\u00ed \u017eurn\u00e1l vdev.<\/p>\n

Existuje roz\u0161\u00ed\u0159en\u00e9 myln\u00e9 p\u0159esv\u011bd\u010den\u00ed, \u017ee \u201edatov\u00e9 pruhy\u201c (stripe) ZFS jsou zapisov\u00e1ny p\u0159es cel\u00fd pool. To nen\u00ed pravda. Zpool rozhodn\u011b nen\u00ed z\u00e1bavn\u00fd RAID0, je to sp\u00ed\u0161e z\u00e1bavn\u00fd. JBOD<\/a><\/noindex> se slo\u017eit\u00fdm prom\u011bnliv\u00fdm mechanismem rozd\u011blen\u00ed.<\/p>\n

Ve v\u011bt\u0161in\u011b p\u0159\u00edpad\u016f jsou z\u00e1pisy rozlo\u017eeny mezi dostupn\u00e1 virtu\u00e1ln\u00ed za\u0159\u00edzen\u00ed podle voln\u00e9ho prostoru, tak\u017ee teoreticky budou v\u0161echna napln\u011bna sou\u010dasn\u011b. V nov\u011bj\u0161\u00edch verz\u00edch ZFS se bere v \u00favahu aktu\u00e1ln\u00ed vyu\u017eit\u00ed (utilizaci) vdev \u2013 pokud je jedno virtu\u00e1ln\u00ed za\u0159\u00edzen\u00ed v\u00fdrazn\u011b zat\u00ed\u017eeno v\u00edce ne\u017e jin\u00e9 (nap\u0159\u00edklad kv\u016fli z\u00e1t\u011b\u017ei na \u010dten\u00ed), bude do\u010dasn\u011b vynech\u00e1no pro z\u00e1pis, navzdory tomu, \u017ee m\u00e1 nejvy\u0161\u0161\u00ed pom\u011br voln\u00e9ho prostoru.<\/p>\n

Mechanismus pro ur\u010den\u00ed vyu\u017eit\u00ed, zabudovan\u00fd v modern\u00edch metod\u00e1ch rozd\u011blen\u00ed z\u00e1pisu ZFS, m\u016f\u017ee sn\u00ed\u017eit latenci a zv\u00fd\u0161it propustnost v obdob\u00edch neobvykle vysok\u00e9ho zat\u00ed\u017een\u00ed \u2013 ale to nen\u00ed blanket<\/i> na ne\u00famysln\u00e9 sm\u00ed\u0161en\u00ed pomal\u00fdch HDD a rychl\u00fdch SSD v jednom poolu. Takov\u00fd nevyv\u00e1\u017een\u00fd pool bude st\u00e1le fungovat rychlost\u00ed nejpomalej\u0161\u00edho za\u0159\u00edzen\u00ed, tedy jako by byl zcela slo\u017een z takov\u00fdch za\u0159\u00edzen\u00ed.<\/p>\n

vdev<\/h3>\n

\nKa\u017ed\u00fd \u00falo\u017en\u00fd pool se skl\u00e1d\u00e1 z jednoho nebo v\u00edce virtu\u00e1ln\u00edch za\u0159\u00edzen\u00ed (virtual device, vdev). Ka\u017ed\u00e9 vdev zase zahrnuje jedno nebo v\u00edce skute\u010dn\u00fdch za\u0159\u00edzen\u00ed. V\u011bt\u0161ina virtu\u00e1ln\u00edch za\u0159\u00edzen\u00ed se pou\u017e\u00edv\u00e1 pro jednoduch\u00e9 ukl\u00e1d\u00e1n\u00ed dat, ale existuje n\u011bkolik pomocn\u00fdch t\u0159\u00edd vdev, v\u010detn\u011b CACHE, LOG a SPECIAL. Ka\u017ed\u00fd z t\u011bchto typ\u016f vdev m\u016f\u017ee m\u00edt jednu z p\u011bti topologi\u00ed: jedin\u00e9 za\u0159\u00edzen\u00ed (single-device), RAIDz1, RAIDz2, RAIDz3 nebo zrcadlo (mirror).<\/p>\n

RAIDz1, RAIDz2 a RAIDz3 jsou speci\u00e1ln\u00ed varianty toho, co by star\u0161\u00ed generace nazvala RAID s dvojitou (diagon\u00e1ln\u00ed) paritou. \u010c\u00edsla 1, 2 a 3 ozna\u010duj\u00ed kolik blok\u016f parity je vyhrazeno pro ka\u017ed\u00fd datov\u00fd pruh. M\u00edsto jednotliv\u00fdch disk\u016f pro zabezpe\u010den\u00ed parity virtu\u00e1ln\u00ed za\u0159\u00edzen\u00ed RAIDz rozd\u011bluj\u00ed tuto paritu rovnom\u011brn\u011b mezi disky. Pole RAIDz m\u016f\u017ee ztratit tolik disk\u016f, kolik m\u00e1 blok\u016f parity; pokud ztrat\u00ed dal\u0161\u00ed, je mimo provoz a vezme s sebou \u00falo\u017ei\u0161t\u011b.<\/p>\n

V zrcadlov\u00fdch virtu\u00e1ln\u00edch za\u0159\u00edzen\u00edch (mirror vdev) je ka\u017ed\u00fd blok ulo\u017een na ka\u017ed\u00e9m za\u0159\u00edzen\u00ed ve vdev. A\u010dkoliv jsou nejb\u011b\u017en\u011bj\u0161\u00ed dvojit\u00e9 zrcadla (two-wide), v zrcadle m\u016f\u017ee b\u00fdt libovoln\u00fd po\u010det za\u0159\u00edzen\u00ed \u2014 ve velk\u00fdch instalac\u00edch se \u010dasto pou\u017e\u00edvaj\u00ed trojit\u00e9 pro zv\u00fd\u0161en\u00ed v\u00fdkonnosti \u010dten\u00ed a odolnosti proti chyb\u00e1m. Zrcadlo vdev m\u016f\u017ee p\u0159e\u017e\u00edt jak\u00e9koli selh\u00e1n\u00ed, pokud alespo\u0148 jedno za\u0159\u00edzen\u00ed ve vdev st\u00e1le funguje.<\/p>\n

Jednotliv\u00e9 vdev jsou v podstat\u011b nebezpe\u010dn\u00e9. Takov\u00e9 virtu\u00e1ln\u00ed za\u0159\u00edzen\u00ed nep\u0159e\u017eije \u017e\u00e1dn\u00e9 selh\u00e1n\u00ed \u2014 a pokud se pou\u017e\u00edv\u00e1 jako \u00falo\u017ei\u0161t\u011b nebo speci\u00e1ln\u00ed vdev, jeho selh\u00e1n\u00ed povede k zni\u010den\u00ed cel\u00e9ho \u00falo\u017ei\u0161t\u011b. Bu\u010fte zde velmi, velmi opatrn\u00ed.<\/p>\n

Virtu\u00e1ln\u00ed za\u0159\u00edzen\u00ed CACHE, LOG a SPECIAL mohou b\u00fdt vytvo\u0159ena podle jak\u00e9koli z v\u00fd\u0161e uveden\u00fdch topologi\u00ed \u2014 ale pamatujte, \u017ee ztr\u00e1ta virtu\u00e1ln\u00edho za\u0159\u00edzen\u00ed SPECIAL znamen\u00e1 ztr\u00e1tu \u00falo\u017ei\u0161t\u011b, proto se d\u016frazn\u011b doporu\u010duje redundantn\u00ed topologie.<\/p>\n

za\u0159\u00edzen\u00ed<\/h3>\n

\nTo je pravd\u011bpodobn\u011b nejjednodu\u0161\u0161\u00ed pojem v ZFS \u2014 doslovn\u011b to znamen\u00e1 blokov\u00e9 za\u0159\u00edzen\u00ed s n\u00e1hodn\u00fdm p\u0159\u00edstupem. Pamatujte, \u017ee virtu\u00e1ln\u00ed za\u0159\u00edzen\u00ed se skl\u00e1daj\u00ed z jednotliv\u00fdch za\u0159\u00edzen\u00ed a \u00falo\u017ei\u0161t\u011b je vytvo\u0159eno z virtu\u00e1ln\u00edch za\u0159\u00edzen\u00ed.<\/p>\n

Disky \u2014 magnetick\u00e9 nebo SSD \u2014 jsou nejb\u011b\u017en\u011bj\u0161\u00ed blokov\u00e1 za\u0159\u00edzen\u00ed, kter\u00e1 se pou\u017e\u00edvaj\u00ed jako stavebn\u00ed bloky vdev. Jak\u00e9koli za\u0159\u00edzen\u00ed s popisem v \/dev je v\u0161ak tak\u00e9 vhodn\u00e9 \u2014 tak\u017ee jako jednotliv\u00e1 za\u0159\u00edzen\u00ed mohou b\u00fdt pou\u017eity cel\u00e9 hardwarov\u00e9 RAID pole.<\/p>\n

Jednoduch\u00fd raw soubor je jedn\u00edm z nejd\u016fle\u017eit\u011bj\u0161\u00edch alternativn\u00edch blokov\u00fdch za\u0159\u00edzen\u00ed, ze kter\u00fdch m\u016f\u017ee b\u00fdt postaven vdev. Testovac\u00ed pole z tenk\u00fdch soubor\u016f<\/a><\/noindex>\u00a0je velmi pohodln\u00fd zp\u016fsob, jak testovat p\u0159\u00edkazy \u00falo\u017ei\u0161t\u011b a sledovat, kolik m\u00edsta je k dispozici v \u00falo\u017ei\u0161ti nebo virtu\u00e1ln\u00edm za\u0159\u00edzen\u00ed dan\u00e9 topologie.<\/p>\n

\"Z\u00e1klady
\nM\u016f\u017eete vytvo\u0159it zku\u0161ebn\u00ed pool se sparsen\u00fdmi soubory b\u011bhem n\u011bkolika sekund \u2014 ale nezapome\u0148te pot\u00e9 cel\u00fd pool a jeho komponenty odstranit.<\/i> <\/p>\n

P\u0159edstavte si, \u017ee chcete nasadit server na osm disk\u016f a pl\u00e1nujete pou\u017e\u00edt disky o velikosti 10 TB (~9300 GiB) \u2014 ale nejste si jisti, kter\u00e1 topologie nejl\u00e9pe vyhovuje va\u0161im pot\u0159eb\u00e1m. V uveden\u00e9m p\u0159\u00edkladu rychle stav\u00edme zku\u0161ebn\u00ed pool ze sparsen\u00fdch soubor\u016f \u2014 a nyn\u00ed v\u00edme, \u017ee RAIDz2 vdev ze \u0161esti disk\u016f o 10 TB poskytuje 50 TiB vyu\u017eiteln\u00e9 kapacity.<\/p>\n

Dal\u0161\u00ed zvl\u00e1\u0161tn\u00ed t\u0159\u00edda za\u0159\u00edzen\u00ed je SPARE (n\u00e1hradn\u00ed). Hot-swap za\u0159\u00edzen\u00ed se na rozd\u00edl od b\u011b\u017en\u00fdch za\u0159\u00edzen\u00ed p\u0159ipojuj\u00ed k cel\u00e9mu poolu, nikoli k jednomu virtu\u00e1ln\u00edmu za\u0159\u00edzen\u00ed. Pokud n\u011bjak\u00fd vdev v poolu sel\u017ee a n\u00e1hradn\u00ed za\u0159\u00edzen\u00ed je p\u0159ipojeno k poolu a k dispozici, p\u0159ipoj\u00ed se automaticky k posti\u017een\u00e9mu vdev.<\/p>\n

Jakmile se n\u00e1hradn\u00ed za\u0159\u00edzen\u00ed p\u0159ipoj\u00ed k posti\u017een\u00e9mu vdev, za\u010dne p\u0159ij\u00edmat kopie nebo rekonstrukce dat, kter\u00e9 by m\u011bly b\u00fdt na chyb\u011bj\u00edc\u00edm za\u0159\u00edzen\u00ed. V tradi\u010dn\u00edm RAID se tomu \u0159\u00edk\u00e1 obnoven\u00ed (rebuilding), a v ZFS se to naz\u00fdv\u00e1 \"obnova redundantnosti\" (resilvering).<\/p>\n

Je d\u016fle\u017eit\u00e9 poznamenat, \u017ee n\u00e1hradn\u00ed za\u0159\u00edzen\u00ed nenahrazuj\u00ed trvale selh\u00e1van\u00e1 za\u0159\u00edzen\u00ed. Jsou to pouze do\u010dasn\u00e9 n\u00e1hrady pro zkr\u00e1cen\u00ed doby, po kterou je pozorov\u00e1na degradace vdevu. Jakmile spr\u00e1vce nahrad\u00ed selhan\u00e9 za\u0159\u00edzen\u00ed vdevu, dojde k obnoven\u00ed redundantnosti na tomto trval\u00e9m za\u0159\u00edzen\u00ed a SPARE se odpoj\u00ed od vdevu a vrac\u00ed se k pr\u00e1ci jako n\u00e1hradn\u00ed na cel\u00fd pool.<\/p>\n

Sady dat, bloky a sektory<\/h1>\n

\nDal\u0161\u00ed sada stavebn\u00edch blok\u016f, kter\u00e9 je t\u0159eba pochopit b\u011bhem na\u0161\u00ed cesty po ZFS, se t\u00fdk\u00e1 sp\u00ed\u0161e toho, jak jsou organizov\u00e1na a uchov\u00e1v\u00e1na samotn\u00e1 data, ne\u017e hardwaru. P\u0159eskakujeme zde n\u011bkolik \u00farovn\u00ed \u2014 jako nap\u0159\u00edklad metaslab \u2014 abychom nezaplnili detaily, p\u0159i\u010dem\u017e zachov\u00e1v\u00e1me porozum\u011bn\u00ed celkov\u00e9 struktu\u0159e.<\/p>\n

Sada dat (dataset)<\/h3>\n

\n\"Z\u00e1klady
\nKdy\u017e poprv\u00e9 vytvo\u0159\u00edme sadu dat, uk\u00e1\u017ee ve\u0161ker\u00fd dostupn\u00fd prostor poolu. Pak nastav\u00edme kv\u00f3tu \u2014 a zm\u011bn\u00edme mont\u00e1\u017en\u00ed bod. Kouzlo!<\/i> <\/p>\n

\"Z\u00e1klady
\nZvol je v\u011bt\u0161inou pouze sada dat, kter\u00e1 nem\u00e1 sv\u016fj vrstvu souborov\u00e9ho syst\u00e9mu, kterou zde nahrazujeme zcela norm\u00e1ln\u00edm souborov\u00fdm syst\u00e9mem ext4.<\/i> <\/p>\n

Sada dat ZFS je p\u0159ibli\u017en\u011b toto\u017en\u00e1 s b\u011b\u017en\u00fdm namontovan\u00fdm souborov\u00fdm syst\u00e9mem. Na prvn\u00ed pohled se jev\u00ed jako \u201eprost\u011b dal\u0161\u00ed slo\u017eka\u201c. Ale stejn\u011b jako u b\u011b\u017en\u00fdch montovan\u00fdch souborov\u00fdch syst\u00e9m\u016f m\u00e1 ka\u017ed\u00fd dataset ZFS svou vlastn\u00ed sadu z\u00e1kladn\u00edch vlastnost\u00ed.<\/p>\n

Nejd\u016fle\u017eit\u011bj\u0161\u00ed je, \u017ee dataset m\u016f\u017ee m\u00edt p\u0159id\u011blenou kv\u00f3tu. Pokud nastav\u00edte zfs set quota=100G poolname\/datasetname<\/code>, nebudete moci zapsat do namontovan\u00e9 slo\u017eky \/poolname\/datasetname<\/code> v\u00edce ne\u017e 100 GiB.<\/p>\n

V\u0161imli jste si p\u0159\u00edtomnosti \u2013 a absence \u2013 lom\u00edtek na za\u010d\u00e1tku ka\u017ed\u00e9ho \u0159\u00e1dku? Ka\u017ed\u00fd dataset m\u00e1 sv\u00e9 m\u00edsto jak v hierarchii ZFS, tak v hierarchii syst\u00e9mov\u00e9ho montov\u00e1n\u00ed. V hierarchii ZFS nen\u00ed \u00favodn\u00ed lom\u00edtko \u2013 za\u010d\u00edn\u00e1te n\u00e1zvem poolu a pot\u00e9 postupujete cestou od jednoho datasetu k dal\u0161\u00edmu. Nap\u0159\u00edklad, pool\/parent\/child<\/code> pro dataset s n\u00e1zvem child<\/code> pod rodi\u010dovsk\u00fdm datov\u00fdm souborem parent<\/code> v poolu s kreativn\u00edm n\u00e1zvem pool<\/code>.<\/p>\n

Ve v\u00fdchoz\u00edm nastaven\u00ed bude bod p\u0159ipojen\u00ed datasetu odpov\u00eddat jeho n\u00e1zvu v hierarchii ZFS, s lom\u00edtkem na za\u010d\u00e1tku \u2013 pool s n\u00e1zvem pool<\/code> bude p\u0159ipojen jako \/pool<\/code>, dataset parent<\/code> je p\u0159ipojen v \/pool\/parent<\/code>, a pod\u0159\u00edzen\u00fd dataset child<\/code> je p\u0159ipojen v \/pool\/parent\/child<\/code>. M\u016f\u017eete v\u0161ak zm\u011bnit syst\u00e9mov\u00fd bod p\u0159ipojen\u00ed datasetu.<\/p>\n

Pokud uvedeme zfs set mountpoint=\/lol pool\/parent\/child<\/code>, dataset pool\/parent\/child<\/code> bude p\u0159ipojen v syst\u00e9mu jako \/lol<\/code>.<\/p>\n

Krom\u011b dataset\u016f mus\u00edme zm\u00ednit tak\u00e9 svazky (zvols). Svazek je p\u0159ibli\u017en\u011b podobn\u00fd datasetu, s t\u00edm rozd\u00edlem, \u017ee v n\u011bm vlastn\u011b neexistuje souborov\u00fd syst\u00e9m \u2013 je to prost\u011b blokov\u00e9 za\u0159\u00edzen\u00ed. Nap\u0159\u00edklad m\u016f\u017eete vytvo\u0159it zvol<\/code> s n\u00e1zvem mypool\/myzvol<\/code>, pot\u00e9 ho naform\u00e1tovat se souborov\u00fdm syst\u00e9mem ext4 a pak tento souborov\u00fd syst\u00e9m p\u0159ipojit \u2013 nyn\u00ed m\u00e1te souborov\u00fd syst\u00e9m ext4, ale se v\u0161emi funkcemi zabezpe\u010den\u00ed ZFS! To se m\u016f\u017ee zd\u00e1t hloup\u00e9 na jednom po\u010d\u00edta\u010di, ale m\u00e1 to mnohem v\u011bt\u0161\u00ed smysl jako backend p\u0159i exportu iSCSI za\u0159\u00edzen\u00ed.<\/p>\n

Bloky<\/h3>\n

\n\"Z\u00e1klady
\nSoubor je reprezentov\u00e1n jedn\u00edm nebo v\u00edce bloky. Ka\u017ed\u00fd blok je ulo\u017een na jednom virtu\u00e1ln\u00edm za\u0159\u00edzen\u00ed. Velikost bloku je obvykle rovna parametru recordsize<\/b>, ale m\u016f\u017ee b\u00fdt sn\u00ed\u017eena na 2^ashift<\/b>, pokud obsahuje metadata nebo mal\u00fd soubor.<\/i><\/p>\n

\"Z\u00e1klady
\nOpravdu, opravdu<\/b> si s ohromnou ztr\u00e1tou v\u00fdkonu ned\u011bl\u00e1me legraci, pokud nastav\u00edte p\u0159\u00edli\u0161 mal\u00fd ashift.<\/i><\/p>\n

V ZFS poolu jsou v\u0161echna data, v\u010detn\u011b metadat, ulo\u017eena v bloc\u00edch. Maxim\u00e1ln\u00ed velikost bloku pro ka\u017edou datovou sadu je ur\u010dena v vlastnosti recordsize<\/code> (velikost z\u00e1znamu). Velikost z\u00e1znamu lze m\u011bnit, ale toto nezm\u011bn\u00ed velikost ani um\u00edst\u011bn\u00ed jak\u00fdchkoli blok\u016f, kter\u00e9 ji\u017e byly zaps\u00e1ny do datov\u00e9 sady \u2013 vztahuje se pouze na nov\u00e9 bloky p\u0159i jejich z\u00e1pisu.<\/p>\n

Pokud nen\u00ed stanoveno jinak, aktu\u00e1ln\u00ed velikost z\u00e1znamu je ve v\u00fdchoz\u00edm nastaven\u00ed nastavena na 128 KiB. Toto je jak\u00fdsi slo\u017eit\u00fd kompromis, kde v\u00fdkon nebude ide\u00e1ln\u00ed, ale ani hrozn\u00fd ve v\u011bt\u0161in\u011b p\u0159\u00edpad\u016f. Velikost z\u00e1znamu<\/code> m\u016f\u017ee b\u00fdt nastavena na jakoukoli hodnotu od 4K do 1M (s dodate\u010dn\u00fdmi nastaven\u00edmi recordsize<\/code> m\u016f\u017ee b\u00fdt nastavena je\u0161t\u011b v\u011bt\u0161\u00ed, ale to b\u00fdv\u00e1 vz\u00e1cn\u011b dobr\u00fd n\u00e1pad).<\/p>\n

Ka\u017ed\u00fd blok odkazuje na data pouze jednoho souboru \u2013 nem\u016f\u017eete vm\u011bstnat dva r\u016fzn\u00e9 soubory do jednoho bloku. Ka\u017ed\u00fd soubor se skl\u00e1d\u00e1 z jednoho nebo v\u00edce blok\u016f, v z\u00e1vislosti na velikosti. Pokud je velikost souboru men\u0161\u00ed ne\u017e velikost z\u00e1znamu, bude ulo\u017een v bloku men\u0161\u00ed velikosti \u2013 nap\u0159\u00edklad blok se souborem 2 KiB zabere pouze jeden sektor 4 KiB na disku.<\/p>\n

Objemy zvolu nemaj\u00ed vlastnost recordsize<\/code>\u00a0\u2013 m\u00edsto toho maj\u00ed ekvivalentn\u00ed vlastnost velikost bloku objemu<\/code>.<\/p>\n

Sektory<\/h3>\n

\nPosledn\u00ed, nejz\u00e1kladn\u011bj\u0161\u00ed stavebn\u00ed blok \u2013 sektor. To je nejmen\u0161\u00ed fyzick\u00e1 jednotka, kter\u00e1 m\u016f\u017ee b\u00fdt zaps\u00e1na nebo p\u0159e\u010dtena z z\u00e1kladn\u00edho za\u0159\u00edzen\u00ed. B\u011bhem n\u011bkolika desetilet\u00ed byly ve v\u011bt\u0161in\u011b disk\u016f pou\u017e\u00edv\u00e1ny sektory o velikosti 512 byt\u016f. V posledn\u00ed dob\u011b v\u011bt\u0161ina disk\u016f podporuje sektory 4 KiB, a na n\u011bkter\u00fdch, zejm\u00e9na SSD, sektory 8 KiB nebo dokonce v\u00edce.<\/p>\n

V syst\u00e9mu ZFS existuje vlastnost, kter\u00e1 umo\u017e\u0148uje ru\u010dn\u011b nastavit velikost sektoru. Tato vlastnost ashift<\/code>. Je pon\u011bkud matouc\u00ed, \u017ee ashift je mocninou dvojky. Nap\u0159\u00edklad, ashift=9<\/code> znamen\u00e1 velikost sektoru 2^9, nebo 512 byt\u016f.<\/p>\n

ZFS dotazuje opera\u010dn\u00ed syst\u00e9m na podrobn\u00e9 informace o ka\u017ed\u00e9m blokov\u00e9m za\u0159\u00edzen\u00ed p\u0159i p\u0159id\u00e1n\u00ed do nov\u00e9ho vdev a teoreticky automaticky nastavuje ashift spr\u00e1vn\u011b na z\u00e1klad\u011b t\u011bchto informac\u00ed. Bohu\u017eel, mnoho disk\u016f lh\u00e1t o sv\u00e9 velikosti sektoru, aby zachovalo kompatibilitu s Windows XP (kter\u00e9 nebyly schopny rozpoznat disky s jin\u00fdmi velikostmi sektor\u016f).<\/p>\n

To znamen\u00e1, \u017ee administr\u00e1tor ZFS by m\u011bl b\u00fdt d\u016fkladn\u011b obezn\u00e1men s skute\u010dnou velikost\u00ed sektoru sv\u00fdch za\u0159\u00edzen\u00ed a manu\u00e1ln\u011b nastavit ashift<\/code>. Pokud je nastaven p\u0159\u00edli\u0161 mal\u00fd ashift, astronomicky se zvy\u0161uje po\u010det operac\u00ed \u010dten\u00ed\/z\u00e1pisu. Tak z\u00e1pis 512-bytov\u00fdch \u201esektor\u016f\u201c do skute\u010dn\u00e9ho sektoru 4 KiB znamen\u00e1, \u017ee je t\u0159eba nejprve zapsat prvn\u00ed \u201esektor\u201c, pak p\u0159e\u010d\u00edst sektor 4 KiB, zm\u011bnit ho druh\u00fdm 512-bytov\u00fdm \u201esekretorem\u201c, zapsat ho zp\u011bt do nov\u00e9ho 4 KiB sektoru a tak d\u00e1le pro ka\u017ed\u00fd z\u00e1pis.<\/p>\n

Ve skute\u010dn\u00e9m sv\u011bt\u011b takov\u00fd trest dopad\u00e1 na SSD disky Samsung EVO, pro kter\u00e9 by se m\u011bl \u0159\u00eddit ashift=13<\/code>, ale tyto SSD l\u017eou o sv\u00e9 velikosti sektoru a proto je implicitn\u011b nastavena ashift=9<\/code>. Pokud zku\u0161en\u00fd syst\u00e9mov\u00fd administr\u00e1tor tento parametr nezm\u011bn\u00ed, tento SSD pracuje pomaleji<\/i> obvykl\u00e9ho magnetick\u00e9ho HDD.<\/p>\n

Na srovn\u00e1n\u00ed, za p\u0159\u00edli\u0161 velkou velikost ashift<\/code> skoro \u017e\u00e1dn\u00fd trest nen\u00ed. Skute\u010dn\u00e9 sn\u00ed\u017een\u00ed v\u00fdkonu neexistuje a n\u00e1r\u016fst neu\u017eitkov\u00e9ho prostoru je zanedbateln\u00fd (nebo nulov\u00fd p\u0159i zapnut\u00e9m kompresi). Proto d\u016frazn\u011b doporu\u010dujeme dokonce i t\u011bm disk\u016fm, kter\u00e9 skute\u010dn\u011b vyu\u017e\u00edvaj\u00ed 512-bytov\u00e9 sektory, nastavit ashift=12<\/code> nebo dokonce ashift=13<\/code>, abyste si mohli s ur\u010ditost\u00ed vysta\u010dit do budoucnosti.<\/p>\n

Vlastnost ashift<\/code> se nastavuje pro ka\u017ed\u00e9 virtu\u00e1ln\u00ed za\u0159\u00edzen\u00ed vdev, a ne pro pool<\/i>, jak si mnoho lid\u00ed myln\u011b mysl\u00ed \u2013 a nezm\u011bn\u00ed se po nastaven\u00ed. Pokud omylem nastav\u00edte ashift<\/code> p\u0159i p\u0159id\u00e1n\u00ed nov\u00e9ho vdev do poolu, pak jste nevratn\u011b zne\u010distili tento pool za\u0159\u00edzen\u00edm s n\u00edzk\u00fdm v\u00fdkonem a obvykle neexistuje jin\u00e1 mo\u017enost, ne\u017e pool zni\u010dit a za\u010d\u00edt znovu. Dokonce ani odstran\u011bn\u00ed vdev v\u00e1s nezachr\u00e1n\u00ed od \u0161patn\u00e9ho nastaven\u00ed. ashift<\/code>!<\/p>\n

Mechanismus kop\u00edrov\u00e1n\u00ed p\u0159i z\u00e1pisu<\/h3>\n

\n\"Z\u00e1klady
\nPokud b\u011b\u017en\u00e9mu souborov\u00e9mu syst\u00e9mu pot\u0159ebuje p\u0159epsat data \u2013 m\u011bn\u00ed ka\u017ed\u00fd blok tam, kde se nach\u00e1z\u00ed.<\/i><\/p>\n

\"Z\u00e1klady
\nSouborov\u00fd syst\u00e9m s kop\u00edrov\u00e1n\u00edm p\u0159i z\u00e1pisu ukl\u00e1d\u00e1 novou verzi bloku a pot\u00e9 uvol\u0148uje starou verzi.<\/i><\/p>\n

\"Z\u00e1klady
\nVe zjednodu\u0161en\u00e9 podob\u011b, pokud ignorujeme skute\u010dn\u00e9 fyzick\u00e9 um\u00edst\u011bn\u00ed blok\u016f, se na\u0161e 'datov\u00e1 kometa' zjednodu\u0161\u00ed na 'datov\u00e9ho \u010derva', kter\u00fd se pohybuje zleva doprava po map\u011b dostupn\u00e9ho prostoru.<\/i><\/p>\n

\"Z\u00e1klady
\nNyn\u00ed m\u00e1me dobrou p\u0159edstavu, jak funguj\u00ed sn\u00edmky kop\u00edrov\u00e1n\u00ed p\u0159i z\u00e1pisu \u2014 ka\u017ed\u00fd blok m\u016f\u017ee pat\u0159it n\u011bkolika sn\u00edmk\u016fm a p\u0159e\u017eije, dokud nebudou zni\u010deny v\u0161echny souvisej\u00edc\u00ed sn\u00edmky.<\/i><\/p>\n

Mechanismus kop\u00edrov\u00e1n\u00ed p\u0159i z\u00e1pisu (Copy on Write, CoW) je z\u00e1sadn\u00ed z\u00e1kladem toho, co d\u011bl\u00e1 ZFS tak \u00fa\u017easn\u00fdm syst\u00e9mem. Z\u00e1kladn\u00ed koncept je jednoduch\u00fd \u2014 pokud po\u017e\u00e1d\u00e1te tradi\u010dn\u00ed souborov\u00fd syst\u00e9m, aby zm\u011bnil soubor, ud\u011bl\u00e1 to, co jste \u017e\u00e1dali. Pokud po\u017e\u00e1d\u00e1te souborov\u00fd syst\u00e9m s kop\u00edrov\u00e1n\u00edm p\u0159i z\u00e1pisu, aby ud\u011blal tot\u00e9\u017e, \u0159ekne 'dob\u0159e' \u2014 ale l\u017ee v\u00e1m.<\/p>\n

M\u00edsto toho souborov\u00fd syst\u00e9m s kop\u00edrov\u00e1n\u00edm p\u0159i z\u00e1pisu ukl\u00e1d\u00e1 novou verzi zm\u011bn\u011bn\u00e9ho bloku a pot\u00e9 aktualizuje metadata souboru, aby p\u0159eru\u0161il vazbu se star\u00fdm blokem a spojil ho s nov\u00fdm blokem, kter\u00fd jste pr\u00e1v\u011b zapsali.<\/p>\n

Odpojen\u00ed star\u00e9ho bloku a spojen\u00ed nov\u00e9ho prob\u00edh\u00e1 v jedn\u00e9 operaci, tak\u017ee ji nelze p\u0159eru\u0161it \u2014 pokud vypnete nap\u00e1jen\u00ed pot\u00e9, co to prob\u011bhne, m\u00e1te novou verzi souboru, a pokud vypnete nap\u00e1jen\u00ed d\u0159\u00edv, m\u00e1te starou verzi. V ka\u017ed\u00e9m p\u0159\u00edpad\u011b se v souborov\u00e9m syst\u00e9mu nevyskytnou konflikty.<\/p>\n

Kop\u00edrov\u00e1n\u00ed p\u0159i z\u00e1pisu v ZFS prob\u00edh\u00e1 nejen na \u00farovni souborov\u00e9ho syst\u00e9mu, ale i na \u00farovni spr\u00e1vy disk\u016f. To znamen\u00e1, \u017ee ZFS nen\u00ed n\u00e1chyln\u00e1 k probl\u00e9mu se z\u00e1pisem (d\u00ed\u0159e v RAID<\/a><\/noindex>) \u2014 jevem, kdy se p\u00e1sma stihla pouze \u010d\u00e1ste\u010dn\u011b zapsat p\u0159ed selh\u00e1n\u00edm syst\u00e9mu, co\u017e zp\u016fsobilo po\u0161kozen\u00ed pole po restartu. Zde je p\u00e1smo zapisov\u00e1no atomicky, vdev je v\u017edy konzistentn\u00ed, a B\u016fh je tv\u016fj str\u00fdc.<\/a><\/noindex>.<\/p>\n

ZIL: den\u00edk z\u00e1m\u011br\u016f ZFS.<\/h3>\n

\n\"Z\u00e1klady
\nSyst\u00e9m ZFS zpracov\u00e1v\u00e1 synchronn\u00ed z\u00e1pisy zvl\u00e1\u0161tn\u00edm zp\u016fsobem \u2014 do\u010dasn\u011b, ale okam\u017eit\u011b je ukl\u00e1d\u00e1 do ZIL, ne\u017e je pozd\u011bji trvale zap\u00ed\u0161e spolu s asynchronn\u00edmi z\u00e1pisy.<\/i><\/p>\n

\"Z\u00e1klady
\nObvykle se data zapisovan\u00e1 na ZIL ji\u017e nikdy nep\u0159e\u010dtou. Ale je to mo\u017en\u00e9 po selh\u00e1n\u00ed syst\u00e9mu.<\/i><\/p>\n

\"Z\u00e1klady
\nSLOG, nebo sekund\u00e1rn\u00ed LOG za\u0159\u00edzen\u00ed, je prost\u011b speci\u00e1ln\u00ed \u2014 a ide\u00e1ln\u011b velmi rychl\u00fd \u2014 vdev, kde m\u016f\u017ee b\u00fdt ZIL uchov\u00e1v\u00e1n odd\u011blen\u011b od hlavn\u00edho \u00falo\u017ei\u0161t\u011b.<\/i><\/p>\n

\"Z\u00e1klady
\nPo hav\u00e1rii jsou v\u0161echny ne\u00fapln\u00e9 \u00fadaje v ZIL obnoveny \u2014 v tomto p\u0159\u00edpad\u011b je ZIL um\u00edst\u011bn na SLOG, tak\u017ee jsou obnoveny pr\u00e1v\u011b odtud.<\/i><\/p>\n

Existuj\u00ed dv\u011b z\u00e1kladn\u00ed kategorie operac\u00ed z\u00e1pisu \u2014 synchronn\u00ed (sync) a asynchronn\u00ed (async). Pro v\u011bt\u0161inu pracovn\u00edch z\u00e1t\u011b\u017e\u00ed je naprost\u00e1 v\u011bt\u0161ina operac\u00ed z\u00e1pisu asynchronn\u00ed \u2014 souborov\u00fd syst\u00e9m umo\u017e\u0148uje jejich agregaci a vyd\u00e1v\u00e1n\u00ed v bal\u00edc\u00edch, co\u017e sni\u017euje fragmentaci a v\u00fdznamn\u011b zvy\u0161uje propustnost.<\/p>\n

Synchronn\u00ed z\u00e1pisy jsou zcela jin\u00e1 v\u011bc. Kdy\u017e aplikace po\u017eaduje synchronn\u00ed z\u00e1pis, \u0159\u00edk\u00e1 souborov\u00e9mu syst\u00e9mu: \u201eMus\u00ed\u0161 to ulo\u017eit do trval\u00e9 pam\u011bti, hned te\u010f<\/i>, a do t\u00e9 doby nemohu d\u011blat nic jin\u00e9ho.\u201c Proto mus\u00ed b\u00fdt synchronn\u00ed z\u00e1pisy okam\u017eit\u011b ulo\u017eeny na disk \u2014 a pokud to zvy\u0161uje fragmentaci nebo sni\u017euje propustnost, tak tomu jednodu\u0161e je.<\/p>\n

ZFS zpracov\u00e1v\u00e1 synchronn\u00ed z\u00e1pisy jinak ne\u017e b\u011b\u017en\u00e9 souborov\u00e9 syst\u00e9my \u2014 m\u00edsto toho, aby je okam\u017eit\u011b nal\u00e9val do b\u011b\u017en\u00e9ho \u00falo\u017ei\u0161t\u011b, ZFS je ukl\u00e1d\u00e1 do speci\u00e1ln\u00ed oblasti \u00falo\u017ei\u0161t\u011b, kter\u00e1 se naz\u00fdv\u00e1 \u017eurn\u00e1l z\u00e1m\u011br\u016f ZFS \u2014 ZFS Intent Log, nebo ZIL. Finta je v tom, \u017ee tyto z\u00e1pisy tak\u00e9<\/i> z\u016fst\u00e1vaj\u00ed v pam\u011bti a jsou agregov\u00e1ny spolu s b\u011b\u017en\u00fdmi asynchronn\u00edmi z\u00e1pisy, aby byly pozd\u011bji vypr\u00e1zdn\u011bny do \u00falo\u017ei\u0161t\u011b jako zcela norm\u00e1ln\u00ed TXG (skupiny transakc\u00ed, Transaction Groups).<\/p>\n

V norm\u00e1ln\u00edm provozn\u00edm re\u017eimu se ZIL zapisuje a nikdy se znovu ne\u010dte. Kdy\u017e jsou za n\u011bkolik okam\u017eik\u016f z\u00e1pisy z ZIL ulo\u017eeny do hlavn\u00edho \u00falo\u017ei\u0161t\u011b v b\u011b\u017en\u00fdch TXG z opera\u010dn\u00ed pam\u011bti, jsou odpojeny od ZIL. Jedin\u00e9, kdy je n\u011bco \u010dteno z ZIL, je p\u0159i importu poolu.<\/p>\n

Pokud dojde k selh\u00e1n\u00ed ZFS \u2014 k selh\u00e1n\u00ed opera\u010dn\u00edho syst\u00e9mu nebo k v\u00fdpadku nap\u00e1jen\u00ed \u2014 kdy\u017e jsou v ZIL data, budou tato data p\u0159e\u010dtena p\u0159i dal\u0161\u00edm importu poolu (nap\u0159\u00edklad po restartov\u00e1n\u00ed havarijn\u00edho syst\u00e9mu). V\u0161echno, co se nach\u00e1z\u00ed v ZIL, bude p\u0159e\u010dteno, slou\u010deno do skupin TXG, ulo\u017eeno do hlavn\u00edho \u00falo\u017ei\u0161t\u011b a pot\u00e9 odpojeno od ZIL b\u011bhem importn\u00edho procesu.<\/p>\n

Jedna z pomocn\u00fdch t\u0159\u00edd vdev se naz\u00fdv\u00e1 LOG nebo SLOG, sekund\u00e1rn\u00ed za\u0159\u00edzen\u00ed LOG. Jeho \u00fakolem je poskytnout poolu samostatn\u00e9 a ide\u00e1ln\u011b mnohem rychlej\u0161\u00ed, s velmi vysokou odolnost\u00ed proti z\u00e1pisu, za\u0159\u00edzen\u00ed vdev pro uchov\u00e1v\u00e1n\u00ed ZIL, m\u00edsto uchov\u00e1v\u00e1n\u00ed ZIL na hlavn\u00edm \u00falo\u017ei\u0161ti vdev. Samotn\u00fd ZIL se chov\u00e1 stejn\u011b bez ohledu na m\u00edsto ukl\u00e1d\u00e1n\u00ed, ale pokud m\u00e1 vdev s LOG velmi vysok\u00fd v\u00fdkon z\u00e1pisu, budou synchronn\u00ed z\u00e1pisy prob\u00edhat rychleji.<\/p>\n

P\u0159id\u00e1n\u00ed vdev s LOG do poolu nijak nem\u016f\u017ee<\/b> zlep\u0161it v\u00fdkon asynchronn\u00edho z\u00e1pisu - i kdy\u017e v\u0161echny z\u00e1pisy do ZIL vynut\u00edte pomoc\u00ed zfs set sync=always<\/code>, st\u00e1le budou v\u00e1z\u00e1ny na hlavn\u00ed \u00falo\u017ei\u0161t\u011b v TXG stejn\u00fdm zp\u016fsobem a stejn\u00fdm tempem, jako bez \u017eurn\u00e1lu. Jedin\u00fdm p\u0159\u00edm\u00fdm zlep\u0161en\u00edm v\u00fdkonu je zpo\u017ed\u011bn\u00ed synchronn\u00edho z\u00e1pisu (proto\u017ee v\u011bt\u0161\u00ed rychlost \u017eurn\u00e1lu zrychluje prov\u00e1d\u011bn\u00ed operac\u00ed sync<\/code>).<\/p>\n

Nicm\u00e9n\u011b v prost\u0159ed\u00ed, kter\u00e9 ji\u017e vy\u017eaduje velk\u00e9 mno\u017estv\u00ed synchronn\u00edch z\u00e1pis\u016f, m\u016f\u017ee vdev LOG nep\u0159\u00edmo urychlit asynchronn\u00ed z\u00e1pis a nekorelovan\u00e9 \u010dten\u00ed. Vylo\u017een\u00ed z\u00e1pis\u016f ZIL do samostatn\u00e9ho vdev LOG znamen\u00e1 men\u0161\u00ed konkurenci o IOPS v prim\u00e1rn\u00edm \u00falo\u017ei\u0161ti, co\u017e do jist\u00e9 m\u00edry zvy\u0161uje v\u00fdkon v\u0161ech operac\u00ed \u010dten\u00ed a z\u00e1pisu.<\/p>\n

Snapshoty<\/h3>\n

\nMechanismus kop\u00edrov\u00e1n\u00ed p\u0159i z\u00e1pisu je tak\u00e9 nezbytn\u00fdm z\u00e1kladem pro atomick\u00e9 okam\u017eit\u00e9 sn\u00edmky ZFS a inkrement\u00e1ln\u00ed asynchronn\u00ed replikaci. V aktivn\u00edm souborov\u00e9m syst\u00e9mu existuje strom ukazatel\u016f, kter\u00fd ozna\u010duje v\u0161echny z\u00e1pisy s aktu\u00e1ln\u00edmi daty - kdy\u017e vytv\u00e1\u0159\u00edte sn\u00edmek, pouze kop\u00edrujete tento strom ukazatel\u016f.<\/p>\n

Kdy\u017e se v aktivn\u00edm souborov\u00e9m syst\u00e9mu p\u0159episuje z\u00e1pis, ZFS nejprve zap\u00ed\u0161e novou verzi bloku do nevyu\u017eit\u00e9ho prostoru. Pot\u00e9 odpoj\u00ed starou verzi bloku od aktu\u00e1ln\u00edho souborov\u00e9ho syst\u00e9mu. Ale pokud n\u011bjak\u00fd sn\u00edmek odkazuje na star\u00fd blok, ten z\u016fst\u00e1v\u00e1 nezm\u011bn\u011bn. Star\u00fd blok ve skute\u010dnosti nebude obnoven jako voln\u00e9 m\u00edsto, dokud nebudou zni\u010deny v\u0161echny sn\u00edmky, kter\u00e9 na tento blok odkazuj\u00ed!<\/p>\n

Replikace<\/h3>\n

\n\"Z\u00e1klady
\nM\u00e9 Steam knihovna v roce 2015 zab\u00edrala 158 GiB a obsahovala 126 927 soubor\u016f. To je pom\u011brn\u011b bl\u00edzko optim\u00e1ln\u00ed situaci pro rsync - replikace ZFS p\u0159es s\u00ed\u0165 byla \u201epouze\u201c o 750% rychlej\u0161\u00ed.<\/i><\/p>\n

\"Z\u00e1klady
\nV t\u00e9\u017ee s\u00edti je replikace jednoho 40-gibibyte souboru obrazu virtu\u00e1ln\u00edho stroje Windows 7 \u00fapln\u011b jin\u00e1 z\u00e1le\u017eitost. Replikace ZFS prob\u00edh\u00e1 289kr\u00e1t rychleji ne\u017e rsync \u2013 nebo \u00abpouze\u00bb 161kr\u00e1t rychleji, pokud v\u00edte, jak spustit rsync s parametrem --inplace.<\/i><\/p>\n

\"Z\u00e1klady
\nKdy\u017e se obraz virtu\u00e1ln\u00edho stroje \u0161k\u00e1luje, probl\u00e9my rsync se roz\u0161i\u0159uj\u00ed spolu s n\u00edm. Velikost 1,9 TiB nen\u00ed pro modern\u00ed obraz virtu\u00e1ln\u00edho stroje tak velk\u00e1 \u2013 ale je dostate\u010dn\u011b velk\u00e1 na to, aby replikace ZFS byla 1148kr\u00e1t rychlej\u0161\u00ed ne\u017e rsync, i s parametrem rsync --inplace.<\/i><\/p>\n

Jakmile pochop\u00edte, jak funguj\u00ed sn\u00edmky, nebude obt\u00ed\u017en\u00e9 uchopit podstatu replikace. Proto\u017ee sn\u00edmek je pouze strom ukazatel\u016f na z\u00e1znamy, vypl\u00fdv\u00e1 z toho, \u017ee kdy\u017e d\u011bl\u00e1me zfs send<\/code> sn\u00edmku, pos\u00edl\u00e1me jak tento strom, tak v\u0161echny souvisej\u00edc\u00ed z\u00e1znamy. Kdy\u017e ho p\u0159ed\u00e1v\u00e1me pomoc\u00ed zfs send<\/code> v zfs receive<\/code> c\u00edlov\u00e9mu objektu, zap\u00ed\u0161e jak skute\u010dn\u00fd obsah bloku, tak strom ukazatel\u016f, kter\u00e9 odkazuj\u00ed na bloky, do c\u00edlov\u00e9 datov\u00e9 sady.<\/p>\n

V\u0161echno se st\u00e1v\u00e1 je\u0161t\u011b zaj\u00edmav\u011bj\u0161\u00edm na druh\u00e9m zfs send<\/code>. Nyn\u00ed m\u00e1me dva syst\u00e9my, z nich\u017e ka\u017ed\u00fd obsahuje poolname\/datasetname@1<\/code>, zat\u00edmco vy po\u0159izujete nov\u00fd sn\u00edmek poolname\/datasetname@2<\/code>. Proto ve zdrojov\u00e9m poolu m\u00e1te datasetname@1<\/code> a datasetname@2<\/code>, zat\u00edmco v c\u00edlov\u00e9m poolu m\u00e1 zat\u00edm pouze prvn\u00ed sn\u00edmek. datasetname@1<\/code>.<\/p>\n

Proto\u017ee mezi zdrojem a c\u00edlem m\u00e1me spole\u010dn\u00fd sn\u00edmek datasetname@1<\/code>, m\u016f\u017eeme prov\u00e9st inkrement\u00e1ln\u00ed<\/i> zfs send<\/code> replikaci k n\u011bmu. Kdy\u017e \u0159\u00edk\u00e1me syst\u00e9mu zfs send -i poolname\/datasetname@1 poolname\/datasetname@2<\/code>, porovn\u00e1v\u00e1 dv\u011b stromy ukazatel\u016f. Jak\u00e9koli ukazatele, kter\u00e9 existuj\u00ed pouze v @2<\/code>, odkazuj\u00ed na nov\u00e9 bloky \u2014 proto pot\u0159ebujeme obsah t\u011bchto blok\u016f.<\/p>\n

V d\u00e1lkov\u00e9m syst\u00e9mu je zpracov\u00e1n\u00ed inkrement\u00e1ln\u00edho send<\/code> tak\u00e9 stejn\u011b jednoduch\u00e9. Nejprve zap\u00ed\u0161eme v\u0161echny nov\u00e9 z\u00e1znamy zahrnut\u00e9 v toku send<\/code>, a pak p\u0159id\u00e1me ukazatele na tyto bloky. Voil\u00e0, m\u00e1me @2<\/code> v nov\u00e9m syst\u00e9mu!<\/p>\n

Asynchronn\u00ed inkrement\u00e1ln\u00ed replikace ZFS je obrovsk\u00e9 zlep\u0161en\u00ed oproti d\u0159\u00edv\u011bj\u0161\u00edm metod\u00e1m, kter\u00e9 nejsou zalo\u017eeny na sn\u00edmc\u00edch, jako je rsync. V obou p\u0159\u00edpadech se p\u0159en\u00e1\u0161ej\u00ed pouze zm\u011bn\u011bn\u00e1 data \u2014 ale rsync mus\u00ed nejprve p\u0159e\u010d\u00edst<\/i> ze diskem v\u0161echny \u00fadaje z obou stran, abychom zkontrolovali sou\u010det a porovnali ho. Na rozd\u00edl od toho replikace ZFS ne\u010dte nic jin\u00e9ho ne\u017e stromy ukazatel\u016f \u2014 a jak\u00e9koli bloky, kter\u00e9 nejsou zastoupeny ve spole\u010dn\u00e9m sn\u00edmku.<\/p>\n

Vestav\u011bn\u00e9 komprese<\/h3>\n

\nMechanismus kop\u00edrov\u00e1n\u00ed p\u0159i z\u00e1pisu tak\u00e9 zjednodu\u0161uje syst\u00e9m vestav\u011bn\u00e9ho komprese. V tradi\u010dn\u00edm souborov\u00e9m syst\u00e9mu je komprese problematick\u00e1 \u2014 jak star\u00e1 verze, tak nov\u00e1 verze zm\u011bn\u011bn\u00fdch dat se nach\u00e1zej\u00ed ve stejn\u00e9m prostoru.<\/p>\n

Pokud zv\u00e1\u017e\u00edme fragment dat uprost\u0159ed souboru, kter\u00fd za\u010d\u00edn\u00e1 \u017eivot jako megabajt nul od 0x00000000 a tak d\u00e1le \u2014 velmi snadno se zmen\u0161\u00ed na jeden sektor na disku. Ale co se stane, kdy\u017e nahrad\u00edme tento megabajt nul megabajtem nekomprimovan\u00fdch dat, jako je JPEG nebo pseudon\u00e1hodn\u00fd \u0161um? Najednou tento megabajt dat vy\u017eaduje ne jeden, ale 256 sektor\u016f po 4 KiB, a na tomto m\u00edst\u011b disku je rezervov\u00e1n pouze jeden sektor.<\/p>\n

U ZFS nen\u00ed tento probl\u00e9m, proto\u017ee zm\u011bn\u011bn\u00e9 z\u00e1znamy jsou v\u017edy zapisov\u00e1ny do nevyu\u017eit\u00e9ho prostoru \u2014 p\u016fvodn\u00ed blok zab\u00edr\u00e1 pouze jeden sektor 4 KiB, a nov\u00e1 z\u00e1znam zabere 256, ale to nen\u00ed probl\u00e9m \u2014 ned\u00e1vno zm\u011bn\u011bn\u00fd fragment z \"prost\u0159edka\" souboru by byl zaznamen\u00e1n do nevyu\u017eit\u00e9ho prostoru bez ohledu na to, zda se jeho velikost zm\u011bnila nebo ne, tak\u017ee pro ZFS je to docela b\u011b\u017en\u00e1 situace.<\/p>\n

Vestav\u011bn\u00e9 komprese ZFS je ve v\u00fdchoz\u00edm nastaven\u00ed vypnuto, a syst\u00e9m nab\u00edz\u00ed p\u0159ipojiteln\u00e9 algoritmy \u2014 nyn\u00ed mezi nimi LZ4, gzip (1-9), LZJB a ZLE.<\/p>\n

Pokud je soubor dostate\u010dn\u011b velk\u00fd a vy\u017eaduje v\u00edce blok\u016f, v\u0161echny z\u00e1znamy s t\u00edmto souborem budou m\u00edt velikost recordsize<\/code>\u00a0\u2013 v\u010detn\u011b posledn\u00edho z\u00e1znamu, jeho\u017e hlavn\u00ed \u010d\u00e1st m\u016f\u017ee b\u00fdt nevyu\u017eit\u00fdm prostorem.<\/a><\/noindex>.<\/p>\n