{"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\/ro\/blog\/administrirovanie\/osnovy-zfs-sistema-hraneniya-i-proizvoditelnost","title":{"rendered":"Bazele ZFS: sistem de stocare \u0219i performan\u021b\u0103","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Bazele
\n
\n\u00cen aceast\u0103 prim\u0103var\u0103, am discutat deja despre unele teme introductive, cum ar fi cum s\u0103 verifica\u021bi viteza discurilor dvs.<\/a><\/noindex> \u0219i ce este RAID<\/a><\/noindex>. \u00cen a doua dintre ele, am promis chiar c\u0103 vom continua s\u0103 studiem performan\u021ba diferitelor topologii multi-disc \u00een ZFS. Aceasta este un sistem de fi\u0219iere de nou\u0103 genera\u021bie, care acum este implementat peste tot: de la Apple<\/a><\/noindex> la Ubuntu<\/a><\/noindex>.
\n<\/a><\/noindex>
\nEi bine, ast\u0103zi este ziua perfect\u0103 pentru a ne familiariza cu ZFS, cititori curio\u0219i. Trebuie s\u0103 \u0219ti\u021bi c\u0103, conform estim\u0103rilor modeste ale dezvoltatorului OpenZFS, Matt Arens, \u201eeste \u00eentr-adev\u0103r complicat\u201d.<\/p>\n

Dar \u00eenainte s\u0103 ajungem la cifre - \u0219i vor fi, promit - pentru toate op\u021biunile de configura\u021bie cu opt discuri din ZFS, trebuie s\u0103 discut\u0103m despre cum<\/i> modul \u00een care ZFS stocheaz\u0103 datele pe disc.<\/p>\n

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

\n\"Bazele
\nDiagrama complet\u0103 a pool-ului include trei vdev-uri auxiliare, c\u00e2te unul din fiecare clas\u0103, \u0219i patru pentru RAIDz2<\/i><\/p>\n

\"Bazele
\n\u00cen general, nu exist\u0103 motive pentru a crea un pool din tipuri \u0219i dimensiuni necorespunz\u0103toare de vdev - dar dac\u0103 dori\u021bi, nimic nu v\u0103 opre\u0219te s\u0103 face\u021bi asta.<\/i><\/p>\n

Pentru a \u00een\u021belege cu adev\u0103rat sistemul de fi\u0219iere ZFS, trebuie s\u0103 ne uit\u0103m atent la structura sa efectiv\u0103. \u00cen primul r\u00e2nd, ZFS combin\u0103 nivelurile tradi\u021bionale de gestionare a volumelor \u0219i sistemului de fi\u0219iere. \u00cen al doilea r\u00e2nd, folose\u0219te un mecanism de tranzac\u021bionare cu copiere la scriere. Aceste caracteristici \u00eenseamn\u0103 c\u0103 sistemul este structural foarte diferit de sistemele de fi\u0219iere obi\u0219nuite \u0219i de array-urile RAID. Primul set de blocuri fundamentale pentru \u00een\u021belegere: este pool-ul de stocare (zpool), dispozitivul virtual (vdev) \u0219i dispozitivul real (device).<\/p>\n

zpool<\/h3>\n

\nPool-ul de stocare zpool este cea mai \u00eenalt\u0103 structur\u0103 ZFS. Fiecare pool con\u021bine unul sau mai multe dispozitive virtuale. La r\u00e2ndul s\u0103u, fiecare dintre acestea con\u021bine unul sau mai multe dispozitive reale (device). Pooile virtuale sunt blocuri autonome. Un computer fizic poate con\u021bine dou\u0103 sau mai multe pool-uri separate, dar fiecare este complet independent de celelalte. Pool-urile nu pot \u00eemp\u0103rt\u0103\u0219i dispozitivele virtuale.<\/p>\n

Redundan\u021ba ZFS se afl\u0103 la nivelul dispozitivelor virtuale, nu la nivelul pool-urilor. La nivelul pool-urilor nu exist\u0103 absolut nicio redundan\u021b\u0103 - dac\u0103 un dispozitiv vdev sau un vdev special se pierde, atunci \u00eempreun\u0103 cu el se pierde \u0219i \u00eentregul pool.<\/p>\n

Pool-urile de stocare moderne pot supravie\u021bui pierderii cache-ului sau jurnalului dispozitivului virtual - de\u0219i pot pierde o cantitate mic\u0103 de date murdare dac\u0103 jurnalul vdev se pierde \u00een timpul unei \u00eentreruperi de curent sau a unei defec\u021biuni a sistemului.<\/p>\n

Exist\u0103 o concep\u021bie gre\u0219it\u0103 comun\u0103 c\u0103 \u201ebenzile de date\u201d (stripes) ZFS sunt scrise pe \u00eentregul pool. Acest lucru este fals. Zpool nu este deloc un RAID0 amuzant, mai degrab\u0103 un JBOD<\/a><\/noindex> cu un mecanism complex \u0219i variabil de distribuire.<\/p>\n

\u00cen cea mai mare parte, \u00eenregistr\u0103rile sunt distribuite \u00eentre dispozitivele virtuale disponibile conform spa\u021biului liber disponibil, astfel \u00eenc\u00e2t teoretic toate vor fi completate simultan. \u00cen versiunile mai recente ale ZFS, se ia \u00een considerare utilizarea curent\u0103 (utilizarea) vdev - dac\u0103 un dispozitiv virtual este semnificativ mai \u00eenc\u0103rcat dec\u00e2t altul (de exemplu, din cauza unei sarcini de citire), acesta va fi s\u0103rit temporar pentru scriere, \u00een ciuda faptului c\u0103 are cel mai mare coeficient de spa\u021biu liber.<\/p>\n

Mecanismul de determinare a utiliz\u0103rii, integrat \u00een metodele moderne de distribuire a scrierii ZFS, poate reduce laten\u021ba \u0219i cre\u0219te l\u0103\u021bimea de band\u0103 \u00een perioadele de sarcin\u0103 neobi\u0219nuit de mare - dar aceasta nu este un cec \u00een alb<\/i> pentru a amesteca f\u0103r\u0103 voie HDD-uri lente \u0219i SSD-uri rapide \u00eentr-un singur pool. Un astfel de pool inegal va func\u021biona totu\u0219i la viteza celui mai lent dispozitiv, adic\u0103 de parc\u0103 ar fi compus \u00een \u00eentregime din astfel de dispozitive.<\/p>\n

vdev<\/h3>\n

\nFiecare pool de stocare const\u0103 din unul sau mai multe dispozitive virtuale (virtual device, vdev). La r\u00e2ndul s\u0103u, fiecare vdev include unul sau mai multe dispozitive reale. Cele mai multe dispozitive virtuale sunt utilizate pentru stocarea simpl\u0103 a datelor, dar exist\u0103 c\u00e2teva clase de vdev auxiliare, inclusiv CACHE, LOG \u0219i SPECIAL. Fiecare dintre aceste tipuri de vdev poate avea una dintre cele cinci topologii: dispozitiv unic (single-device), RAIDz1, RAIDz2, RAIDz3 sau oglind\u0103 (mirror).<\/p>\n

RAIDz1, RAIDz2 \u0219i RAIDz3 sunt variante speciale ale ceea ce vechiul a numit RAID cu dubl\u0103 paritate (diagonal\u0103). 1, 2 \u0219i 3 se refer\u0103 la c\u00e2te blocuri de paritate sunt alocate pentru fiecare band\u0103 de date. \u00cen loc de discuri separate pentru asigurarea parit\u0103\u021bii, dispozitivele RAIDz distribuie uniform aceast\u0103 paritate pe discuri. Un RAIDz poate pierde at\u00e2tea discuri c\u00e2te blocuri de paritate are; dac\u0103 pierde \u00eenc\u0103 unul, va ceda \u0219i va duce cu el \u00eentregul pool de stocare.<\/p>\n

\u00cen dispozitivele virtuale mirror (mirror vdev), fiecare bloc este stocat pe fiecare dispozitiv din vdev. De\u0219i cele mai comune sunt oglinzile duble (two-wide), \u00een oglind\u0103 poate fi un num\u0103r arbitrar de dispozitive \u2013 \u00een instal\u0103rile mari, pentru a \u00eembun\u0103t\u0103\u021bi performan\u021ba la citire \u0219i rezisten\u021ba la defecte, sunt adesea folosite oglinzi triple. O oglind\u0103 vdev poate supravie\u021bui oric\u0103rei defec\u021biuni, at\u00e2ta timp c\u00e2t func\u021bioneaz\u0103 cel pu\u021bin un dispozitiv \u00een vdev.<\/p>\n

vdev-urile unice sunt, prin natura lor, periculoase. Un astfel de dispozitiv virtual nu va supravie\u021bui niciunei defec\u021biuni \u2013 iar dac\u0103 este folosit ca stocare sau ca vdev special, defec\u021biunea sa va duce la distrugerea \u00eentregului pool. Fi\u021bi aici foarte, foarte aten\u021bi.<\/p>\n

Dispozitivele virtuale CACHE, LOG \u0219i SPECIAL pot fi create conform oric\u0103rei dintre topologiile enumerate mai sus \u2013 dar aminti\u021bi-v\u0103 c\u0103 pierderea unui dispozitiv virtual SPECIAL \u00eenseamn\u0103 pierderea pool-ului, de aceea se recomand\u0103 cu t\u0103rie o topologie redundant\u0103.<\/p>\n

dispozitiv<\/h3>\n

\nProbabil c\u0103 acesta este cel mai simplu termen de \u00een\u021beles \u00een ZFS \u2013 se refer\u0103 literalmente la un dispozitiv de bloc de acces aleatoriu. Aminti\u021bi-v\u0103 c\u0103 dispozitivele virtuale sunt compuse din dispozitive separate, iar pool-ul este format din dispozitive virtuale.<\/p>\n

Discurile \u2013 magnetice sau cu stare solid\u0103 \u2013 sunt cele mai frecvente dispozitive de bloc folosite ca elemente de baz\u0103 ale vdev-ului. Totu\u0219i, orice dispozitiv cu un descripitor \u00een \/dev este acceptabil \u2013 astfel, pot fi folosite \u00eentregi matrice RAID hardware ca dispozitive separate.<\/p>\n

Un fi\u0219ier raw simplu este unul dintre cele mai importante alternative ale dispozitelor de bloc, din care poate fi construit un vdev. Pool-urile de test fi\u0219iere sparse<\/a><\/noindex>\u00a0sunt o modalitate foarte convenabil\u0103 de a verifica comenzile pool-ului \u0219i a vedea c\u00e2te spa\u021biu este disponibil \u00een pool sau discul virtual din aceast\u0103 topologie.<\/p>\n

\"Bazele
\nPute\u021bi crea un pool de test din fi\u0219iere sparse \u00een c\u00e2teva secunde \u2013 dar nu uita\u021bi s\u0103 \u0219terge\u021bi ulterior tot pool-ul \u0219i componentele sale.<\/i> <\/p>\n

S\u0103 presupunem c\u0103 dori\u021bi s\u0103 configura\u021bi un server cu opt discuri \u0219i inten\u021biona\u021bi s\u0103 folosi\u021bi discuri de 10 TB (~9300 GiB) \u2013 dar nu sunte\u021bi sigur care topologie se potrive\u0219te cel mai bine nevoilor dumneavoastr\u0103. \u00cen exemplul de mai sus, construim un pool de test din fi\u0219iere sparse \u00een c\u00e2teva secunde \u2013 \u0219i acum \u0219tim c\u0103 un vdev RAIDz2 format din opt discuri de 10 TB ofer\u0103 50 TiB de capacitate util\u0103.<\/p>\n

O alt\u0103 clas\u0103 special\u0103 de dispozitive este SPARE (de rezerv\u0103). Dispozitivele hot-swap, spre deosebire de cele obi\u0219nuite, apar\u021bin \u00eentregului pool, nu unui singur dispozitiv virtual. Dac\u0103 un vdev din pool e\u0219ueaz\u0103, iar dispozitivul de rezerv\u0103 este conectat la pool \u0219i disponibil, acesta se va al\u0103tura automat vdev-ului afectat.<\/p>\n

Dup\u0103 ce se conecteaz\u0103 la vdev-ul afectat, dispozitivul de rezerv\u0103 \u00eencepe s\u0103 primeasc\u0103 copii sau reconstruc\u021bii ale datelor care ar trebui s\u0103 fie pe dispozitivul lips\u0103. \u00cen RAID-ul tradi\u021bional, acest lucru se nume\u0219te recuperare (rebuilding), iar \u00een ZFS, 'recuperare a redundan\u021bei' (resilvering).<\/p>\n

Este important de men\u021bionat c\u0103 dispozitivele de rezerv\u0103 nu \u00eenlocuiesc permanent dispozitivele defecte. Acestea sunt doar o \u00eenlocuire temporar\u0103 pentru a reduce timpul \u00een care vdev-ul este degradat. Dup\u0103 ce administratorul \u00eenlocuie\u0219te dispozitivul defect din vdev, are loc recuperarea redundan\u021bei pentru acest dispozitiv permanent, iar SPARE se deconecteaz\u0103 de la vdev \u0219i revine la func\u021bia de rezerv\u0103 pentru \u00eentregul pool.<\/p>\n

Seturi de date, blocuri \u0219i sectoare<\/h1>\n

\nUrm\u0103torul set de blocuri fundamentale pe care trebuie s\u0103-l \u00een\u021belegem \u00een c\u0103l\u0103toria noastr\u0103 prin ZFS se refer\u0103 mai pu\u021bin la hardware \u0219i mai mult la modul \u00een care sunt organizate \u0219i stocate datele \u00een sine. S\u0103rim peste c\u00e2teva niveluri \u2013 cum ar fi metaslab \u2013 pentru a nu aglomera detalii, p\u0103str\u00e2nd \u00een\u021belegerea structurii generale.<\/p>\n

Set de date (dataset)<\/h3>\n

\n\"Bazele
\nC\u00e2nd cre\u0103m pentru prima dat\u0103 un set de date, acesta arat\u0103 tot spa\u021biul disponibil al pool-ului. Apoi stabilim o cot\u0103 \u2013 \u0219i schimb\u0103m punctul de montare. Magie!<\/i> <\/p>\n

\"Bazele
\nZvol este, \u00een cea mai mare parte, doar un set de date lipsit de stratul s\u0103u de sistem de fi\u0219iere, pe care \u00eel \u00eenlocuim aici cu un sistem de fi\u0219iere normal, ext4.<\/i> <\/p>\n

Setul de date ZFS este aproximativ echivalent cu un sistem de fi\u0219iere montat standard. La prima vedere, acesta arat\u0103 \u201epur \u0219i simplu ca un alt folder\u201d. Dar, asemenea sistemelor de fi\u0219iere montate obi\u0219nuite, fiecare set de date ZFS are propriul s\u0103u set de propriet\u0103\u021bi fundamentale.<\/p>\n

\u00cen primul r\u00e2nd, un set de date poate avea o cot\u0103 alocat\u0103. Dac\u0103 stabilim zfs set quota=100G poolname\/datasetname<\/code>, atunci nu vei putea scrie \u00een folderul montat \/poolname\/datasetname<\/code> cu mai mult de 100 GiB.<\/p>\n

Ai observat prezen\u021ba - \u0219i absen\u021ba - slash-urilor la \u00eenceputul fiec\u0103rei linii? Fiecare set de date are propriul s\u0103u loc at\u00e2t \u00een ierarhia ZFS, c\u00e2t \u0219i \u00een ierarhia mont\u0103rii sistemului. \u00cen ierarhia ZFS nu exist\u0103 slash ini\u021bial - \u00eencepi cu numele pool-ului \u0219i apoi urmezi calea de la un set de date la altul. De exemplu, pool\/parent\/child<\/code> pentru un set de date cu numele child<\/code> sub setul de date p\u0103rinte parent<\/code> \u00eentr-un pool cu un nume creativ pool<\/code>.<\/p>\n

\u00cen mod implicit, punctul de montare al setului de date va fi echivalent cu numele s\u0103u \u00een ierarhia ZFS, cu un slash la \u00eenceput - pool-ul cu numele pool<\/code> se va monta ca \/pool<\/code>, setul de date parent<\/code> se monteaz\u0103 \u00een \/pool\/parent<\/code>, iar setul de date copil child<\/code> se monteaz\u0103 \u00een \/pool\/parent\/child<\/code>. Totu\u0219i, punctul de montare al setului de date \u00een sistem poate fi schimbat.<\/p>\n

Dac\u0103 specific\u0103m zfs set mountpoint=\/lol pool\/parent\/child<\/code>, atunci setul de date pool\/parent\/child<\/code> se va monta \u00een sistem ca \/lol<\/code>.<\/p>\n

\u00cen plus fa\u021b\u0103 de seturile de date, trebuie s\u0103 men\u021bion\u0103m volumele (zvols). O volumul este aproximativ echivalent cu un set de date, cu excep\u021bia faptului c\u0103 nu are de fapt un sistem de fi\u0219iere - este pur \u0219i simplu un dispozitiv bloc. Po\u021bi, de exemplu, s\u0103 creezi zvol<\/code> cu numele mypool\/myzvol<\/code>, apoi s\u0103-l formatezi cu un sistem de fi\u0219iere ext4 \u0219i s\u0103 montezi acest sistem de fi\u0219iere - acum ai un sistem de fi\u0219iere ext4, dar cu suport pentru toate func\u021biile de securitate ZFS! Poate p\u0103rea nebun pe un singur computer, dar are mult mai mult sens ca backend la exportarea unui dispozitiv iSCSI.<\/p>\n

Unit\u0103\u021bi<\/h3>\n

\n\"Bazele
\nUn fi\u0219ier este prezentat prin unul sau mai multe blocuri. Fiecare bloc este stocat pe un singur dispozitiv virtual. Dimensinea blocului este de obicei echivalent\u0103 cu parametrul recordsize<\/b>, dar poate fi redus\u0103 la 2^ashift<\/b>, dac\u0103 con\u021bine metadate sau un fi\u0219ier mic.<\/i><\/p>\n

\"Bazele
\nNoi chiar nu cu adev\u0103rat<\/b> glumim \u00een leg\u0103tur\u0103 cu daunele enorme de performan\u021b\u0103 dac\u0103 set\u0103m un ashift prea mic.<\/i><\/p>\n

\u00cen pool-ul ZFS, toate datele, inclusiv metadatele, sunt stocate \u00een blocuri. Dimensiunea maxim\u0103 a blocului pentru fiecare set de date este stabilit\u0103 \u00een proprietatea recordsize<\/code> (dimensiunea \u00eenregistr\u0103rii). Dimensiunea \u00eenregistr\u0103rii poate varia, dar aceasta nu va schimba dimensiunea sau loca\u021bia vreunor blocuri care au fost deja scrise \u00een setul de date - ea se aplic\u0103 doar pentru noile blocuri pe m\u0103sur\u0103 ce sunt scrise.<\/p>\n

Dac\u0103 nu este specificat altceva, dimensiunea curent\u0103 a \u00eenregistr\u0103rii este, \u00een mod implicit, 128 KiB. Aceasta este, \u00eentr-un fel, un compromis rezonabil, \u00een care performan\u021ba nu va fi ideal\u0103, dar nici nu va fi groaznic\u0103 \u00een majoritatea cazurilor. Dimensiune \u00eenregistrare<\/code> poate fi setat\u0103 pe orice valoare de la 4K la 1M (cu set\u0103ri suplimentare recordsize<\/code> poate fi setat\u0103 chiar mai mare, dar asta este rar o idee bun\u0103).<\/p>\n

Fiecare bloc face referire la datele unui singur fi\u0219ier - nu po\u021bi \u00eenghesui dou\u0103 fi\u0219iere diferite \u00eentr-un singur bloc. Fiecare fi\u0219ier este compus din unul sau mai multe blocuri, \u00een func\u021bie de dimensiunea sa. Dac\u0103 dimensiunea fi\u0219ierului este mai mic\u0103 dec\u00e2t dimensiunea \u00eenregistr\u0103rii, acesta va fi p\u0103strat \u00eentr-un bloc mai mic - de exemplu, un bloc cu un fi\u0219ier de 2 KiB va ocupa doar un sector de 4 KiB pe disc.<\/p>\n

Volumele zvol nu au proprietatea recordsize<\/code>\u00a0- \u00een loc de aceasta, au o proprietate echivalent\u0103 volblocksize.<\/code>.<\/p>\n

Sectoare<\/h3>\n

\nUltimul, cel mai de baz\u0103 element constructiv este sectorul. Aceasta este cea mai mic\u0103 unitate fizic\u0103 care poate fi scris\u0103 sau citit\u0103 de pe dispozitivul de baz\u0103. De-a lungul a c\u00e2teva decenii, majoritatea discurilor au folosit sectoare de 512 octe\u021bi. \u00cen ultima vreme, majoritatea discurilor sunt configurate cu sectoare de 4 KiB, iar \u00een unele - \u00een special SSD-urile - sectoare de 8 KiB sau chiar mai mari.<\/p>\n

\u00cen sistemul ZFS exist\u0103 o proprietate care permite setarea manual\u0103 a dimensiunii sectorului. Aceast\u0103 proprietate ashift<\/code>. Este oarecum confuz, deoarece ashift este o putere a lui 2. De exemplu, ashift=9<\/code> \u00eenseamn\u0103 dimensiunea sectorului 2^9, sau 512 octe\u021bi.<\/p>\n

ZFS solicit\u0103 sistemului de operare informa\u021bii detaliate despre fiecare dispozitiv de bloc atunci c\u00e2nd este ad\u0103ugat \u00eentr-un nou vdev \u0219i, teoretic, stabile\u0219te automat ashift corespunz\u0103tor pe baza acestor informa\u021bii. Din p\u0103cate, multe discuri mint despre dimensiunea sectorului lor pentru a men\u021bine compatibilitatea cu Windows XP (care nu putea interpreta discurile cu alte dimensiuni ale sectorului).<\/p>\n

Aceasta \u00eenseamn\u0103 c\u0103 administratorul ZFS este puternic sf\u0103tuit s\u0103 cunoasc\u0103 dimensiunea real\u0103 a sectorului dispozitivelor sale \u0219i s\u0103 o seteze manual. ashift<\/code>. Dac\u0103 ashift este setat prea mic, num\u0103rul de opera\u021biuni de citire\/scriere cre\u0219te astronomic. De exemplu, scrierea de 'sectoare' de 512 bi\u021bi \u00eentr-un sector real de 4 KiB necesit\u0103 prima scriere a 'sectorului', apoi citirea sectorului de 4 KiB, modificarea lui cu al doilea 'sector' de 512 bi\u021bi, scrierea lui \u00eenapoi \u00een noul sector de 4 KiB \u0219i a\u0219a mai departe pentru fiecare scriere.<\/p>\n

\u00cen lumea real\u0103, aceast\u0103 penalizare afecteaz\u0103 unit\u0103\u021bile de stocare SSD Samsung EVO, pentru care ar trebui s\u0103 se aplice ashift=13<\/code>, dar aceste SSD mint despre dimensiunea lor a sectorului, iar prin urmare, este setat implicit ashift=9<\/code>. Dac\u0103 un administrator de sistem experimentat nu schimb\u0103 aceast\u0103 setare, atunci acest SSD func\u021bioneaz\u0103 mai lent<\/i> ca un HDD magnetic obi\u0219nuit.<\/p>\n

\u00cen compara\u021bie, pentru o dimensiune prea mare ashift<\/code> nu exist\u0103 practic nicio penalizare. Nu exist\u0103 o reducere real\u0103 a performan\u021bei, iar cre\u0219terea spa\u021biului neutilizat este infinit de mic\u0103 (sau nul\u0103 atunci c\u00e2nd compresia este activat\u0103). Prin urmare, recomand\u0103m cu t\u0103rie chiar \u0219i pentru discurile care folosesc \u00eentr-adev\u0103r sectoare de 512 bi\u021bi s\u0103 stabileasc\u0103 ashift=12<\/code> sau chiar ashift=13<\/code>, pentru a privi cu \u00eencredere \u00een viitor.<\/p>\n

Proprietate ashift<\/code> se stabile\u0219te pentru fiecare dispozitiv virtual vdev, \u0219i nu pentru pool<\/i>, a\u0219a cum cred mul\u021bi pe o idee gre\u0219it\u0103 - \u0219i nu se schimb\u0103 dup\u0103 instalare. Dac\u0103 accidental a\u021bi gre\u0219it ashift<\/code> c\u00e2nd ad\u0103uga\u021bi un nou vdev \u00een pool, a\u021bi contaminat irevocabil acest pool cu un dispozitiv de performan\u021b\u0103 sc\u0103zut\u0103 \u0219i, \u00een general, nu exist\u0103 alt\u0103 op\u021biune dec\u00e2t s\u0103 distruge\u021bi pool-ul \u0219i s\u0103 \u00eencepe\u021bi din nou. Chiar \u0219i eliminarea vdev-ului nu va salva de setarea gre\u0219it\u0103. ashift<\/code>!<\/p>\n

Mecanismul de copiere la scriere<\/h3>\n

\n\"Bazele
\nDac\u0103 un sistem de fi\u0219iere obi\u0219nuit trebuie s\u0103 rescrie datele - modific\u0103 fiecare bloc acolo unde se afl\u0103.<\/i><\/p>\n

\"Bazele
\nSistemul de fi\u0219iere cu copiere la scriere scrie o nou\u0103 versiune a blocului \u0219i apoi deblocheaz\u0103 versiunea veche.<\/i><\/p>\n

\"Bazele
\nAbstract, ignor\u00e2nd pozi\u021bia fizic\u0103 real\u0103 a blocurilor, cometa noastr\u0103 de date se simplific\u0103 la un \u201everme de date\u201d care se deplaseaz\u0103 de la st\u00e2nga la dreapta pe harta spa\u021biului disponibil.<\/i><\/p>\n

\"Bazele
\nAcum putem ob\u021bine o idee clar\u0103 despre cum func\u021bioneaz\u0103 instantaneele copiei la scriere - fiecare bloc poate apar\u021bine mai multor instantanee \u0219i va r\u0103m\u00e2ne p\u00e2n\u0103 c\u00e2nd toate instantanee asociate sunt distruse.<\/i><\/p>\n

Mecanismul copiei la scriere (Copy on Write, CoW) este fundamentele a ceea ce face ZFS un sistem at\u00e2t de uimitor. Conceptul de baz\u0103 este simplu - dac\u0103 ceri unui sistem de fi\u0219iere tradi\u021bional s\u0103 modifice un fi\u0219ier, va face exact ceea ce ai cerut. Dac\u0103 ceri unui sistem de fi\u0219iere cu copiere la scriere s\u0103 fac\u0103 acela\u0219i lucru, va spune \"bine\" - dar \u00ee\u021bi va spune o minciun\u0103.<\/p>\n

\u00cen loc s\u0103 fac\u0103 acest lucru, sistemul de fi\u0219iere cu copiere la scriere scrie o nou\u0103 versiune a blocului modificat \u0219i apoi actualizeaz\u0103 meta-datele fi\u0219ierului pentru a rupe leg\u0103tura cu blocul vechi \u0219i a lega noul bloc pe care tocmai l-ai scris.<\/p>\n

Detasarea blocului vechi \u0219i legarea celui nou se face \u00eentr-o singur\u0103 opera\u021bie, deci nu poate fi \u00eentrerupt\u0103 - dac\u0103 \u00eentrerupi alimentarea dup\u0103 ce acest lucru s-a \u00eent\u00e2mplat, ai o nou\u0103 versiune a fi\u0219ierului, iar dac\u0103 \u00eentrerupi alimentarea mai devreme, ai versiunea veche. \u00cen orice caz, nu vor exista conflicte \u00een sistemul de fi\u0219iere.<\/p>\n

Copierea la scriere \u00een ZFS are loc nu doar la nivelul sistemului de fi\u0219iere, ci \u0219i la nivelul gestion\u0103rii discurilor. Aceasta \u00eenseamn\u0103 c\u0103 ZFS nu este predispus la o bre\u0219\u0103 \u00een scriere (o gaur\u0103 \u00een RAID<\/a><\/noindex>) - fenomenul \u00een care banda a reu\u0219it s\u0103 fie scris\u0103 doar par\u021bial \u00eenainte de defec\u021biune, provoc\u00e2nd deteriorarea array-ului dup\u0103 reboot. Aici banda este scris\u0103 atomic, vdev-ul este \u00eentotdeauna consistent, \u0219i Bob este unchiul t\u0103u<\/a><\/noindex>.<\/p>\n

ZIL: jurnalul inten\u021biilor ZFS<\/h3>\n

\n\"Bazele
\nSistemul ZFS gestioneaz\u0103 scrierile sincrone \u00eentr-un mod special - le salveaz\u0103 temporar, dar imediat \u00een ZIL, \u00eenainte de a le scrie mai t\u00e2rziu \u00een mod permanent \u00eempreun\u0103 cu scrierile asincrone.<\/i><\/p>\n

\"Bazele
\nDe obicei, datele scrise pe ZIL nu mai sunt niciodat\u0103 citite. Dar acest lucru este posibil dup\u0103 o defec\u021biune a sistemului.<\/i><\/p>\n

\"Bazele
\nSLOG, sau dispozitivul LOG secundar, este pur \u0219i simplu un vdev special \u2014 \u0219i de preferin\u021b\u0103 foarte rapid \u2014 unde ZIL poate fi stocat separat de stocarea principal\u0103.<\/i><\/p>\n

\"Bazele
\nDup\u0103 o defec\u021biune, toate datele murdare din ZIL sunt reproduse \u2014 \u00een acest caz, ZIL se afl\u0103 pe SLOG, deci ele sunt reproduce exact de acolo.<\/i><\/p>\n

Exist\u0103 dou\u0103 categorii principale de opera\u021biuni de scriere \u2014 sincrone (sync) \u0219i asincrone (async). Pentru majoritatea sarcinilor de lucru, o mare parte din opera\u021biunile de scriere sunt asincrone \u2014 sistemul de fi\u0219iere permite agregarea acestora \u0219i livrarea lor \u00een pachete, reduc\u00e2nd fragmentarea \u0219i cresc\u00e2nd semnificativ l\u0103\u021bimea de band\u0103.<\/p>\n

Scrierile sincrone sunt complet diferite. C\u00e2nd o aplica\u021bie solicit\u0103 o scriere sincron\u0103, aceasta informeaz\u0103 sistemul de fi\u0219iere: \u201eTrebuie s\u0103 fixezi asta \u00een memoria non-volatil\u0103, chiar acum<\/i>iar p\u00e2n\u0103 atunci nu pot face nimic altceva\u201d. Prin urmare, scrierile sincrone trebuie s\u0103 fie fixate imediat pe disc \u2014 \u0219i dac\u0103 acest lucru cre\u0219te fragmentarea sau reduce l\u0103\u021bimea de band\u0103, a\u0219a s\u0103 fie.<\/p>\n

ZFS trateaz\u0103 scrierile sincrone diferit de sistemele de fi\u0219iere obi\u0219nuite \u2014 \u00een loc s\u0103 le scrie imediat \u00een stocarea standard, ZFS le fixeaz\u0103 \u00eentr-o zon\u0103 special\u0103 de stocare numit\u0103 jurnalul inten\u021biilor ZFS \u2014 ZFS Intent Log sau ZIL. Trucul este c\u0103 aceste scrieri de asemenea<\/i> r\u0103m\u00e2n \u00een memorie, fiind aglomerate \u00eempreun\u0103 cu cererile de scriere asincrone obi\u0219nuite, pentru a fi mai t\u00e2rziu scrise \u00een stocare ca ni\u0219te TXG (grupuri de tranzac\u021bii, Transaction Groups) complet normale.<\/p>\n

\u00cen modul normal de func\u021bionare, ZIL este scris \u0219i niciodat\u0103 citit din nou. C\u00e2nd, dup\u0103 c\u00e2teva momente, scrierile din ZIL sunt fixate \u00een stocarea principal\u0103 ca TXG-uri standard din RAM, ele se deconecteaz\u0103 de la ZIL. Singurul moment c\u00e2nd ceva este citit din ZIL este la importul unui pool.<\/p>\n

Dac\u0103 se \u00eent\u00e2mpl\u0103 o defec\u021biune a ZFS \u2014 o defec\u021biune a sistemului de operare sau o \u00eentrerupere a aliment\u0103rii \u2014 c\u00e2nd exist\u0103 date \u00een ZIL, aceste date vor fi citite \u00een timpul urm\u0103torului import al pool-ului (de exemplu, la repornirea sistemului de recuperare). Tot ce se afl\u0103 \u00een ZIL va fi citit, combinat \u00een grupuri TXG, fixat \u00een stocarea principal\u0103, \u0219i apoi deconectat de la ZIL \u00een timpul procesului de import.<\/p>\n

O clas\u0103 auxiliar\u0103 a vdev-ului se nume\u0219te LOG sau SLOG, un dispozitiv secundar LOG. Are un singur scop \u2014 s\u0103 ofere unui pool un dispozitiv vdev separat \u0219i, de preferin\u021b\u0103, mult mai rapid, cu o rezisten\u021b\u0103 foarte mare la scriere, pentru stocarea ZIL-ului, \u00een loc s\u0103 stocheze ZIL-ul pe principalul stocare vdev. \u00censu\u0219i ZIL-ul se comport\u0103 la fel, indiferent de locul de stocare, dar dac\u0103 vdev-ul cu LOG are o performan\u021b\u0103 foarte mare la scriere, atunci scrierile sincronizate vor avea loc mai rapid.<\/p>\n

Ad\u0103ugarea vdev-ului cu LOG \u00een pool nu va nu poate<\/b> \u00eembun\u0103t\u0103\u021bi performan\u021ba scrierilor asincrone \u2014 chiar dac\u0103 for\u021bezi toate scrierile \u00een ZIL cu zfs set sync=always<\/code>, ele vor fi \u00een continuare legate la stocarea principal\u0103 \u00een TXG \u00een acela\u0219i mod \u0219i cu aceea\u0219i vitez\u0103 ca \u0219i f\u0103r\u0103 jurnal. Singura \u00eembun\u0103t\u0103\u021bire direct\u0103 a performan\u021bei este \u00eent\u00e2rzierea scrierii sincronizate (deoarece o vitez\u0103 mai mare a jurnalului accelereaz\u0103 execu\u021bia opera\u021biunilor. sync<\/code>).<\/p>\n

Cu toate acestea, \u00eentr-un mediu care necesit\u0103 deja un num\u0103r mare de scrieri sincronizate, vdev LOG poate accelera indirect scrierea asincron\u0103 \u0219i citirea necache-uit\u0103. Desc\u0103rcarea scrierilor ZIL \u00eentr-un vdev LOG separat \u00eenseamn\u0103 o concuren\u021b\u0103 mai mic\u0103 pentru IOPS \u00een stocarea primar\u0103, ceea ce, \u00eentr-o oarecare m\u0103sur\u0103, \u00eembun\u0103t\u0103\u021be\u0219te performan\u021ba tuturor opera\u021biunilor de citire \u0219i scriere.<\/p>\n

Snapshot-uri<\/h3>\n

\nMecanismul de copiere la scriere este, de asemenea, o baz\u0103 necesar\u0103 pentru instantaneele atomice ZFS \u0219i replicarea asincron\u0103 incremental\u0103. \u00centr-un sistem de fi\u0219iere activ exist\u0103 un arbore de pointeri, care marcheaz\u0103 toate \u00eenregistr\u0103rile cu date curente \u2014 c\u00e2nd faci un snapshot, pur \u0219i simplu faci o copie a acestui arbore de pointeri.<\/p>\n

C\u00e2nd o \u00eenregistrare este rescris\u0103 \u00een sistemul de fi\u0219iere activ, ZFS scrie mai \u00eent\u00e2i o versiune nou\u0103 a blocului \u00een spa\u021biul nefolosit. Apoi, deconecteaz\u0103 versiunea veche a blocului de sistemul de fi\u0219iere curent. Dar dac\u0103 un snapshot se refer\u0103 la blocul vechi, el r\u0103m\u00e2ne neschimbat. Blocul vechi nu va fi de fapt recuperat ca spa\u021biu liber p\u00e2n\u0103 c\u00e2nd toate snapshot-urile care se refer\u0103 la acest bloc nu vor fi distruse!<\/p>\n

Replicare<\/h3>\n

\n\"Bazele
\nBiblioteca mea Steam \u00een 2015 ocupa 158 GiB \u0219i includea 126,927 de fi\u0219iere. Aceasta este destul de aproape de situa\u021bia optim\u0103 pentru rsync \u2014 replicarea ZFS prin re\u021bea a fost \u201edoar\u201d cu 750% mai rapid\u0103.<\/i><\/p>\n

\"Bazele
\n\u00cen aceea\u0219i re\u021bea, replicarea unui fi\u0219ier de 40 gigabi\u021bi al unei imagini a ma\u0219inii virtuale Windows 7 este o cu totul alt\u0103 poveste. Replicarea ZFS se desf\u0103\u0219oar\u0103 de 289 de ori mai repede dec\u00e2t rsync, sau \u201edoar\u201d de 161 de ori mai repede, dac\u0103 e\u0219ti suficient de bine preg\u0103tit pentru a apela rsync cu op\u021biunea \u2014inplace.<\/i><\/p>\n

\"Bazele
\nAtunci c\u00e2nd imaginea ma\u0219inii virtuale este scalat\u0103, problemele rsync se scalaz\u0103 \u00eempreun\u0103 cu ea. Dimensiunea de 1,9 TiB nu este at\u00e2t de mare pentru o imagine modern\u0103 a ma\u0219inii virtuale, dar este suficient de mare pentru ca replicarea ZFS s\u0103 fie de 1148 de ori mai rapid\u0103 dec\u00e2t rsync, chiar \u0219i cu argumentul rsync \u2014inplace.<\/i><\/p>\n

Odat\u0103 ce \u00een\u021belege\u021bi cum func\u021bioneaz\u0103 instantaneele, va fi simplu s\u0103 prindem esen\u021ba replic\u0103rii. Deoarece o instantanee este pur \u0219i simplu un arbore de pointere c\u0103tre \u00eenregistr\u0103ri, urmeaz\u0103 c\u0103, dac\u0103 facem zfs send<\/code> o instantanee, trimitem at\u00e2t acest arbore, c\u00e2t \u0219i toate \u00eenregistr\u0103rile asociate. C\u00e2nd trimitem acest zfs send<\/code> \u00een zfs receive<\/code> la obiectul \u021bint\u0103, acesta \u00eenregistreaz\u0103 at\u00e2t con\u021binutul efectiv al blocului, c\u00e2t \u0219i arborele de pointere care face referire la blocuri, \u00een setul de date \u021bint\u0103.<\/p>\n

Totul devine \u0219i mai interesant \u00een zfs send<\/code>. Acum avem dou\u0103 sisteme, fiecare con\u021bin\u00e2nd poolname\/datasetname@1<\/code>, iar dumneavoastr\u0103 face\u021bi o nou\u0103 instantanee poolname\/datasetname@2<\/code>. Prin urmare, \u00een pool-ul ini\u021bial ave\u021bi datasetname@1<\/code> \u0219i datasetname@2<\/code>, iar \u00een pool-ul \u021bint\u0103, deocamdat\u0103, doar prima instantanee. datasetname@1<\/code>.<\/p>\n

Deoarece \u00eentre surs\u0103 \u0219i destina\u021bie avem o instantanee comun\u0103, datasetname@1<\/code>putem face incremental\u0103<\/i> zfs send<\/code> peste ea. C\u00e2nd spunem sistemului zfs send -i poolname\/datasetname@1 poolname\/datasetname@2<\/code>, acesta compar\u0103 cele dou\u0103 arbori de pointere. Orice pointere care exist\u0103 doar \u00een @2<\/code>, evident, fac referire la blocuri noi \u2014 astfel \u00eenc\u00e2t vom avea nevoie de con\u021binutul acestor blocuri.<\/p>\n

\u00cen sistemul \u00eendep\u0103rtat, procesarea incremental\u0103 send<\/code> este la fel de simpl\u0103. Mai \u00eent\u00e2i, \u00eenregistr\u0103m toate \u00eenregistr\u0103rile noi incluse \u00een flux, send<\/code>apoi ad\u0103ug\u0103m pointere la aceste blocuri. Voil\u00e0, avem @2<\/code> \u00een noul sistem!<\/p>\n

Replicarea incremental\u0103 ZFS asincron\u0103 reprezint\u0103 o \u00eembun\u0103t\u0103\u021bire considerabil\u0103 fa\u021b\u0103 de metodele anterioare, care nu se bazau pe instantanee, cum ar fi rsync. \u00cen ambele cazuri, sunt transmise doar datele modificate \u2014 dar rsync trebuie mai \u00eent\u00e2i citi<\/i> s\u0103 citeasc\u0103 toate datele de pe ambele p\u0103r\u021bi de pe disc, pentru a verifica suma \u0219i a o compara. Spre deosebire de aceasta, replicarea ZFS nu cite\u0219te nimic \u00een afar\u0103 de arborii de pointere \u2014 \u0219i orice blocuri care nu sunt reprezente \u00een instantaneul comun.<\/p>\n

Compresie \u00eencorporat\u0103<\/h3>\n

\nMecanismul de copiere la scriere simplific\u0103, de asemenea, sistemul de compresie \u00eencorporat\u0103. \u00centr-un sistem de fi\u0219iere tradi\u021bional, compresia este problematic\u0103 - at\u00e2t versiunea veche, c\u00e2t \u0219i cea nou\u0103 a datelor modificate se afl\u0103 \u00een acela\u0219i spa\u021biu.<\/p>\n

Dac\u0103 analiz\u0103m un fragment de date din mijlocul unui fi\u0219ier, care \u00ee\u0219i \u00eencepe via\u021ba ca un megabyte de zerouri de la 0x00000000 \u0219i a\u0219a mai departe - este foarte u\u0219or de comprimat la un singur sector pe disk. Dar ce se va \u00eent\u00e2mpla dac\u0103 \u00eenlocuim acest megabyte de zerouri cu un megabyte de date necomprimate, cum ar fi JPEG sau zgomot pseudo-aleatoriu? Dintr-o dat\u0103, acest megabyte de date va necesita nu unul, ci 256 de sectoare de 4 KiB, iar \u00een acest loc pe disk a fost rezervat doar un singur sector.<\/p>\n

ZFS nu are aceast\u0103 problem\u0103, deoarece \u00eenregistr\u0103rile modificate sunt \u00eentotdeauna scrise \u00een spa\u021biul neutilizat - blocul original ocup\u0103 un singur sector de 4 KiB, iar noua \u00eenregistrare va ocupa 256, dar aceasta nu este o problem\u0103 - fragmentul recent modificat din \"mijlocul\" fi\u0219ierului ar fi fost scris \u00een spa\u021biul neutilizat, indiferent dac\u0103 dimensiunea sa s-a schimbat sau nu, a\u0219a c\u0103 pentru ZFS este o situa\u021bie normal\u0103.<\/p>\n

Compresia \u00eencorporat\u0103 ZFS este dezactivat\u0103 implicit, iar sistemul ofer\u0103 algoritmi op\u021bionali - printre ace\u0219tia se num\u0103r\u0103 LZ4, gzip (1-9), LZJB \u0219i ZLE.<\/p>\n

Dac\u0103 fi\u0219ierul este suficient de mare \u0219i necesit\u0103 mai multe blocuri, atunci toate \u00eenregistr\u0103rile cu acest fi\u0219ier vor avea dimensiunea recordsize<\/code>\u00a0- inclusiv ultima \u00eenregistrare, a c\u0103rei parte principal\u0103 poate fi spa\u021biu neutilizat.<\/a><\/noindex>.<\/p>\n