{"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\/sk\/blog\/administrirovanie\/osnovy-zfs-sistema-hraneniya-i-proizvoditelnost","title":{"rendered":"Z\u00e1klady ZFS: \u00falo\u017en\u00fd syst\u00e9m a v\u00fdkon","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Z\u00e1klady
\n
\nT\u00fato jar sme u\u017e prediskutovali niektor\u00e9 \u00favodn\u00e9 t\u00e9my, napr\u00edklad, ako skontrolova\u0165 r\u00fdchlos\u0165 va\u0161ich diskov<\/a><\/noindex> a \u010do je RAID<\/a><\/noindex>. V druhom z nich sme dokonca pris\u013e\u00fabili pokra\u010dova\u0165 v sk\u00faman\u00ed v\u00fdkonu r\u00f4znych viacdiskov\u00fdch topol\u00f3gi\u00ed v ZFS. Ide o s\u00faborov\u00fd syst\u00e9m novej gener\u00e1cie, ktor\u00fd sa aktu\u00e1lne zav\u00e1dza v\u0161ade: od Apple<\/a><\/noindex> do Ubuntu<\/a><\/noindex>.
\n<\/a><\/noindex>
\nNo \u010do, dnes je ten najvhodnej\u0161\u00ed de\u0148 na zozn\u00e1menie sa so ZFS, zvedav\u00ed \u010ditatelia. jednoducho vedzte, \u017ee pod\u013ea skromn\u00e9ho odhadu v\u00fdvoj\u00e1ra OpenZFS Matta Arensa, \u201eje to naozaj zlo\u017eit\u00e9\u201c.<\/p>\n

Ale predt\u00fdm, ne\u017e sa dostaneme k \u010d\u00edslam \u2013 a tie tu bud\u00fa, s\u013eubujem \u2013 o v\u0161etk\u00fdch variant\u00e1ch osemdiskovej konfigur\u00e1cie ZFS, mus\u00edme sa porozpr\u00e1va\u0165 o tom, ako<\/i> v\u00f4bec ZFS uchov\u00e1va d\u00e1ta na disku.<\/p>\n

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

\n\"Z\u00e1klady
\nTento diagram pln\u00e9ho puzdra obsahuje tri podporn\u00e9 vdevy, po jednom z ka\u017edej triedy, a \u0161tyri pre RAIDz2.<\/i><\/p>\n

\"Z\u00e1klady
\nZvy\u010dajne nie s\u00fa d\u00f4vody na vytv\u00e1ranie poolu z nekompatibiln\u00fdch typov a ve\u013ekost\u00ed vdev \u2013 ale ak chcete, ni\u010d v\u00e1m nebr\u00e1ni to urobi\u0165<\/i><\/p>\n

Aby ste naozaj pochopili s\u00faborov\u00fd syst\u00e9m ZFS, mus\u00edte sa pozrie\u0165 na jeho skuto\u010dn\u00fa \u0161trukt\u00faru. Po prv\u00e9, ZFS kombinuje tradi\u010dn\u00e9 \u00farovne spr\u00e1vy objemov a s\u00faborov\u00e9ho syst\u00e9mu. Po druh\u00e9, pou\u017e\u00edva transak\u010dn\u00fd mechanizmus kop\u00edrovania pri z\u00e1pise. Tieto vlastnosti znamenaj\u00fa, \u017ee syst\u00e9m je \u0161truktur\u00e1lne ve\u013emi odli\u0161n\u00fd od be\u017en\u00fdch s\u00faborov\u00fdch syst\u00e9mov a RAID pol\u00ed. Prv\u00e1 sada z\u00e1kladn\u00fdch stavebn\u00fdch blokov na pochopenie: je to \u00falo\u017en\u00fd pool (zpool), virtu\u00e1lne zariadenie (vdev) a re\u00e1lne zariadenie (device).<\/p>\n

zpool<\/h3>\n

\n\u00dalo\u017en\u00fd pool zpool je najvy\u0161\u0161ia \u0161trukt\u00fara ZFS. Ka\u017ed\u00fd pool obsahuje jedno alebo viac virtu\u00e1lnych zariaden\u00ed. Tie na opl\u00e1tku obsahuj\u00fa jedno alebo viac re\u00e1lnych zariaden\u00ed (device). Virtu\u00e1lne pooly s\u00fa samostatn\u00e9 bloky. Jeden fyzick\u00fd po\u010d\u00edta\u010d m\u00f4\u017ee obsahova\u0165 dva alebo viac samostatn\u00fdch poolov, ale ka\u017ed\u00fd je \u00faplne nez\u00e1visl\u00fd od ostatn\u00fdch. Pooly nem\u00f4\u017eu zdie\u013ea\u0165 virtu\u00e1lne zariadenia.<\/p>\n

Redundancia ZFS sa nach\u00e1dza na \u00farovni virtu\u00e1lnych zariaden\u00ed, a nie na \u00farovni poolov. Na \u00farovni poolov nie je absol\u00fatne \u017eiadna redundancia \u2013 ak sa strat\u00ed ak\u00e9ko\u013evek zariadenie vdev alebo \u0161peci\u00e1lne vdev, spolu s n\u00edm sa strat\u00ed aj cel\u00fd pool.<\/p>\n

S\u00fa\u010dasn\u00e9 \u00falo\u017en\u00e9 pooly m\u00f4\u017eu pre\u017ei\u0165 stratu cache alebo denn\u00edka virtu\u00e1lneho zariadenia \u2014 hoci m\u00f4\u017eu strati\u0165 mal\u00e9 mno\u017estvo \u0161pinav\u00fdch \u00fadajov, ak strat\u00ed denn\u00edk vdev po\u010das v\u00fdpadku nap\u00e1jania alebo syst\u00e9mu.<\/p>\n

Existuje roz\u0161\u00edren\u00e9 zav\u00e1dzanie, \u017ee \u201e\u00fadajov\u00e9 p\u00e1sy\u201c (stripes) ZFS s\u00fa zapisovan\u00e9 cez cel\u00fd pool. To nie je pravda. Zpool nie je len z\u00e1bavn\u00fd RAID0, je to sk\u00f4r z\u00e1bavn\u00fd JBOD<\/a><\/noindex> so zlo\u017eit\u00fdm premenliv\u00fdm mechanizmom distrib\u00facie.<\/p>\n

Vo v\u00e4\u010d\u0161ine pr\u00edpadov s\u00fa z\u00e1pisy distribuovan\u00e9 medzi dostupn\u00e9 virtu\u00e1lne zariadenia pod\u013ea dostupn\u00e9ho vo\u013en\u00e9ho miesta, tak\u017ee teoreticky bud\u00fa v\u0161etky vyplnen\u00e9 s\u00fa\u010dasne. V nov\u0161\u00edch verzi\u00e1ch ZFS sa zoh\u013ead\u0148uje aktu\u00e1lne vyu\u017eitie (utiliz\u00e1cia) vdev \u2014 ak je jedno virtu\u00e1lne zariadenie v\u00fdrazne za\u0165a\u017een\u00e9 viac ako in\u00e9 (napr\u00edklad kv\u00f4li za\u0165a\u017eeniu pri \u010d\u00edtan\u00ed), do\u010dasne sa vynech\u00e1 pre z\u00e1pis, aj ke\u010f m\u00e1 najvy\u0161\u0161\u00ed koeficient vo\u013en\u00e9ho miesta.<\/p>\n

Mechanizmus ur\u010dovania vyu\u017eitia, integrovan\u00fd do modern\u00fdch met\u00f3d distrib\u00facie z\u00e1pisu ZFS, m\u00f4\u017ee zn\u00ed\u017ei\u0165 latenciu a zv\u00fd\u0161i\u0165 priepustnos\u0165 po\u010das obdob\u00ed nezvy\u010dajne vysok\u00e9ho za\u0165a\u017eenia \u2014 ale to nie je blank check<\/i> na ne\u00famyseln\u00e9 mie\u0161anie pomal\u00fdch HDD a r\u00fdchlych SSD v jednom poole. Tak\u00fdto nevyv\u00e1\u017een\u00fd pool bude st\u00e1le fungova\u0165 r\u00fdchlos\u0165ou najpomal\u0161ieho zariadenia, teda akoby bol \u00faplne zlo\u017een\u00fd z tak\u00fdchto zariaden\u00ed.<\/p>\n

vdev<\/h3>\n

\nKa\u017ed\u00fd \u00falo\u017en\u00fd pool pozost\u00e1va z jedn\u00e9ho alebo viacer\u00fdch virtu\u00e1lnych zariaden\u00ed (virtual device, vdev). Ka\u017ed\u00e9 vdev na druhej strane zah\u0155\u0148a jedno alebo viac skuto\u010dn\u00fdch zariaden\u00ed. V\u00e4\u010d\u0161ina virtu\u00e1lnych zariaden\u00ed sa pou\u017e\u00edva na jednoduch\u00e9 \u00falo\u017eisko d\u00e1t, ale existuje nieko\u013eko pomocn\u00fdch tried vdev, vr\u00e1tane CACHE, LOG a SPECIAL. Ka\u017ed\u00fd z t\u00fdchto typov vdev m\u00f4\u017ee ma\u0165 jednu z piatich topol\u00f3gi\u00ed: jedin\u00e9 zariadenie (single-device), RAIDz1, RAIDz2, RAIDz3 alebo zrkadlo (mirror).<\/p>\n

RAIDz1, RAIDz2 a RAIDz3 s\u00fa \u0161peci\u00e1lne typy toho, \u010do star\u00ed naz\u00fdvaj\u00fa RAID s dvojitou (diagon\u00e1lnou) paritou. 1, 2 a 3 sa vz\u0165ahuj\u00fa na po\u010det blokov par\u00edt, ktor\u00e9 s\u00fa pridelen\u00e9 pre ka\u017ed\u00fd pruh d\u00e1t. Namiesto samostatn\u00fdch diskov na zabezpe\u010denie parity virtu\u00e1lne RAIDz zariadenia rovnomerne rozde\u013euj\u00fa t\u00fato paritu na disky. RAIDz pole m\u00f4\u017ee strati\u0165 to\u013eko diskov, ko\u013eko m\u00e1 blokov par\u00edt; ak strat\u00ed e\u0161te jeden, zlyh\u00e1 a odnesie so sebou \u00falo\u017en\u00fd pool.<\/p>\n

Vo zrkadlovo virtu\u00e1lnych zariadeniach (mirror vdev) sa ka\u017ed\u00fd blok uklad\u00e1 na ka\u017ed\u00e9 zariadenie v vdev. Hoci najbe\u017enej\u0161ie s\u00fa dvojit\u00e9 zrkadl\u00e1 (two-wide), v zrkadle m\u00f4\u017ee by\u0165 ak\u00e9ko\u013evek \u013eubovo\u013en\u00e9 mno\u017estvo zariaden\u00ed \u2014 vo ve\u013ek\u00fdch in\u0161tal\u00e1ci\u00e1ch na zv\u00fd\u0161enie v\u00fdkonu \u010d\u00edtania a odolnosti proti zlyhaniu sa \u010dasto pou\u017e\u00edvaj\u00fa trojit\u00e9. Zrkadlo vdev m\u00f4\u017ee pre\u017ei\u0165 ak\u00e9ko\u013evek zlyhanie, pokia\u013e funguje aspo\u0148 jedno zariadenie v vdev.<\/p>\n

Jednotliv\u00e9 vdev s\u00fa z podstaty nebezpe\u010dn\u00e9. Tak\u00e9to virtu\u00e1lne zariadenie nepre\u017eije \u017eiadne zlyhanie \u2014 a ak sa pou\u017e\u00edva ako \u00falo\u017eisko alebo \u0161peci\u00e1lne vdev, jeho zlyhanie sp\u00f4sob\u00ed zni\u010denie cel\u00e9ho poolu. Bu\u010fte tu ve\u013emi, ve\u013emi opatrn\u00ed.<\/p>\n

Virtu\u00e1lne zariadenia CACHE, LOG a SPECIAL m\u00f4\u017eu by\u0165 vytvoren\u00e9 v akejko\u013evek z uveden\u00fdch topol\u00f3gi\u00ed \u2014 ale pam\u00e4tajte, \u017ee strata virtu\u00e1lneho zariadenia SPECIAL znamen\u00e1 stratu poolu, preto sa d\u00f4razne odpor\u00fa\u010da redundantn\u00e1 topol\u00f3gia.<\/p>\n

device<\/h3>\n

\nToto je pravdepodobne najjednoduch\u0161\u00ed term\u00edn na pochopenie v ZFS \u2014 je to doslova blokov\u00e9 zariadenie s n\u00e1hodn\u00fdm pr\u00edstupom. Pam\u00e4tajte, \u017ee virtu\u00e1lne zariadenia sa skladaj\u00fa z jednotliv\u00fdch zariaden\u00ed a pool je zlo\u017een\u00fd z virtu\u00e1lnych zariaden\u00ed.<\/p>\n

Disky \u2014 magnetick\u00e9 alebo solid-state \u2014 s\u00fa najbe\u017enej\u0161ie blokov\u00e9 zariadenia, ktor\u00e9 sa pou\u017e\u00edvaj\u00fa ako stavebn\u00e9 bloky vdev. Av\u0161ak ak\u00e9ko\u013evek zariadenie s deskriptorom v \/dev je vhodn\u00e9 \u2014 tak\u017ee ako jednotliv\u00e9 zariadenia m\u00f4\u017eu by\u0165 pou\u017eit\u00e9 cel\u00e9 hardwarov\u00e9 RAID polia.<\/p>\n

Jednoduch\u00fd raw s\u00fabor je jedn\u00fdm z najd\u00f4le\u017eitej\u0161\u00edch alternat\u00edvnych blokov\u00fdch zariaden\u00ed, z ktor\u00fdch m\u00f4\u017ee by\u0165 vdev postaven\u00fd. Testovacie pooly z sparse files<\/a><\/noindex>\u00a0s\u00fa ve\u013emi pohodln\u00fdm sp\u00f4sobom, ako testova\u0165 pr\u00edkazy poolu a vidie\u0165, ko\u013eko miesta je k dispoz\u00edcii v poole alebo virtu\u00e1lnom zariaden\u00ed danej topol\u00f3gie.<\/p>\n

\"Z\u00e1klady
\nM\u00f4\u017eete vytvori\u0165 testovac\u00ed pool zo zdie\u013ean\u00fdch s\u00faborov len za nieko\u013eko sek\u00fand \u2014 ale nezabudnite nesk\u00f4r odstr\u00e1ni\u0165 cel\u00fd pool a jeho komponenty.<\/i> <\/p>\n

Predpokladajme, \u017ee chcete nastavi\u0165 server s \u00f4smymi diskami a pl\u00e1nujete pou\u017ei\u0165 disky s kapacitou 10 TB (~9300 GiB) \u2014 ale nie ste si ist\u00ed, ktor\u00e1 topol\u00f3gia najlep\u0161ie vyhovuje va\u0161im potreb\u00e1m. V predch\u00e1dzaj\u00facom pr\u00edklade vytv\u00e1rame testovac\u00ed pool zo zdie\u013ean\u00fdch s\u00faborov len za nieko\u013eko sek\u00fand \u2014 a teraz vieme, \u017ee RAIDz2 vdev z \u00f4smich diskov s kapacitou 10 TB poskytuje 50 TiB vyu\u017eite\u013enej kapacity.<\/p>\n

\u010eal\u0161ou \u0161peci\u00e1lnou triedou zariaden\u00ed s\u00fa SPARE (n\u00e1hradn\u00e9). Zariadenia na hor\u00facu v\u00fdmenu, na rozdiel od be\u017en\u00fdch zariaden\u00ed, patria cel\u00e9mu poolu, nie jedn\u00e9mu virtu\u00e1lnemu zariadeniu. Ak nejak\u00fd vdev v poole zlyh\u00e1 a n\u00e1hradn\u00e9 zariadenie je pripojen\u00e9 k poolu a dostupn\u00e9, automaticky sa pripoj\u00ed k postihnut\u00e9mu vdev.<\/p>\n

Po pripojen\u00ed k postihnut\u00e9mu vdev n\u00e1hradn\u00e9 zariadenie za\u010d\u00edna dost\u00e1va\u0165 k\u00f3pie alebo rekon\u0161trukcie d\u00e1t, ktor\u00e9 by mali by\u0165 na ch\u00fdbaj\u00facom zariaden\u00ed. V tradi\u010dnom RAID sa tomu hovor\u00ed obnova (rebuilding) a v ZFS to je \"obnova redundancie\" (resilvering).<\/p>\n

Je d\u00f4le\u017eit\u00e9 poznamena\u0165, \u017ee n\u00e1hradn\u00e9 zariadenia trvale nenahr\u00e1dzaj\u00fa zlyhan\u00e9 zariadenia. To je len do\u010dasn\u00e1 n\u00e1hrada na skr\u00e1tenie \u010dasu, po\u010das ktor\u00e9ho je vdev v degradovanom stave. Po tom, \u010do administr\u00e1tor nahrad\u00ed zlyhan\u00e9 zariadenie vdev, d\u00f4jde k obnove redundancie na toto trval\u00e9 zariadenie a SPARE sa odpoj\u00ed od vdev a vr\u00e1ti sa k pr\u00e1ci ako n\u00e1hradn\u00fd pre cel\u00fd pool.<\/p>\n

Sady d\u00e1t, bloky a sektory<\/h1>\n

\n\u010eal\u0161\u00ed s\u00fabor z\u00e1kladn\u00fdch blokov, ktor\u00e9 treba pochopi\u0165 v na\u0161ej ceste cez ZFS, sa net\u00fdka to\u013eko hardv\u00e9ru, ako sk\u00f4r toho, ako s\u00fa samotn\u00e9 d\u00e1ta organizovan\u00e9 a ulo\u017een\u00e9. Prech\u00e1dzame tu nieko\u013ek\u00fdmi \u00farov\u0148ami \u2014 ako je metaslab \u2014 aby sme nezav\u00e1dzali detaily a zachovali porozumenie celkovej \u0161trukt\u00fare.<\/p>\n

S\u00fabor d\u00e1t (dataset)<\/h3>\n

\n\"Z\u00e1klady
\nKe\u010f prv\u00fdkr\u00e1t vytvor\u00edme s\u00fabor d\u00e1t, zobrazuje v\u0161etok dostupn\u00fd priestor poolu. Potom nastav\u00edme kv\u00f3tu \u2014 a men\u00edme mont\u00e1\u017eny bod. \u010carovn\u00e9!<\/i> <\/p>\n

\"Z\u00e1klady
\nZvol je v podstate len s\u00fabor d\u00e1t bez svojej vrstvy s\u00faborov\u00e9ho syst\u00e9mu, ktor\u00fa tu nahr\u00e1dzame \u00faplne norm\u00e1lnym s\u00faborov\u00fdm syst\u00e9mom ext4.<\/i> <\/p>\n

Dataset ZFS je pribli\u017ene rovnak\u00fd ako \u0161tandardn\u00fd pripojen\u00fd s\u00faborov\u00fd syst\u00e9m. Rovnako ako be\u017en\u00fd s\u00faborov\u00fd syst\u00e9m, na prv\u00fd poh\u013ead sa zd\u00e1, \u017ee je to \"len \u010fal\u0161ia prie\u010dinok\". Ale, ako v be\u017en\u00fdch pripojen\u00fdch s\u00faborov\u00fdch syst\u00e9moch, ka\u017ed\u00fd dataset ZFS m\u00e1 svoj vlastn\u00fd s\u00fabor z\u00e1kladn\u00fdch vlastnost\u00ed.<\/p>\n

Predov\u0161etk\u00fdm m\u00f4\u017ee ma\u0165 dataset stanoven\u00fa kv\u00f3tu. Ak nastav\u00edte zfs set quota=100G poolname\/datasetname<\/code>, nebudete m\u00f4c\u0165 zapisova\u0165 do pripojenej prie\u010dinka \/poolname\/datasetname<\/code> viac ako 100 GiB.<\/p>\n

V\u0161imli ste si pr\u00edtomnos\u0165 \u2013 aj nepr\u00edtomnos\u0165 \u2013 lom\u00edtok na za\u010diatku ka\u017ed\u00e9ho riadku? Ka\u017ed\u00fd dataset m\u00e1 svoje miesto ako v hierarchii ZFS, tak aj v hierarchii syst\u00e9mov\u00e9ho pripojenia. V hierarchii ZFS nie je ved\u00face lom\u00edtko \u2013 za\u010d\u00ednate s n\u00e1zvom poolu a potom smerujete od jedn\u00e9ho datasetu k druh\u00e9mu. Napr\u00edklad, pool\/parent\/child<\/code> pre dataset s n\u00e1zvom child<\/code> pod rodi\u010dovsk\u00fdm datasetom parent<\/code> v puli s kreat\u00edvnym n\u00e1zvom pool<\/code>.<\/p>\n

Predvolene, bod pripojenia datasetu bude ekvivalentn\u00fd jeho n\u00e1zvu v hierarchii ZFS, so zlomen\u00fdm lom\u00edtkom na za\u010diatku \u2013 pool s n\u00e1zvom pool<\/code> bude pripojen\u00fd ako \/pool<\/code>, dataset parent<\/code> sa pripoj\u00ed do \/pool\/parent<\/code>, a dc\u00e9rsky dataset child<\/code> sa pripoj\u00ed do \/pool\/parent\/child<\/code>. M\u00f4\u017eete v\u0161ak zmeni\u0165 syst\u00e9mov\u00fd bod pripojenia datasetu.<\/p>\n

Ak uvedieme zfs set mountpoint=\/lol pool\/parent\/child<\/code>, dataset pool\/parent\/child<\/code> sa pripoj\u00ed do syst\u00e9mu ako \/lol<\/code>.<\/p>\n

Okrem datasetov by sme mali spomen\u00fa\u0165 aj objemy (zvols). Objem je pribli\u017ene rovnak\u00fd ako dataset, s v\u00fdnimkou toho, \u017ee v \u0148om prakticky nie je s\u00faborov\u00fd syst\u00e9m - je to len blokov\u00e9 zariadenie. M\u00f4\u017eete napr\u00edklad vytvori\u0165 zvol<\/code> s n\u00e1zvom mypool\/myzvol<\/code>, potom ho naform\u00e1tova\u0165 so s\u00faborov\u00fdm syst\u00e9mom ext4 a n\u00e1sledne pripoji\u0165 tento s\u00faborov\u00fd syst\u00e9m - teraz m\u00e1te s\u00faborov\u00fd syst\u00e9m ext4, ale s podporou v\u0161etk\u00fdch funkci\u00ed zabezpe\u010denia ZFS! M\u00f4\u017ee to vyzera\u0165 hl\u00fapo na jednom po\u010d\u00edta\u010di, ale m\u00e1 to omnoho v\u00e4\u010d\u0161\u00ed zmysel ako backend pri exporte zariadenia iSCSI.<\/p>\n

Bloky<\/h3>\n

\n\"Z\u00e1klady
\nS\u00fabor je reprezentovan\u00fd jedn\u00fdm alebo viacer\u00fdmi blokmi. Ka\u017ed\u00fd blok je ulo\u017een\u00fd na jednom virtu\u00e1lnom zariaden\u00ed. Ve\u013ekos\u0165 bloku je zvy\u010dajne rovn\u00e1 parametru recordsize<\/b>, ale m\u00f4\u017ee by\u0165 zn\u00ed\u017een\u00e1 na 2^ashift<\/b>, ak obsahuje metadata alebo mal\u00fd s\u00fabor.<\/i><\/p>\n

\"Z\u00e1klady
\nNaozaj, naozaj<\/b> ne\u017eartujeme o obrovskom po\u0161koden\u00ed v\u00fdkonu, ak nastav\u00edte pr\u00edli\u0161 mal\u00fd ashift.<\/i><\/p>\n

V ZFS pool s\u00fa v\u0161etky \u00fadaje, vr\u00e1tane metad\u00e1t, ulo\u017een\u00e9 v blokoch. Maxim\u00e1lna ve\u013ekos\u0165 bloku pre ka\u017ed\u00fd dataset je ur\u010den\u00e1 v vlastnosti recordsize<\/code> (ve\u013ekos\u0165 z\u00e1pisu). Ve\u013ekos\u0165 z\u00e1pisu sa m\u00f4\u017ee meni\u0165, ale to nezmen\u00ed ve\u013ekos\u0165 ani umiestnenie \u017eiadnych blokov, ktor\u00e9 u\u017e boli zap\u00edsan\u00e9 do datasetu \u2013 plat\u00ed to len pre nov\u00e9 bloky pri ich z\u00e1pise.<\/p>\n

Ak nie je ur\u010den\u00e9 inak, aktu\u00e1lna predvolen\u00e1 ve\u013ekos\u0165 z\u00e1pisu je 128 KiB. Ide o ak\u00fdsi zlo\u017eit\u00fd kompromis, pri ktorom v\u00fdkonnos\u0165 nebude ide\u00e1lna, ale ani hrozn\u00e1 vo v\u00e4\u010d\u0161ine pr\u00edpadov. Recordsize<\/code> m\u00f4\u017ee by\u0165 nastaven\u00e1 na ak\u00fako\u013evek hodnotu od 4K do 1M (s \u010fal\u0161\u00edmi nastaveniami recordsize<\/code> m\u00f4\u017ee by\u0165 nastaven\u00e1 e\u0161te vy\u0161\u0161ie, ale to zriedka b\u00fdva dobr\u00fd n\u00e1pad).<\/p>\n

Ka\u017ed\u00fd blok odkazuje na \u00fadaje len jedn\u00e9ho s\u00faboru \u2013 nem\u00f4\u017eete natla\u010di\u0165 dva r\u00f4zne s\u00fabory do jedn\u00e9ho bloku. Ka\u017ed\u00fd s\u00fabor sa sklad\u00e1 z jedn\u00e9ho alebo viacer\u00fdch blokov, v z\u00e1vislosti od ve\u013ekosti. Ak je ve\u013ekos\u0165 s\u00faboru men\u0161ia ako ve\u013ekos\u0165 z\u00e1pisu, ulo\u017e\u00ed sa v bloku men\u0161ej ve\u013ekosti \u2013 napr\u00edklad blok so s\u00faborom 2 KiB zaberie len jeden sektor 4 KiB na disku.<\/p>\n

Voly zvol nemaj\u00fa vlastnos\u0165 recordsize<\/code>\u00a0\u2013 namiesto toho maj\u00fa ekvivalentn\u00fa vlastnos\u0165 volblocksize<\/code>.<\/p>\n

Sekundy<\/h3>\n

\nPosledn\u00fd, najz\u00e1kladnej\u0161\u00ed stavebn\u00fd blok \u2013 sektor. Toto je najmen\u0161ia fyzick\u00e1 jednotka, ktor\u00e1 m\u00f4\u017ee by\u0165 zap\u00edsan\u00e1 alebo \u010d\u00edtan\u00e1 z fyzick\u00e9ho zariadenia. Po cel\u00e9 desa\u0165ro\u010dia sa na v\u00e4\u010d\u0161ine diskov pou\u017e\u00edvali sektory po 512 bajtoch. V poslednom \u010dase je v\u00e4\u010d\u0161ina diskov nastaven\u00e1 na sektory 4 KiB a v niektor\u00fdch \u2013 najm\u00e4 SSD \u2013 sektory 8 KiB alebo dokonca viac.<\/p>\n

V syst\u00e9me ZFS existuje vlastnos\u0165, ktor\u00e1 umo\u017e\u0148uje ru\u010dne nastavi\u0165 ve\u013ekos\u0165 sektora. T\u00e1to vlastnos\u0165 ashift<\/code>. Celkom zlo\u017eit\u00e9, \u017ee ashift je mocnina dvoch. Napr\u00edklad, ashift=9<\/code> znamen\u00e1 ve\u013ekos\u0165 sektora 2^9, alebo 512 bajtov.<\/p>\n

ZFS \u017eiada od opera\u010dn\u00e9ho syst\u00e9mu podrobn\u00e9 inform\u00e1cie o ka\u017ed\u00e9 blokov\u00e9 zariadenie, ke\u010f je pridan\u00e9 do nov\u00e9ho vdev, a teoreticky automaticky nastavuje ashift spr\u00e1vne na z\u00e1klade t\u00fdchto inform\u00e1ci\u00ed. Bohu\u017eia\u013e, mnoh\u00e9 disky klam\u00fa o svojej ve\u013ekosti sektora, aby zachovali kompatibilitu s Windows XP (ktor\u00e1 bola neschopn\u00e1 pochopi\u0165 disky s in\u00fdmi ve\u013ekos\u0165ami sektorov).<\/p>\n

To znamen\u00e1, \u017ee spr\u00e1vca ZFS by mal d\u00f4kladne pozna\u0165 skuto\u010dn\u00fa ve\u013ekos\u0165 sektora svojich zariaden\u00ed a manu\u00e1lne nastavi\u0165 ashift<\/code>. Ak je nastaven\u00fd pr\u00edli\u0161 mal\u00fd ashift, astronomicky sa zvy\u0161uje po\u010det oper\u00e1ci\u00ed \u010d\u00edtania\/z\u00e1pisu. Tak\u017ee z\u00e1pis 512-bytov\u00fdch \u201e sektorov\u201c do skuto\u010dn\u00e9ho sektora 4 KiB znamen\u00e1 potrebu zap\u00edsa\u0165 prv\u00fd \u201e sektor\u201c, potom pre\u010d\u00edta\u0165 sektor 4 KiB, zmeni\u0165 ho druh\u00fdm 512-bytov\u00fdm \u201e sektorom\u201c, zap\u00edsa\u0165 ho sp\u00e4\u0165 do nov\u00e9ho sektora 4 KiB a tak \u010falej pre ka\u017ed\u00fd z\u00e1pis.<\/p>\n

V re\u00e1lnom svete tak\u00fdto trest zasahuje do pevn\u00fdch diskov Samsung EVO, pre ktor\u00e9 by mal plati\u0165 ashift=13<\/code>, ale tieto SSD klam\u00fa o svojej ve\u013ekosti sektora, a preto je predvolene nastaven\u00fd ashift=9<\/code>. Ak sk\u00fasen\u00fd syst\u00e9mov\u00fd administr\u00e1tor tento parameter nezmen\u00ed, tak tento SSD pracuje pomal\u0161ie<\/i> ako be\u017en\u00fd magnetick\u00fd HDD.<\/p>\n

Na porovnanie, za pr\u00edli\u0161 ve\u013ek\u00fa ve\u013ekos\u0165 ashift<\/code> neexistuje prakticky \u017eiadny trest. Skuto\u010dn\u00e9 zn\u00ed\u017eenie v\u00fdkonu neexistuje a zv\u00fd\u0161enie nevyu\u017eit\u00e9ho priestoru je nekone\u010dne mal\u00e9 (alebo nulov\u00e9 pri zapnutom kompresii). Preto d\u00f4razne odpor\u00fa\u010dame aj pre tie disky, ktor\u00e9 skuto\u010dne pou\u017e\u00edvaj\u00fa 512-bytov\u00e9 sektory, nastavi\u0165 ashift=12<\/code> alebo aj ashift=13<\/code>, aby ste sa mohli s d\u00f4verou pozera\u0165 do bud\u00facnosti.<\/p>\n

Vlastnos\u0165 ashift<\/code> sa nastavuje pre ka\u017ed\u00e9 virtu\u00e1lne zariadenie vdev, a nie pre pool<\/i>, ako mnoh\u00ed mylne predpokladaj\u00fa \u2013 a nemen\u00ed sa po nastaven\u00ed. Ak ste n\u00e1hodou naru\u0161ili ashift<\/code> pri prid\u00e1van\u00ed nov\u00e9ho vdev do poolu, tak ste nen\u00e1vratne zne\u010distili tento pool zariaden\u00edm s n\u00edzkym v\u00fdkonom a spravidla niet inej cesty, len zni\u010di\u0165 pool a za\u010da\u0165 v\u0161etko odznova. Ani odstr\u00e1nenie vdev nezachr\u00e1ni pred zmenen\u00fdm nastaven\u00edm ashift<\/code>!<\/p>\n

Mechanizmus kop\u00edrovania pri z\u00e1pise<\/h3>\n

\n\"Z\u00e1klady
\nAk be\u017en\u00fd s\u00faborov\u00fd syst\u00e9m mus\u00ed prep\u00edsa\u0165 d\u00e1ta - men\u00ed ka\u017ed\u00fd blok tam, kde sa nach\u00e1dza.<\/i><\/p>\n

\"Z\u00e1klady
\nS\u00faborov\u00fd syst\u00e9m s kop\u00edrovan\u00edm pri z\u00e1pise zapisuje nov\u00fa verziu bloku a potom odomkne star\u00fa verziu.<\/i><\/p>\n

\"Z\u00e1klady
\nV abstraktnom po\u0148at\u00ed, ak ignorujeme re\u00e1lne fyzick\u00e9 umiestnenie blokov, sa na\u0161a \u201ekom\u00e9ta d\u00e1t\u201c zjednodu\u0161uje na \u201e\u010d\u00edta\u010d d\u00e1t\u201c, ktor\u00fd sa pohybuje z\u013eava doprava po mape dostupn\u00e9ho priestoru.<\/i><\/p>\n

\"Z\u00e1klady
\nTeraz m\u00e1me dobr\u00fa predstavu o tom, ako funguj\u00fa sn\u00edmky kop\u00edrovania pri z\u00e1pise \u2014 ka\u017ed\u00fd blok m\u00f4\u017ee patri\u0165 viacer\u00fdm sn\u00edmkam a zachov\u00e1 sa, pokia\u013e nebud\u00fa zni\u010den\u00e9 v\u0161etky s\u00favisiace sn\u00edmky.<\/i><\/p>\n

Mechanizmus kop\u00edrovania pri z\u00e1pise (Copy on Write, CoW) je z\u00e1kladnou z\u00e1klad\u0148ou toho, \u010do rob\u00ed ZFS tak \u00fa\u017easn\u00fdm syst\u00e9mom. Hlavn\u00e1 my\u0161lienka je jednoduch\u00e1 \u2014 ak po\u017eiadate tradi\u010dn\u00fd s\u00faborov\u00fd syst\u00e9m o zmenu s\u00faboru, urob\u00ed presne to, \u010do ste po\u017eiadali. Ak po\u017eiadate s\u00faborov\u00fd syst\u00e9m s kop\u00edrovan\u00edm pri z\u00e1pise o to ist\u00e9, povie v\u00e1m \u201edobre\u201c \u2014 ale zav\u00e1dza v\u00e1s.<\/p>\n

Namiesto toho s\u00faborov\u00fd syst\u00e9m s kop\u00edrovan\u00edm pri z\u00e1pise zapisuje nov\u00fa verziu zmenen\u00e9ho bloku a potom aktualizuje metad\u00e1ta s\u00faboru, aby preru\u0161en\u00edm v\u00e4zby na star\u00fd blok spojil nov\u00fd blok, ktor\u00fd ste pr\u00e1ve zap\u00edsali.<\/p>\n

Odpojenie star\u00e9ho bloku a spojenie nov\u00e9ho sa vykon\u00e1va v jednej oper\u00e1cii, tak\u017ee ju nemo\u017eno preru\u0161i\u0165 \u2014 ak vypnete nap\u00e1janie po tom, \u010do sa to stane, m\u00e1te nov\u00fa verziu s\u00faboru, a ak vypnete nap\u00e1janie sk\u00f4r, tak m\u00e1te star\u00fa verziu. V ka\u017edom pr\u00edpade v s\u00faborovom syst\u00e9me ned\u00f4jde ku konfliktom.<\/p>\n

Kop\u00edrovanie pri z\u00e1pise v ZFS sa deje nielen na \u00farovni s\u00faborov\u00e9ho syst\u00e9mu, ale aj na \u00farovni spr\u00e1vy diskov. To znamen\u00e1, \u017ee ZFS nie je vystaven\u00fd medzere pri z\u00e1pise (diera v RAID<\/a><\/noindex>) \u2014 fenom\u00e9nu, kdy p\u00e1ska bola len \u010diasto\u010dne zap\u00edsan\u00e1 pred zlyhan\u00edm syst\u00e9mu, s po\u0161koden\u00edm po\u013ea po re\u0161tarte. Tu sa p\u00e1ska zapisuje at\u00f3movo, vdev je v\u017edy konzistentn\u00fd, a Bob je tvoj str\u00fdko.<\/a><\/noindex>.<\/p>\n

ZIL: \u017eurn\u00e1l \u00famyslov ZFS.<\/h3>\n

\n\"Z\u00e1klady
\nSyst\u00e9m ZFS spracov\u00e1va synchronn\u00e9 z\u00e1pisy osobitn\u00fdm sp\u00f4sobom \u2014 do\u010dasne, ale okam\u017eite ich uklad\u00e1 do ZIL, predt\u00fdm ne\u017e ich nesk\u00f4r zap\u00ed\u0161e trvalo spolu s asynchr\u00f3nnymi z\u00e1pisami.<\/i><\/p>\n

\"Z\u00e1klady
\nZvy\u010dajne sa \u00fadaje zap\u00edsan\u00e9 do ZIL u\u017e nikdy ne\u010d\u00edtaj\u00fa. Ale to je mo\u017en\u00e9 po zlyhan\u00ed syst\u00e9mu.<\/i><\/p>\n

\"Z\u00e1klady
\nSLOG, alebo sekund\u00e1rne LOG zariadenie, je jednoducho \u0161peci\u00e1lny \u2013 a, ak je to mo\u017en\u00e9, ve\u013emi r\u00fdchly \u2013 vdev, kde m\u00f4\u017ee ZIL by\u0165 ulo\u017een\u00fd oddelene od hlavn\u00e9ho \u00falo\u017eiska.<\/i><\/p>\n

\"Z\u00e1klady
\nPo zlyhan\u00ed sa v\u0161etky nepresn\u00e9 \u00fadaje v ZIL obnovuj\u00fa \u2013 v tomto pr\u00edpade je ZIL na SLOG, tak\u017ee sa obnovuj\u00fa pr\u00e1ve odtia\u013e.<\/i><\/p>\n

Existuj\u00fa dve hlavn\u00e9 kateg\u00f3rie zapisovac\u00edch oper\u00e1ci\u00ed \u2013 synchronn\u00e9 (sync) a asynchronn\u00e9 (async). Pre v\u00e4\u010d\u0161inu pracovn\u00fdch z\u00e1\u0165a\u017e\u00ed je preva\u017en\u00e1 v\u00e4\u010d\u0161ina zapisovac\u00edch oper\u00e1ci\u00ed asynchronn\u00fdch \u2013 s\u00faborov\u00fd syst\u00e9m umo\u017e\u0148uje ich agreg\u00e1ciu a vyd\u00e1vanie v d\u00e1vkach, \u010d\u00edm sa zni\u017euje fragment\u00e1cia a zna\u010dne zvy\u0161uje priepustnos\u0165.<\/p>\n

Synchronn\u00e9 z\u00e1pisy s\u00fa \u00faplne in\u00e1 vec. Ke\u010f aplik\u00e1cia po\u017eaduje synchronn\u00fd z\u00e1pis, hovor\u00ed s\u00faborov\u00e9mu syst\u00e9mu: \u201eMus\u00ed\u0161 to zafixova\u0165 v nevolatile pam\u00e4ti pr\u00e1ve teraz. pr\u00e1ve teraz.<\/i>, a dovtedy nem\u00f4\u017eem urobi\u0165 ni\u010d in\u00e9.\u201c Preto musia by\u0165 synchronn\u00e9 z\u00e1pisy okam\u017eite zafixovan\u00e9 na disku \u2013 a ak to zvy\u0161uje fragment\u00e1ciu alebo zni\u017euje priepustnos\u0165, tak to bude.<\/p>\n

ZFS spracov\u00e1va synchronn\u00e9 z\u00e1pisy inak ako be\u017en\u00e9 s\u00faborov\u00e9 syst\u00e9my \u2013 namiesto okam\u017eit\u00e9ho z\u00e1znamu do be\u017en\u00e9ho \u00falo\u017eiska ZFS ich fixuje v \u0161peci\u00e1lnej oblasti ukladania naz\u00fdvanej ZFS Intent Log, alebo ZIL. Trik je v tom, \u017ee tieto z\u00e1pisy takisto<\/i> ost\u00e1vaj\u00fa v pam\u00e4ti, pri\u010dom s\u00fa agregovan\u00e9 spolu s be\u017en\u00fdmi asynchronn\u00fdmi z\u00e1pismi, aby mohli by\u0165 nesk\u00f4r zapsan\u00e9 do \u00falo\u017eiska ako \u00faplne norm\u00e1lne TXG (skupiny transakci\u00ed, Transaction Groups).<\/p>\n

V norm\u00e1lnom re\u017eime ZIL zapisuje a nikdy sa potom ne\u010d\u00edta. Ke\u010f sa po nieko\u013ek\u00fdch momentoch z\u00e1pisy z ZIL fixuj\u00fa do hlavn\u00e9ho \u00falo\u017eiska v be\u017en\u00fdch TXG z opera\u010dnej pam\u00e4te, s\u00fa oddelen\u00e9 od ZIL. Jedin\u00fd \u010das, kedy sa nie\u010do \u010d\u00edta z ZIL, je pri importe poolu.<\/p>\n

Ak d\u00f4jde k zlyhaniu ZFS \u2013 zlyhaniu opera\u010dn\u00e9ho syst\u00e9mu alebo preru\u0161enie nap\u00e1jania \u2013 ke\u010f s\u00fa v ZIL \u00fadaje, tieto \u00fadaje bud\u00fa pre\u010d\u00edtan\u00e9 pri nasleduj\u00facom importe poolu (napr\u00edklad pri re\u0161tartovan\u00ed havarijn\u00e9ho syst\u00e9mu). V\u0161etko, \u010do je v ZIL, bude pre\u010d\u00edtan\u00e9, zl\u00fa\u010den\u00e9 do TXG skup\u00edn, zafixovan\u00e9 do hlavn\u00e9ho \u00falo\u017eiska a potom oddelen\u00e9 od ZIL v procese importu.<\/p>\n

Jednou z pomocn\u00fdch tried vdev sa naz\u00fdva LOG alebo SLOG, sekund\u00e1rne zariadenie LOG. Jeho \u00falohou je poskytn\u00fa\u0165 pulu samostatn\u00e9 a, ide\u00e1lne, ove\u013ea r\u00fdchlej\u0161ie, s ve\u013emi vysokou odolnos\u0165ou proti z\u00e1pisu, zariadenie vdev na ukladanie ZIL, namiesto uchov\u00e1vania ZIL na hlavnom \u00falo\u017eisku vdev. Samotn\u00fd ZIL sa spr\u00e1va rovnako nez\u00e1visle od miesta ulo\u017eenia, ale ak m\u00e1 vdev s LOG ve\u013emi vysok\u00fd v\u00fdkon z\u00e1pisu, synchronizovan\u00e9 z\u00e1pisy sa uskuto\u010dnia r\u00fdchlej\u0161ie.<\/p>\n

Pridanie vdev s LOG do pulu nijako nem\u00f4\u017ee<\/b> zlep\u0161i\u0165 v\u00fdkon asynchr\u00f3nneho z\u00e1pisu - aj ke\u010f n\u00fatene vykon\u00e1vate v\u0161etky z\u00e1pisy do ZIL pomocou zfs set sync=always<\/code>, aj tak bud\u00fa viazan\u00e9 na hlavn\u00e9 \u00falo\u017eisko v TXG rovnak\u00fdm sp\u00f4sobom a rovnakou r\u00fdchlos\u0165ou ako bez denn\u00edka. Jedin\u00fdm priamym zlep\u0161en\u00edm v\u00fdkonu je latencia synchronizovan\u00e9ho z\u00e1pisu (ke\u010f\u017ee vy\u0161\u0161ia r\u00fdchlos\u0165 denn\u00edka zr\u00fdch\u013euje vykon\u00e1vanie oper\u00e1ci\u00ed. sync<\/code>).<\/p>\n

Av\u0161ak v prostred\u00ed, ktor\u00e9 u\u017e vy\u017eaduje ve\u013ea synchronizovan\u00fdch z\u00e1pisov, m\u00f4\u017ee vdev LOG nepriamo ur\u00fdchli\u0165 asynchr\u00f3nny z\u00e1pis a nekacovan\u00e9 \u010d\u00edtanie. Presunutie z\u00e1pisov ZIL do oddelen\u00e9ho vdev LOG znamen\u00e1 men\u0161iu konkurenciu za IOPS v prim\u00e1rnom \u00falo\u017eisku, \u010do do istej miery zlep\u0161uje v\u00fdkon v\u0161etk\u00fdch oper\u00e1ci\u00ed \u010d\u00edtania a z\u00e1pisu.<\/p>\n

Sn\u00edmky<\/h3>\n

\nMechanizmus copy-on-write je tie\u017e nevyhnutn\u00fdm z\u00e1kladom pre atom\u00e1rne okam\u017eit\u00e9 sn\u00edmky ZFS a inkrement\u00e1lnu asynchr\u00f3nnu replik\u00e1ciu. V akt\u00edvnom s\u00faborovom syst\u00e9me existuje strom ukazovate\u013eov, ktor\u00fd ozna\u010duje v\u0161etky z\u00e1pisy s aktu\u00e1lnymi \u00fadajmi - ke\u010f vytv\u00e1rate sn\u00edmku, jednoducho vytv\u00e1rate k\u00f3piu tohto stromu ukazovate\u013eov.<\/p>\n

Ke\u010f sa v akt\u00edvnom s\u00faborovom syst\u00e9me prep\u00ed\u0161e z\u00e1pis, ZFS najprv zap\u00ed\u0161e nov\u00fa verziu bloku do nepou\u017eit\u00e9ho priestoru. Potom odpoj\u00ed star\u00fa verziu bloku od aktu\u00e1lneho s\u00faborov\u00e9ho syst\u00e9mu. Ale ak sa na nejak\u00fa sn\u00edmku odkazuje na star\u00fd blok, ten zost\u00e1va nezmenen\u00fd. Star\u00fd blok sa v skuto\u010dnosti nebude obnovova\u0165 ako vo\u013en\u00fd priestor, k\u00fdm nebud\u00fa zni\u010den\u00e9 v\u0161etky sn\u00edmky, ktor\u00e9 odkazuj\u00fa na tento blok!<\/p>\n

Replik\u00e1cia<\/h3>\n

\n\"Z\u00e1klady
\nMoja kni\u017enica Steam v roku 2015 zaberala 158 GiB a obsahovala 126 927 s\u00faborov. To je dos\u0165 bl\u00edzko k optim\u00e1lnej situ\u00e1cii pre rsync - replik\u00e1cia ZFS po sieti bola \"iba\" o 750% r\u00fdchlej\u0161ia.<\/i><\/p>\n

\"Z\u00e1klady
\nV tej istej sieti je replik\u00e1cia jedn\u00e9ho 40-gibibajtov\u00e9ho s\u00faboru obrazu virtu\u00e1lneho stroja Windows 7 \u00faplne in\u00fd pr\u00edbeh. Replik\u00e1cia ZFS prebieha 289-kr\u00e1t r\u00fdchlej\u0161ie ako rsync \u2013 alebo 'len' 161-kr\u00e1t r\u00fdchlej\u0161ie, ak ste dostato\u010dne zbehl\u00ed na to, aby ste volali rsync s mo\u017enos\u0165ou —inplace.<\/i><\/p>\n

\"Z\u00e1klady
\nKe\u010f sa obraz virtu\u00e1lneho stroja \u0161k\u00e1luje, probl\u00e9my rsync sa \u0161k\u00e1luj\u00fa spolu s n\u00edm. Ve\u013ekos\u0165 1,9 TiB nie je pre modern\u00fd obraz virtu\u00e1lneho stroja a\u017e tak\u00e1 ve\u013ek\u00e1 \u2013 ale je dostato\u010dne ve\u013ek\u00e1 na to, aby replik\u00e1cia ZFS bola 1148-kr\u00e1t r\u00fdchlej\u0161ia ako rsync, aj s argumentom rsync —inplace.<\/i><\/p>\n

Hne\u010f, ako pochop\u00edte, ako funguj\u00fa sn\u00edmky, nebude \u0165a\u017ek\u00e9 pochopi\u0165 podstatu replik\u00e1cie. Preto\u017ee sn\u00edmka je len strom ukazovate\u013eov na z\u00e1znamy, vypl\u00fdva z toho, \u017ee ak rob\u00edme zfs send<\/code> sn\u00edmku, posielame tento strom aj v\u0161etky s\u00favisiace z\u00e1znamy. Ke\u010f tento zfs send<\/code> v zfs receive<\/code> posielame na cie\u013eov\u00fd objekt, zapisuje ako skuto\u010dn\u00fd obsah bloku, tak aj strom ukazovate\u013eov odkazuj\u00facich na bloky do cie\u013eov\u00e9ho d\u00e1tov\u00e9ho s\u00faboru.<\/p>\n

V\u0161etko sa st\u00e1va e\u0161te zauj\u00edmavej\u0161\u00edm na druhom zfs send<\/code>. Teraz m\u00e1me dva syst\u00e9my, z ktor\u00fdch ka\u017ed\u00fd obsahuje poolname\/datasetname@1<\/code>, a odober\u00e1te nov\u00fa sn\u00edmku poolname\/datasetname@2<\/code>. Preto vo zdrojovom poole m\u00e1te datasetname@1<\/code> a datasetname@2<\/code>, zatia\u013e \u010do v cie\u013eovom poole je zatia\u013e iba prv\u00e1 sn\u00edmka. datasetname@1<\/code>.<\/p>\n

Ke\u010f\u017ee medzi zdrojom a cie\u013eom m\u00e1me spolo\u010dn\u00fa sn\u00edmku, m\u00f4\u017eeme vykona\u0165 datasetname@1<\/code>inkrement\u00e1lnu nad \u0148ou. Ke\u010f hovor\u00edme syst\u00e9mu<\/i> zfs send<\/code> zfs send -i poolname\/datasetname@1 poolname\/datasetname@2 , porovn\u00e1va dva stromy ukazovate\u013eov. Ak\u00e9ko\u013evek ukazovatele, ktor\u00e9 existuj\u00fa iba v<\/code>, zjavne odkazuj\u00fa na nov\u00e9 bloky \u2013 preto budeme potrebova\u0165 obsah t\u00fdchto blokov. @2<\/code>V vzdialenom syst\u00e9me je spracovanie inkrement\u00e1lneho<\/p>\n

send rovnak\u00e9 jednoduch\u00e9. Najprv zap\u00ed\u0161eme v\u0161etky nov\u00e9 z\u00e1znamy zahrnut\u00e9 v pr\u00fade<\/code> , a potom prid\u00e1vame ukazovatele na tieto bloky. Voil\u00e0, m\u00e1me rovnak\u00e9 jednoduch\u00e9. Najprv zap\u00ed\u0161eme v\u0161etky nov\u00e9 z\u00e1znamy zahrnut\u00e9 v pr\u00fade<\/code>v novom syst\u00e9me! @2<\/code> Asynchr\u00f3nna inkrement\u00e1lna replik\u00e1cia ZFS je obrovsk\u00e9 zlep\u0161enie v porovnan\u00ed s skor\u0161\u00edmi met\u00f3dami, ktor\u00e9 nie s\u00fa zalo\u017een\u00e9 na sn\u00edmkach, ako je rsync. V oboch pr\u00edpadoch sa pren\u00e1\u0161aj\u00fa len zmenen\u00e9 \u00fadaje \u2013 ale rsync mus\u00ed najsk\u00f4r<\/p>\n

pre\u010d\u00edta\u0165 pre\u010d\u00edta\u0165<\/i> z disku v\u0161etky \u00fadaje z oboch str\u00e1n, aby sa skontroloval s\u00fa\u010det a porovnal. Na rozdiel od toho, replik\u00e1cia ZFS ne\u010d\u00edta ni\u010d in\u00e9 ako stromy ukazovate\u013eov \u2013 a ak\u00e9ko\u013evek bloky, ktor\u00e9 nie s\u00fa zast\u00fapen\u00e9 vo v\u0161eobecnom sn\u00edmke.<\/p>\n

Zabudovan\u00e1 kompresia<\/h3>\n

\nMechanizmus kop\u00edrovania pri z\u00e1pise tie\u017e zjednodu\u0161uje syst\u00e9m zabudovanej kompresie. V tradi\u010dnej s\u00faborovej syst\u00e9me je kompresia problematick\u00e1 \u2013 ako star\u00e1 verzia, tak aj nov\u00e1 verzia zmenen\u00fdch \u00fadajov sa nach\u00e1dzaj\u00fa v rovnakom priestore.<\/p>\n

Ak sa pozrieme na fragment \u00fadajov v strede s\u00faboru, ktor\u00fd za\u010d\u00edna svoj \u017eivot ako megabajt n\u00fal od 0x00000000 a tak \u010falej \u2013 ve\u013emi \u013eahko sa d\u00e1 stla\u010di\u0165 do jedn\u00e9ho sektora na disku. Ale \u010do sa stane, ak tento megabajt n\u00fal nahrad\u00edme megabajtom nescompressibiln\u00fdch \u00fadajov, ako JPEG alebo pseudon\u00e1hodn\u00fd \u0161um? Zrazu tento megabajt \u00fadajov bude potrebova\u0165 nie jeden, ale 256 sektorov po 4 KiB, a na tomto mieste na disku je rezervovan\u00fd iba jeden sektor.<\/p>\n

ZFS nem\u00e1 tento probl\u00e9m, preto\u017ee zmenen\u00e9 z\u00e1znamy s\u00fa v\u017edy zapisovan\u00e9 do nevyu\u017eit\u00e9ho priestoru \u2013 p\u00f4vodn\u00fd blok zaber\u00e1 iba jeden sektor 4 KiB, a nov\u00fd z\u00e1znam zaberie 256, ale to nie je probl\u00e9m \u2013 ned\u00e1vno zmenen\u00fd fragment zo \"stredu\" s\u00faboru by bol zap\u00edsan\u00fd do nevyu\u017eit\u00e9ho priestoru bez oh\u013eadu na to, \u010di sa jeho ve\u013ekos\u0165 zmenila alebo nie, tak\u017ee pre ZFS je to celkom be\u017en\u00e1 situ\u00e1cia.<\/p>\n

Zabudovan\u00e1 kompresia ZFS je predvolene vypnut\u00e1, a syst\u00e9m pon\u00faka pripojite\u013en\u00e9 algoritmy \u2013 medzi nimi LZ4, gzip (1-9), LZJB a ZLE.<\/p>\n

Ak je s\u00fabor dostato\u010dne ve\u013ek\u00fd a vy\u017eaduje nieko\u013eko blokov, v\u0161etky z\u00e1znamy s t\u00fdmto s\u00faborom bud\u00fa ma\u0165 ve\u013ekos\u0165 recordsize<\/code>\u00a0\u2013 vr\u00e1tane posledn\u00e9ho z\u00e1znamu, jeho\u017e hlavn\u00e1 \u010das\u0165 sa m\u00f4\u017ee uk\u00e1za\u0165 ako nevyu\u017eit\u00fd priestor<\/a><\/noindex>.<\/p>\n