{"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\/sq\/blog\/administrirovanie\/osnovy-zfs-sistema-hraneniya-i-proizvoditelnost","title":{"rendered":"Themelor ZFS: sistemi i ruajtjes dhe performanca","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Themelor
\n
\nK\u00ebt\u00eb pranver\u00eb ne kemi diskutuar disa tema hyr\u00ebse, si\u00e7 jan\u00eb si t\u00eb verifikoni shpejt\u00ebsin\u00eb e disk\u00ebve tuaj<\/a><\/noindex> dhe \u00e7far\u00eb \u00ebsht\u00eb RAID<\/a><\/noindex>. N\u00eb t\u00eb dyt\u00ebn ne madje premtuam t\u00eb vazhdojm\u00eb studimin e performanc\u00ebs s\u00eb topologjive t\u00eb ndryshme me shum\u00eb disqe n\u00eb ZFS. Kjo \u00ebsht\u00eb nj\u00eb sistem skedari t\u00eb gjenerat\u00ebs s\u00eb ardhshme, i cili po implementohet kudo: nga Apple<\/a><\/noindex> deri te Ubuntu<\/a><\/noindex>.
\n<\/a><\/noindex>
\nAjo q\u00eb \u00ebsht\u00eb, sot \u00ebsht\u00eb dita m\u00eb e p\u00ebrshtatshme p\u00ebr t\u00eb njohur me ZFS, lexues t\u00eb kuresh\u00ebm. Thjesht dijeni se, sipas vler\u00ebsimeve modeste nga zhvilluesi i OpenZFS, Matt Arent, \"\u00ebsht\u00eb v\u00ebrtet\u00eb e v\u00ebshtir\u00eb\".<\/p>\n

Por para se t\u00eb arrijm\u00eb te numrat - dhe ata do t\u00eb jen\u00eb, premtoj - p\u00ebr t\u00eb gjitha variantet e konfigurimit t\u00eb tet\u00eb disqeve ZFS, duhet t\u00eb flasim p\u00ebr at\u00eb si<\/i> si ZFS ruan t\u00eb dh\u00ebnat n\u00eb disk.<\/p>\n

Zpool, vdev dhe pajisja<\/h1>\n

\n\"Themelor
\nKy kjo diagram\u00eb e plot\u00eb p\u00ebrfshin tre vdev-e ndihm\u00ebse, nga nj\u00eb p\u00ebr \u00e7do klas\u00eb, dhe kat\u00ebr p\u00ebr RAIDz2.<\/i><\/p>\n

\"Themelor
\nZakonisht nuk ka arsye p\u00ebr t\u00eb krijuar nj\u00eb pool nga tipe dhe madh\u00ebsi t\u00eb ndryshme t\u00eb vdev - por n\u00ebse d\u00ebshironi, asgj\u00eb nuk ju ndalon ta b\u00ebni k\u00ebt\u00eb.<\/i><\/p>\n

P\u00ebr t\u00eb kuptuar v\u00ebrtet\u00ebsisht sistemin e skedar\u00ebve ZFS, duhen shqyrtuar me kujdes strukturat e tij reale. S\u00eb pari, ZFS kombinon nivelet tradicionale t\u00eb menaxhimit t\u00eb v\u00ebllimeve dhe sistemit t\u00eb skedar\u00ebve. S\u00eb dyti, ajo p\u00ebrdor nj\u00eb mekaniz\u00ebm transaksional t\u00eb kopjimit gjat\u00eb shkruarjes. K\u00ebto karakteristika tregojn\u00eb se sistemi \u00ebsht\u00eb strukturalisht shum\u00eb i ndrysh\u00ebm nga sistemet e zakonshme t\u00eb skedar\u00ebve dhe RAID. Grupi i par\u00eb i blloqeve themelore p\u00ebr t\u00eb kuptuar \u00ebsht\u00eb: kjo \u00ebsht\u00eb baza e ruajtjes (zpool), pajisja virtuale (vdev) dhe pajisja reale (device).<\/p>\n

zpool<\/h3>\n

\nGrupi i ruajtjes zpool \u00ebsht\u00eb struktura m\u00eb e lart\u00eb e ZFS. \u00c7do grup p\u00ebrmban nj\u00eb ose m\u00eb shum\u00eb pajisje virtuale. Nga ana tjet\u00ebr, secila prej tyre p\u00ebrmban nj\u00eb ose m\u00eb shum\u00eb pajisje reale (device). Pajisjet virtuale jan\u00eb blloqe autonome. Nj\u00eb kompjuter fizik mund t\u00eb ket\u00eb dy ose m\u00eb shum\u00eb grupe t\u00eb ndara, por secili \u00ebsht\u00eb plot\u00ebsisht i pavarur nga t\u00eb tjer\u00ebt. Grupe nuk mund t\u00eb ndajn\u00eb pajisje virtuale.<\/p>\n

Tezja e ZFS ndodhet n\u00eb nivelin e pajisjeve virtuale, dhe jo n\u00eb nivelin e pishinave. N\u00eb nivelin e pishinave nuk ka asnj\u00eb lloj teje \u2014 n\u00ebse humbet ndonj\u00eb pajisje vdev ose nj\u00eb vdev i ve\u00e7ant\u00eb, at\u00ebher\u00eb humbet gjithashtu dhe gjith\u00eb pishina.<\/p>\n

Pishinat moderne t\u00eb ruajtjes mund t\u00eb p\u00ebrballojn\u00eb humbjen e caches ose regjistrit t\u00eb pajisjes virtuale \u2014 megjithat\u00eb, ata mund t\u00eb humbasin nj\u00eb sasi t\u00eb vog\u00ebl t\u00eb t\u00eb dh\u00ebnave t\u00eb papastruara n\u00ebse humbin regjistrin e vdev gjat\u00eb nd\u00ebrprerjes s\u00eb energjis\u00eb ose d\u00ebshtimit t\u00eb sistemit.<\/p>\n

Ka nj\u00eb keqkuptim t\u00eb zakonsh\u00ebm se \"bandat e t\u00eb dh\u00ebnave\" (stripes) n\u00eb ZFS shkruhen p\u00ebrmes t\u00eb gjith\u00eb pishin\u00ebs. Kjo \u00ebsht\u00eb e pav\u00ebrtet\u00eb. Zpool nuk \u00ebsht\u00eb aspak nj\u00eb RAID0 arg\u00ebllues, \u00ebsht\u00eb m\u00eb shum\u00eb nj\u00eb arg\u00ebllues JBOD<\/a><\/noindex> me nj\u00eb mekaniz\u00ebm kompleks t\u00eb ndarjes s\u00eb ndryshueshme.<\/p>\n

Pjes\u00ebt shp\u00ebrndahen kryesisht mes pajisjeve virtuale t\u00eb disponueshme n\u00eb baz\u00eb t\u00eb hap\u00ebsir\u00ebs s\u00eb lir\u00eb t\u00eb disponueshme, k\u00ebshtu q\u00eb teorikisht t\u00eb gjitha ato do t\u00eb mbushen nj\u00ebher\u00ebsh. N\u00eb versionet e m\u00ebvonshme t\u00eb ZFS, merret parasysh p\u00ebrdorimi aktual (shfryt\u00ebzimi) i vdev - n\u00ebse nj\u00eb pajisje virtuale \u00ebsht\u00eb shum\u00eb m\u00eb e ngarkuar se tjetra (p.sh., p\u00ebr shkak t\u00eb ngarkes\u00ebs s\u00eb leximit), do ta anashkalojn\u00eb p\u00ebr p\u00ebrpunim t\u00eb shkrimit p\u00ebrkoh\u00ebsisht, pavar\u00ebsisht ngaCoefficienti m\u00eb i lart\u00eb i hap\u00ebsir\u00ebs s\u00eb lir\u00eb.<\/p>\n

Mekanizmi i vler\u00ebsimit t\u00eb shfryt\u00ebzimit, i integruar n\u00eb metodat moderne t\u00eb shp\u00ebrndarjes s\u00eb shkrimit t\u00eb ZFS, mund t\u00eb zvog\u00ebloj\u00eb vonesat dhe t\u00eb rris\u00eb kapacitetin gjat\u00eb periudhave t\u00eb ngarkes\u00ebs jasht\u00ebzakonisht t\u00eb lart\u00eb - por kjo nuk \u00ebsht\u00eb kart-blan<\/i> p\u00ebr kombinimin e pad\u00ebshiruar t\u00eb HDD-ve t\u00eb ngadalta dhe SSD-ve t\u00eb shpejta n\u00eb nj\u00eb grup. Nj\u00eb grup i till\u00eb disavantazhi do t\u00eb funksionoj\u00eb prap\u00eb me shpejt\u00ebsin\u00eb e pajisjes m\u00eb t\u00eb ngadaljt\u00eb, si\u00e7 do t\u00eb ishte si t\u00eb ishte t\u00ebr\u00ebsisht i p\u00ebrb\u00ebr\u00eb nga ato pajisje.<\/p>\n

vdev<\/h3>\n

\n\u00c7do pool ruajtjeje p\u00ebrb\u00ebhet nga nj\u00eb ose m\u00eb shum\u00eb pajisje virtuale (virtual device, vdev). Nga ana tjet\u00ebr, \u00e7do vdev p\u00ebrfshin nj\u00eb ose m\u00eb shum\u00eb pajisje reale. Shumica e pajisjeve virtuale p\u00ebrdoren p\u00ebr ruajtje t\u00eb thjesht\u00eb t\u00eb t\u00eb dh\u00ebnave, por ekzistojn\u00eb disa klasa ndihm\u00ebse vdev, duke p\u00ebrfshir\u00eb CACHE, LOG dhe SPECIAL. \u00c7do nga k\u00ebto tipe vdev mund t\u00eb ket\u00eb nj\u00eb nga pes\u00eb topologjit\u00eb: pajisje t\u00eb vetme (single-device), RAIDz1, RAIDz2, RAIDz3 ose pasqyr\u00eb (mirror).<\/p>\n

RAIDz1, RAIDz2 dhe RAIDz3 jan\u00eb variante t\u00eb ve\u00e7anta t\u00eb asaj q\u00eb 'oldies' do ta quanin RAID me dy (diagonale) paritet. 1, 2 dhe 3 i referohen numrit t\u00eb bllokove t\u00eb paritetit t\u00eb caktuar p\u00ebr \u00e7do band\u00eb t\u00eb dh\u00ebnash. N\u00eb vend t\u00eb disk\u00ebve t\u00eb ve\u00e7ant\u00eb p\u00ebr sigurimin e paritetit, pajisjet virtuale RAIDz shp\u00ebrndajn\u00eb n\u00eb m\u00ebnyr\u00eb gjysm\u00eb t\u00eb barabart\u00eb k\u00ebt\u00eb paritet n\u00ebp\u00ebr disqe. Nj\u00eb grup RAIDz mund t\u00eb humbas\u00eb aq disqe sa ka bllok\u00eb pariteti; n\u00ebse humbet nj\u00eb tjet\u00ebr, do t\u00eb degradoj\u00eb dhe do t\u00eb marr\u00eb me vete pool-in e ruajtjes.<\/p>\n

N\u00eb pajisjet virtuale t\u00eb pasqyruara (mirror vdev), \u00e7do bllok ruhet n\u00eb \u00e7do pajisje n\u00eb vdev. Megjith\u00ebse pasqyra m\u00eb t\u00eb zakonshme jan\u00eb ato me dy pajisje (two-wide), n\u00eb nj\u00eb pasqyr\u00eb mund t\u00eb ket\u00eb \u00e7do num\u00ebr t\u00eb rast\u00ebsish\u00ebm pajisjesh \u2014 n\u00eb instalime t\u00eb m\u00ebdha, p\u00ebr t\u00eb rritur performanc\u00ebn e leximit dhe q\u00ebndrueshm\u00ebrin\u00eb, shpesh p\u00ebrdoren ato me tre pajisje. Nj\u00eb pasqyr\u00eb vdev mund t\u00eb p\u00ebrballoj\u00eb \u00e7do d\u00ebshtim, p\u00ebrsa koh\u00eb funksionon t\u00eb pakt\u00ebn nj\u00eb pajisje n\u00eb vdev.<\/p>\n

vdev-t\u00eb e vetme, n\u00eb thelb, jan\u00eb t\u00eb rrezikshme. Nj\u00eb pajisje virtuale e till\u00eb nuk do t\u00eb p\u00ebrballoj\u00eb asnj\u00eb d\u00ebshtim \u2014 dhe n\u00ebse p\u00ebrdoret si hap\u00ebsir\u00eb ruajtjeje ose vdev i ve\u00e7ant\u00eb, d\u00ebshtimi i saj do t\u00eb \u00e7oj\u00eb n\u00eb shkat\u00ebrrimin e t\u00eb gjith\u00eb grupit. Kini shum\u00eb, shum\u00eb kujdes k\u00ebtu.<\/p>\n

Pajisjet virtuale CACHE, LOG dhe SPECIAL mund t\u00eb krijohen sipas ndonj\u00eb nga topologjit\u00eb e m\u00ebsip\u00ebrme \u2014 por mbani mend se humbja e nj\u00eb pajisjeje SPECIAL do t\u00eb thot\u00eb humbje t\u00eb grupit, prandaj rekomandohet me ngulm nj\u00eb topologji e tep\u00ebrt.<\/p>\n

pajisje<\/h3>\n

\nProbablemente, kjo \u00ebsht\u00eb termi m\u00eb i thjesht\u00eb p\u00ebr t'u kuptuar n\u00eb ZFS \u2013 \u00ebsht\u00eb dosja e hapur q\u00eb \u00ebsht\u00eb literalisht nj\u00eb nj\u00ebsit t\u00eb dh\u00ebnash t\u00eb aksessit t\u00eb rast\u00ebsish\u00ebm. Mbani mend se pajisjet virtuale p\u00ebrb\u00ebhen nga pajisje t\u00eb ve\u00e7anta, dhe nj\u00eb pishin\u00eb \u00ebsht\u00eb b\u00ebr\u00eb nga pajisje virtuale.<\/p>\n

Disqet \u2013 magnetik\u00eb ose t\u00eb ngurta \u2013 jan\u00eb nj\u00ebsit\u00eb m\u00eb t\u00eb zakonshme q\u00eb p\u00ebrdoren si bllok p\u00ebr vdev. Megjithat\u00eb, p\u00ebr \u00e7do pajisje me nj\u00eb p\u00ebrshkrim n\u00eb \/dev do t\u00eb b\u00ebj\u00eb - k\u00ebshtu q\u00eb gjithashtu mund t\u00eb p\u00ebrdoren t\u00ebr\u00eb grupe RAID p\u00ebr pajisje t\u00eb ve\u00e7anta.<\/p>\n

Nj\u00eb skedar i thjesht\u00eb raw \u00ebsht\u00eb nj\u00eb nga pajisjet m\u00eb t\u00eb r\u00ebnd\u00ebsishme alternative blloku nga t\u00eb cilat mund t\u00eb nd\u00ebrtohet nj\u00eb vdev. Pishinat testuese nga skedare t\u00eb holl\u00eb<\/a><\/noindex>\u00a0jan\u00eb nj\u00eb m\u00ebnyr\u00eb shum\u00eb e dobishme p\u00ebr t\u00eb kontrolluar komandat e pishin\u00ebs dhe p\u00ebr t\u00eb par\u00eb sa hap\u00ebsir\u00eb \u00ebsht\u00eb e disponueshme n\u00eb pishin\u00eb ose pajisjen virtuale t\u00eb k\u00ebsaj topologjie.<\/p>\n

\"Themelor
\nMund t\u00eb krijoni nj\u00eb pishin\u00eb testuese nga skedar\u00eb t\u00eb holl\u00eb p\u00ebr vet\u00ebm disa sekonda \u2013 por mos harroni t\u00eb fshini pastaj t\u00eb gjith\u00eb pishin\u00ebn dhe komponent\u00ebt e saj.<\/i> <\/p>\n

T\u00eb supozojm\u00eb se d\u00ebshironi t\u00eb vendosni nj\u00eb server me tet\u00eb disqe dhe planifikoni t\u00eb p\u00ebrdorni disqe prej 10 TB (~9300 GiB) \u2014 por nuk jeni t\u00eb sigurt se cila topologji \u00ebsht\u00eb m\u00eb e p\u00ebrshtatshme p\u00ebr nevojat tuaja. N\u00eb shembullin e m\u00ebsip\u00ebrm, nd\u00ebrtuam nj\u00eb grup prova nga skedar\u00eb t\u00eb shp\u00ebrndar\u00eb p\u00ebr disa sekonda \u2014 dhe tani e dim\u00eb se RAIDz2 vdev me tet\u00eb disqe prej 10 TB ofron 50 TiB kapacitet t\u00eb dobish\u00ebm.<\/p>\n

Nj\u00eb klas\u00eb tjet\u00ebr e ve\u00e7ant\u00eb e pajisjeve \u00ebsht\u00eb SPARE (rezerv\u00eb). Pajisjet me nd\u00ebrrim t\u00eb nxeht\u00eb, n\u00eb dallim nga pajisjet normale, i p\u00ebrkasin t\u00eb gjith\u00eb grupit dhe jo nj\u00eb pajisjeje virtuale. N\u00ebse ndonj\u00eb vdev n\u00eb grup d\u00ebshton dhe pajisja rezerv\u00eb \u00ebsht\u00eb e lidhur me grupin dhe e disponueshme, ajo do t\u00eb bashkohet automatikisht me vdev-in e d\u00ebmtuar.<\/p>\n

Pasi t\u00eb lidhet me vdev-in e d\u00ebmtuar, pajisja rezerv\u00eb fillon t\u00eb marr\u00eb kopje ose rikonstruksione t\u00eb t\u00eb dh\u00ebnave q\u00eb duhet t\u00eb jen\u00eb n\u00eb pajisjen e munguar. N\u00eb RAID-in tradicional, ky proces quhet rikonstruksion (rebuilding), nd\u00ebrsa n\u00eb ZFS \u00ebsht\u00eb \"rikthimi i tep\u00ebrsiis\u00eb\" (resilvering).<\/p>\n

\u00cbsht\u00eb e r\u00ebnd\u00ebsishme t\u00eb theksohet se pajisjet rezerv\u00eb nuk z\u00ebvend\u00ebsojn\u00eb p\u00ebrfundimisht pajisjet e prishura. Ato jan\u00eb nj\u00eb z\u00ebvend\u00ebsim p\u00ebrkoh\u00ebsor p\u00ebr t\u00eb reduktuar koh\u00ebn e degradimit t\u00eb vdev. Pasi administratorit t'i z\u00ebvend\u00ebsoj\u00eb pajisjen e prishur t\u00eb vdev, ndodhi rikthimi i tep\u00ebrsis\u00eb n\u00eb k\u00ebt\u00eb pajisje t\u00eb p\u00ebrhershme, dhe SPARE shk\u00ebputet nga vdev dhe kthehet n\u00eb pun\u00eb si rezerv\u00eb p\u00ebr t\u00eb gjith\u00eb pool-in.<\/p>\n

Grupet e t\u00eb dh\u00ebnave, blloket dhe sektor\u00ebt<\/h1>\n

\nGrupi i ardhsh\u00ebm i elementeve ndihmon p\u00ebr t\u00eb kuptuar m\u00eb mir\u00eb n\u00eb udh\u00ebtimin ton\u00eb p\u00ebr ZFS, nd\u00ebrlidhet m\u00eb shum\u00eb me m\u00ebnyr\u00ebn se si organizohen dhe ruhen vet\u00eb t\u00eb dh\u00ebnat. Ne k\u00ebtu e anashkalojm\u00eb disa nivele \u2014 si p\u00ebr shembull metaslab \u2014 p\u00ebr t\u00eb mos e mbingarkuar detajin, duke ruajtur kuptimin e struktur\u00ebs s\u00eb p\u00ebrgjithshme.<\/p>\n

Grupi i t\u00eb dh\u00ebnave (dataset)<\/h3>\n

\n\"Themelor
\nKur krijojm\u00eb p\u00ebr her\u00eb t\u00eb par\u00eb nj\u00eb grup t\u00eb dh\u00ebnash, ai tregon gjith\u00eb hap\u00ebsir\u00ebn e disponueshme t\u00eb pool-it. Pastaj ne vendosim nj\u00eb kuot\u00eb \u2014 dhe ndryshojm\u00eb pik\u00ebn e montimit. Magjia!<\/i> <\/p>\n

\"Themelor
\nZvol \u00ebsht\u00eb kryesisht thjesht nj\u00eb grup t\u00eb dh\u00ebnash, i hequr nga shtresa e tij e sistemit t\u00eb skedar\u00ebve, e cila k\u00ebtu z\u00ebvend\u00ebsohet me nj\u00eb sistem faturimi t\u00eb zakonsh\u00ebm si ext4.<\/i> <\/p>\n

Grupi i t\u00eb dh\u00ebnave ZFS \u00ebsht\u00eb n\u00eb p\u00ebrputhje t\u00eb ngjashme me sistemin standard t\u00eb skedar\u00ebve t\u00eb montuar. Si \u00e7do sistem skedar\u00ebsh t\u00eb zakonsh\u00ebm, n\u00eb radh\u00eb t\u00eb par\u00eb duket si \"thjesht nj\u00eb dosje tjet\u00ebr\". Por ashtu si \u00e7do sistem tjet\u00ebr i montuar i skedar\u00ebve, \u00e7do grup t\u00eb dh\u00ebnash ZFS ka grupin e tij t\u00eb ve\u00e7orive elementare.<\/p>\n

S\u00eb pari, grupit t\u00eb t\u00eb dh\u00ebnave mund t'i caktohet nj\u00eb kuot\u00eb. N\u00ebse caktoni zfs set quota=100G poolname\/datasetname<\/code>, at\u00ebher\u00eb nuk do t\u00eb jeni n\u00eb gjendje t\u00eb shkruani n\u00eb dosjen e montuar \/poolname\/datasetname<\/code> m\u00eb shum\u00eb se 100 GiB.<\/p>\n

A e keni v\u00ebn\u00eb re pranin\u00eb \u2014 dhe munges\u00ebn \u2014 e shenjave \/ n\u00eb fillim t\u00eb \u00e7do rreshti? \u00c7do grup t\u00eb dh\u00ebnash ka vendin e tij n\u00eb hierarkin\u00eb ZFS, ashtu si dhe n\u00eb hierarkin\u00eb e montimit t\u00eb sistemit. N\u00eb hierarkin\u00eb ZFS nuk ka shenj\u00eb t\u00eb par\u00eb \u2014 filloni me emrin e puloit dhe pastaj rrug\u00ebn nga nj\u00eb grup t\u00eb dh\u00ebnash n\u00eb tjetrin. P\u00ebr shembull, pool\/parent\/child<\/code> p\u00ebr nj\u00eb grup t\u00eb dh\u00ebnash me emrin child<\/code> n\u00eb grupin e parentit parent<\/code> n\u00eb nj\u00eb pool me emrin krijues pool<\/code>.<\/p>\n

N\u00eb m\u00ebnyr\u00eb standarde, pika e montimit t\u00eb grupit t\u00eb dh\u00ebnash do t\u00eb jet\u00eb e barabart\u00eb me emrin e tij n\u00eb hierarkin\u00eb ZFS, me nj\u00eb slash n\u00eb fillim \u2014 pool me emrin pool<\/code> do t\u00eb montoj\u00eb si \/pool<\/code>, grupi i t\u00eb dh\u00ebnave parent<\/code> do t\u00eb montohet n\u00eb \/pool\/parent<\/code>, dhe grupi i f\u00ebmij\u00ebs child<\/code> do t\u00eb montohet n\u00eb \/pool\/parent\/child<\/code>. Megjithat\u00eb, pika e montimit t\u00eb sistemit p\u00ebr grupin e t\u00eb dh\u00ebnave mund t\u00eb ndryshohet.<\/p>\n

N\u00ebse ne tregojm\u00eb zfs set mountpoint=\/lol pool\/parent\/child<\/code>, at\u00ebher\u00eb grupi i t\u00eb dh\u00ebnave pool\/parent\/child<\/code> do t\u00eb montoj\u00eb n\u00eb sistem si \/lol<\/code>.<\/p>\n

P\u00ebrve\u00e7 grupeve t\u00eb t\u00eb dh\u00ebnave, ne duhet t\u00eb p\u00ebrmendim volumat (zvols). Nj\u00eb volum \u00ebsht\u00eb af\u00ebrsisht ekuivalent me nj\u00eb grup t\u00eb dh\u00ebnash, p\u00ebrve\u00e7 se nuk ka nj\u00eb sistem skedar\u00ebsh \u2014 \u00ebsht\u00eb thjesht nj\u00eb pajisje blloku. P\u00ebr shembull, mund t\u00eb krijoni zvol<\/code> me emrin mypool\/myzvol<\/code>, pastaj ta formatoni me nj\u00eb sistem skedar\u00ebsh ext4, dhe m\u00eb pas ta montoni k\u00ebt\u00eb sistem skedar\u00ebsh \u2014 tani keni nj\u00eb sistem skedar\u00ebsh ext4, por me mb\u00ebshtetje p\u00ebr t\u00eb gjitha funksionet e siguris\u00eb ZFS! Kjo mund t\u00eb duket e \u00e7uditshme n\u00eb nj\u00eb kompjuter, por ka shum\u00eb m\u00eb shum\u00eb kuptim si nj\u00eb backend kur eksportoni nj\u00eb pajisje iSCSI.<\/p>\n

Blloqe<\/h3>\n

\n\"Themelor
\nNj\u00eb skedar p\u00ebrfaq\u00ebsohet nga nj\u00eb ose m\u00eb shum\u00eb blloqe. \u00c7do bllok ruhet n\u00eb nj\u00eb pajisje virtuale. Madh\u00ebsia e bllokut zakonisht \u00ebsht\u00eb e barabart\u00eb me parametrin recordsize<\/b>, por mund t\u00eb zvog\u00eblohet deri n\u00eb 2^ashift<\/b>, n\u00ebse p\u00ebrmban meta t\u00eb dh\u00ebna ose nj\u00eb skedar t\u00eb vog\u00ebl.<\/i><\/p>\n

\"Themelor
\nNe v\u00ebrtet, v\u00ebrtet<\/b> nuk po shaka n\u00eb lidhje me d\u00ebmin e madh n\u00eb performanc\u00eb, n\u00ebse vendosni nj\u00eb ashift shum\u00eb t\u00eb vog\u00ebl.<\/i><\/p>\n

N\u00eb grupin ZFS t\u00eb gjitha t\u00eb dh\u00ebnat, p\u00ebrfshir\u00eb metadat\u00ebn, ruhen n\u00eb blloqe. Madh\u00ebsia maksimale e bllokut p\u00ebr \u00e7do grup t\u00eb dh\u00ebnash p\u00ebrcaktohet n\u00eb pron\u00ebn recordsize<\/code> (madh\u00ebsia e sh\u00ebnimit). Madh\u00ebsia e sh\u00ebnimit mund t\u00eb ndryshoj\u00eb, por kjo nuk do t\u00eb ndryshoj\u00eb madh\u00ebsin\u00eb ose pozicionin e \u00e7do blloku q\u00eb tashm\u00eb \u00ebsht\u00eb shkruar n\u00eb grupin e dh\u00ebnash - vepron vet\u00ebm p\u00ebr blloqet e reja gjat\u00eb shkruarjes s\u00eb tyre.<\/p>\n

N\u00ebse nuk p\u00ebrcaktohet ndryshe, madh\u00ebsia aktuale e sh\u00ebnimit \u00ebsht\u00eb caktuar si 128 KiB. Ky \u00ebsht\u00eb nj\u00eb lloj kompromisi t\u00eb v\u00ebshtir\u00eb, ku performanca nuk do t\u00eb jet\u00eb e p\u00ebrsosur, por as e keqe n\u00eb shumic\u00ebn e rasteve. Madh\u00ebsia e sh\u00ebnimit<\/code> mund t\u00eb vendoset n\u00eb \u00e7do vler\u00eb nga 4K n\u00eb 1M (me cil\u00ebsime shtes\u00eb recordsize<\/code> mund t\u00eb vendoset edhe m\u00eb shum\u00eb, por kjo rrall\u00eb \u00ebsht\u00eb nj\u00eb ide e mir\u00eb).<\/p>\n

\u00c7do bllok i referohet t\u00eb dh\u00ebnave t\u00eb vet\u00ebm nj\u00eb skedari - nuk mund t\u00eb vendosni dy skedar\u00eb t\u00eb ndrysh\u00ebm n\u00eb nj\u00eb bllok. \u00c7do skedar p\u00ebrb\u00ebhet nga nj\u00eb ose m\u00eb shum\u00eb blloqe, n\u00eb var\u00ebsi t\u00eb madh\u00ebsis\u00eb. N\u00ebse madh\u00ebsia e skedarit \u00ebsht\u00eb m\u00eb e vog\u00ebl se madh\u00ebsia e sh\u00ebnimit, ai do t\u00eb ruhet n\u00eb nj\u00eb bllok m\u00eb t\u00eb vog\u00ebl - p\u00ebr shembull, nj\u00eb bllok me nj\u00eb skedari 2 KiB do t\u00eb z\u00eb vet\u00ebm nj\u00eb sektor 4 KiB n\u00eb disk.<\/p>\n

V\u00ebllimet zvol nuk kan\u00eb pron\u00ebsi recordsize<\/code>\u00a0\u2014 n\u00eb vend t\u00eb k\u00ebsaj, ato kan\u00eb nj\u00eb pron\u00ebsi ekuivalente volblocksize<\/code>.<\/p>\n

Sektor\u00eb<\/h3>\n

\nNj\u00ebsi m\u00eb e vog\u00ebl, blloku themelor \u00ebsht\u00eb sektori. Kjo \u00ebsht\u00eb nj\u00ebsia m\u00eb e vog\u00ebl fizike q\u00eb mund t\u00eb shkruhet ose lexohet nga pajisja themelore. Gjat\u00eb disa dekadave, sektoret prej 512 byte kan\u00eb qen\u00eb t\u00eb zakonsh\u00ebm n\u00eb shumic\u00ebn e disk\u00ebve. Koh\u00ebt e fundit, shumica e disk\u00ebve jan\u00eb konfiguruar me sektore 4 KiB, nd\u00ebrsa disa \u2014 ve\u00e7an\u00ebrisht SSD \u2014 kan\u00eb sektore 8 KiB ose edhe m\u00eb shum\u00eb.<\/p>\n

N\u00eb sistemin ZFS, ka nj\u00eb pron\u00ebsi q\u00eb lejon vendosjen manuale t\u00eb madh\u00ebsis\u00eb s\u00eb sektorit. Kjo pron\u00ebsi ashift<\/code>. \u00cbsht\u00eb pak e ngat\u00ebrruar q\u00eb ashift \u00ebsht\u00eb nj\u00eb fuqi e dytes. P\u00ebr shembull, ashift=9<\/code> n\u00eb at\u00eb rast do t\u00eb thot\u00eb madh\u00ebsia e sektorit 2^9, ose 512 byte.<\/p>\n

ZFS k\u00ebrkon informacion t\u00eb detajuar nga sistemi operativ p\u00ebr \u00e7do pajisje bllokuese kur ajo shtohet n\u00eb nj\u00eb vdev t\u00eb ri, dhe teorikisht vendos automatikisht ashiftin si\u00e7 \u00ebsht\u00eb e duhur n\u00eb baz\u00eb t\u00eb k\u00ebtij informacioni. Fatkeq\u00ebsisht, shum\u00eb disqe g\u00ebnjejn\u00eb p\u00ebr madh\u00ebsin\u00eb e tyre t\u00eb sektorit p\u00ebr t\u00eb ruajtur pajtueshm\u00ebrin\u00eb me Windows XP (i cili nuk ishte n\u00eb gjendje t\u00eb kuptonte disk\u00ebt me madh\u00ebsi t\u00eb ndryshme sektori).<\/p>\n

Kjo do t\u00eb thot\u00eb se administratori i ZFS rekomandohet me ngulm t\u00eb di madh\u00ebsin\u00eb e v\u00ebrtet\u00eb t\u00eb sektor\u00ebve t\u00eb pajisjeve t\u00eb tij dhe t\u00eb vendos\u00eb manualisht ashift<\/code>. N\u00ebse vendoset nj\u00eb ashift shum\u00eb i vog\u00ebl, do t\u00eb rritet astronomikisht numri i operacioneve t\u00eb leximit\/shkrimit. K\u00ebshtu, shkrimi i \u00absektor\u00ebve\u00bb 512-bytes n\u00eb nj\u00eb sektor t\u00eb v\u00ebrtet\u00eb 4 KiB do t\u00eb thot\u00eb nevoj\u00ebn p\u00ebr t\u00eb shkruar \u00absektorin\u00bb e par\u00eb, pastaj t\u00eb lexosh sektorin 4 KiB, ta ndryshosh at\u00eb me \u00absektorin\u00bb e dyt\u00eb 512-bytes, ta shkruash at\u00eb p\u00ebrs\u00ebri n\u00eb sektorin e ri 4 KiB dhe k\u00ebshtu me radh\u00eb p\u00ebr \u00e7do shkrim.<\/p>\n

N\u00eb bot\u00ebn reale, nj\u00eb d\u00ebnim i till\u00eb godet disqet e ngurta Samsung EVO, p\u00ebr t\u00eb cilat duhet t\u00eb mbaj\u00eb ashift=13<\/code>, por k\u00ebta SSD g\u00ebnjejn\u00eb p\u00ebr madh\u00ebsin\u00eb e tyre t\u00eb sektorit, dhe p\u00ebr k\u00ebt\u00eb arsye caktimi \u00ebsht\u00eb b\u00ebr\u00eb n\u00eb parazgjedhje ashift=9<\/code>. N\u00ebse nj\u00eb administrator i sistemit me p\u00ebrvoj\u00eb nuk e ndryshon k\u00ebt\u00eb paramet\u00ebr, at\u00ebher\u00eb ky SSD funksionon m\u00eb ngadal\u00eb<\/i> se nj\u00eb HDD t\u00eb zakonsh\u00ebm.<\/p>\n

P\u00ebr krahasim, p\u00ebr nj\u00eb madh\u00ebsi t\u00eb tep\u00ebrt ashift<\/code> nuk ka praktikisht asnj\u00eb gjob\u00eb. Nuk ka ulje t\u00eb v\u00ebrtet\u00eb t\u00eb performanc\u00ebs, dhe rritja e hap\u00ebsir\u00ebs s\u00eb pavendosur \u00ebsht\u00eb p\u00ebr t\u00eb gjith\u00eb praktisht minimale (ose e barabart\u00eb me zero n\u00ebse kompresimi \u00ebsht\u00eb aktiv). Prandaj, rekomandojm\u00eb me ngulm q\u00eb edhe disqe q\u00eb v\u00ebrtet p\u00ebrdorin sektora prej 512 bytes t\u00eb vendosin ashift=12<\/code> ose madje ashift=13<\/code>, p\u00ebr t'u siguruar n\u00eb t\u00eb ardhmen.<\/p>\n

Karakteristika ashift<\/code> vendoset p\u00ebr \u00e7do pajisje virtuale vdev, dhe jo p\u00ebr puhun<\/i>, si\u00e7 mendon gabimisht shum\u00eb njer\u00ebz - dhe nuk ndryshohet pas vendosjes. N\u00ebse gabimisht e ke shtremb\u00ebruar ashift<\/code> kur shton nj\u00eb vdev n\u00eb pu, at\u00ebher\u00eb e ke ndotur p\u00ebrhersh\u00ebm k\u00ebt\u00eb pu me nj\u00eb pajisje me performanc\u00eb t\u00eb ul\u00ebt dhe, si\u00e7 ndodh zakonisht, nuk ka alternativ\u00eb tjet\u00ebr p\u00ebrve\u00e7se t\u00eb shkat\u00ebrrosh puun dhe t\u00eb fillosh nga e para. Edhe heqja e vdev-it nuk do t\u00eb shp\u00ebtoj\u00eb nga konfigurimi i shtremb\u00ebruar ashift<\/code>!<\/p>\n

Mekanizmi i kopjimit gjat\u00eb shkrimit<\/h3>\n

\n\"Themelor
\nN\u00ebse nj\u00eb sistem dosjesh t\u00eb zakonsh\u00ebm ka nevoj\u00eb t\u00eb riparaqes\u00eb t\u00eb dh\u00ebnat - ai ndryshon \u00e7do bllok aty ku ndodhet<\/i><\/p>\n

\"Themelor
\nSistemi i skedar\u00ebve me kopjim gjat\u00eb shkrimit regjistron nj\u00eb version t\u00eb ri t\u00eb bllokut dhe m\u00eb pas \u00e7liron versionin e vjet\u00ebr.<\/i><\/p>\n

\"Themelor
\nN\u00eb nj\u00eb form\u00eb abstrakte, n\u00ebse injorojm\u00eb vendosjen fizike reale t\u00eb bllok\u00ebve, \u00abkometa e t\u00eb dh\u00ebnave\u00bb p\u00ebrkthehet n\u00eb \u00abbregun e t\u00eb dh\u00ebnave\u00bb, i cili l\u00ebviz nga majtas n\u00eb djathtas n\u00eb hart\u00ebn e hap\u00ebsir\u00ebs s\u00eb disponueshme.<\/i><\/p>\n

\"Themelor
\nTani mund t\u00eb kuptojm\u00eb mir\u00eb se si funksionojn\u00eb snapshot-et e kopjimit gjat\u00eb shkrimit \u2014 \u00e7do bllok mund t'i p\u00ebrkas\u00eb disa snapshot-eve dhe do t\u00eb ruhet derisa t\u00eb shkat\u00ebrrohen t\u00eb gjitha snapshot-et e lidhura.<\/i><\/p>\n

Mekanizmi i kopjimit gjat\u00eb shkrimit (Copy on Write, CoW) \u00ebsht\u00eb baza themelore e asaj q\u00eb e b\u00ebn ZFS nj\u00eb sistem kaq t\u00eb shk\u00eblqyer. Koncepti themelor \u00ebsht\u00eb i thjesht\u00eb \u2014 n\u00ebse i k\u00ebrkoni nj\u00eb sistemi tradicional skedari t\u00eb ndryshoj\u00eb nj\u00eb skedar, do t\u00eb b\u00ebj\u00eb pik\u00ebrisht at\u00eb q\u00eb i k\u00ebrkoni. N\u00ebse i k\u00ebrkoni nj\u00eb sistemi skedari me kopjim gjat\u00eb shkrimit t\u00eb b\u00ebj\u00eb t\u00eb nj\u00ebjt\u00ebn gj\u00eb, ai do t\u00eb thot\u00eb \u00abmir\u00eb\u00bb \u2014 por do t'ju g\u00ebnjej\u00eb.<\/p>\n

Sistemi i skedar\u00ebve me kopjim gjat\u00eb shkrimit shkruan nj\u00eb version t\u00eb ri t\u00eb bllokut t\u00eb ndryshuar dhe m\u00eb pas p\u00ebrdit\u00ebson metadat\u00eb e skedarit p\u00ebr t\u00eb prishur lidhjen me bllokun e vjet\u00ebr dhe p\u00ebr ta lidhur me bllokun e ri q\u00eb sapo shkruaja.<\/p>\n

Shk\u00ebputja e bllokut t\u00eb vjet\u00ebr dhe lidhja e atij t\u00eb ri b\u00ebhet n\u00eb nj\u00eb operacion, prandaj nuk mund t\u00eb nd\u00ebrpritet \u2014 n\u00ebse ndalon energjin\u00eb pasi kjo t\u00eb ndodhi, do t\u00eb kesh nj\u00eb version t\u00eb ri t\u00eb skedarit, dhe n\u00ebse ndalon energjin\u00eb m\u00eb her\u00ebt, ke versionin e vjet\u00ebr. N\u00eb \u00e7do rast, n\u00eb sistemin e skedar\u00ebve nuk do t\u00eb ket\u00eb konflikte.<\/p>\n

Kopjimi gjat\u00eb shkrimit n\u00eb ZFS ndodh jo vet\u00ebm n\u00eb nivelin e sistemit t\u00eb skedar\u00ebve, por edhe n\u00eb nivelin e menaxhimit t\u00eb disqeve. Kjo do t\u00eb thot\u00eb se ZFS nuk \u00ebsht\u00eb e ndjeshme ndaj boshll\u00ebkut n\u00eb shkrim (boshll\u00ebku n\u00eb RAID<\/a><\/noindex>) \u2014 nj\u00eb fenomen ku shiritii \u00ebsht\u00eb regjistruar vet\u00ebm pjes\u00ebrisht para d\u00ebshtimit t\u00eb sistemit, duke d\u00ebmtuar masivin pas riballafimit. K\u00ebtu shiriti shkruhet n\u00eb m\u00ebnyr\u00eb atomike, vdev gjithmon\u00eb \u00ebsht\u00eb i q\u00ebndruesh\u00ebm, dhe Bobi \u00ebsht\u00eb xhaxhai yt<\/a><\/noindex>.<\/p>\n

ZIL: regjistri i q\u00ebllimeve t\u00eb ZFS<\/h3>\n

\n\"Themelor
\nSistemi ZFS trajton shkruaj m\u00eb nj\u00eb m\u00ebnyr\u00eb t\u00eb ve\u00e7ant\u00eb - ai i ruan ato p\u00ebrkoh\u00ebsisht, por menj\u00ebher\u00eb n\u00eb ZIL, p\u00ebrpara se m\u00eb von\u00eb t'i regjistroj\u00eb ato p\u00ebrfundimisht, s\u00eb bashku me shkrimet asinkrone.<\/i><\/p>\n

\"Themelor
\nZakonisht, t\u00eb dh\u00ebnat e regjistruara n\u00eb ZIL kurr\u00eb nuk lexohen p\u00ebrs\u00ebri. Por kjo \u00ebsht\u00eb e mundur pas nj\u00eb d\u00ebshtimi t\u00eb sistemit.<\/i><\/p>\n

\"Themelor
\nSLOG, ose pajisja e dyt\u00eb LOG, \u00ebsht\u00eb thjesht nj\u00eb vdev special - dhe, idealisht, shum\u00eb e shpejt\u00eb - ku ZIL mund t\u00eb ruhet ndaras nga ruajtja kryesore.<\/i><\/p>\n

\"Themelor
\nPas nj\u00eb d\u00ebshtimi, t\u00eb gjitha t\u00eb dh\u00ebnat e papastruara n\u00eb ZIL riprodhohen - n\u00eb k\u00ebt\u00eb rast ZIL ndodhet n\u00eb SLOG, prandaj ato riprodhohen pik\u00ebrisht nga atje.<\/i><\/p>\n

Ekzistojn\u00eb dy kategori kryesore t\u00eb operacioneve t\u00eb shkrimit - sinkrone (sync) dhe asinkrone (async). P\u00ebr shumic\u00ebn e ngarkesave t\u00eb pun\u00ebs, shumica d\u00ebrrmuese e operacioneve t\u00eb shkrimit jan\u00eb asinkrone - sistemi skedar i lejon t\u00eb aggregoj\u00eb ato dhe t'i l\u00ebshoj\u00eb n\u00eb paket\u00eb, duke reduktuar fragmentimin dhe duke rritur ndjesh\u00ebm kapacitetin.<\/p>\n

Shkrimet sinkrone jan\u00eb nj\u00eb \u00e7\u00ebshtje krejt\u00ebsisht tjet\u00ebr. Kur aplikacioni k\u00ebrkon nj\u00eb shkrim sinkron, ai i thot\u00eb sistemit skedar: 'Ti duhet ta ruash k\u00ebt\u00eb n\u00eb kujtes\u00ebn e q\u00ebndrueshme. n\u00eb k\u00ebt\u00eb moment<\/i>, dhe deri at\u00ebher\u00eb nuk mund t\u00eb b\u00ebj asgj\u00eb tjet\u00ebr\u00bb. Prandaj, regjistrimet sinkron do t\u00eb duhet t\u00eb regjistrohen menj\u00ebher\u00eb n\u00eb disk \u2014 dhe n\u00ebse kjo rrit fragmentimin ose zvog\u00eblon kapacitetin, ashtu t\u00eb jet\u00eb.<\/p>\n

ZFS i trajton regjistrimet sinkron ndryshe nga sistemet e zakonshme t\u00eb skedar\u00ebve \u2014 n\u00eb vend q\u00eb t'i d\u00ebrgoj\u00eb ato menj\u00ebher\u00eb n\u00eb memorie t\u00eb zakonshme, ZFS i regjistron ato n\u00eb nj\u00eb zon\u00eb t\u00eb ve\u00e7ant\u00eb ruajtjeje t\u00eb quajtur regjistri i q\u00ebllimeve t\u00eb ZFS \u2014 ZFS Intent Log, ose ZIL. Truku \u00ebsht\u00eb se k\u00ebto regjistrime po ashtu<\/i> q\u00ebndrojn\u00eb n\u00eb memorie, duke u agreguar s\u00eb bashku me k\u00ebrkesat normale asinkrone p\u00ebr regjistrim, p\u00ebr t'u nd\u00ebrprer\u00eb m\u00eb von\u00eb n\u00eb ruajtje si TXG (grupet e transaksioneve, Transaction Groups) krejt\u00ebsisht normale.<\/p>\n

N\u00eb modalitetin e zakonsh\u00ebm t\u00eb funksionimit, ZIL regjistrohet dhe kurr\u00eb nuk lexohet m\u00eb. Kur pas disa \u00e7astesh regjistrimet nga ZIL regjistrohen n\u00eb ruajtjen kryesore n\u00eb TXG t\u00eb zakonshme nga memoria, ato shk\u00ebputen nga ZIL. E vetmja her\u00eb kur di\u00e7ka lexohet nga ZIL \u2014 \u00ebsht\u00eb kur importohet nj\u00eb grup.<\/p>\n

N\u00ebse ndodh nj\u00eb d\u00ebshtim ZFS - d\u00ebshtim i sistemit operativ ose nd\u00ebrprerje e energjis\u00eb - kur n\u00eb ZIL ka t\u00eb dh\u00ebna, k\u00ebto t\u00eb dh\u00ebna do t\u00eb lexohen gjat\u00eb importimit tjet\u00ebr t\u00eb rezervuarit (p.sh., gjat\u00eb ribashkimit t\u00eb sistemit t\u00eb papritur). \u00c7do gj\u00eb q\u00eb \u00ebsht\u00eb n\u00eb ZIL do t\u00eb lexohen, do t\u00eb bashkohen n\u00eb grupe TXG, do t\u00eb regjistrohen n\u00eb magazin\u00ebn kryesore dhe pastaj do t\u00eb shk\u00ebputen nga ZIL n\u00eb procesin e importit.<\/p>\n

Nj\u00eb nga klasat ndihm\u00ebse vdev quhet LOG ose SLOG, pajisje sekondare LOG. Ai ka nj\u00eb detyr\u00eb t\u00eb vetme - t\u00eb siguroj\u00eb rezervuarin me nj\u00eb pajisje vdev t\u00eb ve\u00e7ant\u00eb dhe, idealisht, shum\u00eb m\u00eb t\u00eb shpejt\u00eb, me nj\u00eb q\u00ebndrueshm\u00ebri shum\u00eb t\u00eb lart\u00eb p\u00ebr shkrim p\u00ebr t\u00eb ruajtur ZIL, n\u00eb vend t\u00eb ruajtjes s\u00eb ZIL n\u00eb magazin\u00ebn kryesore vdev. Vet\u00eb ZIL sillet nj\u00ebsoj, pavar\u00ebsisht nga vendndodhja e ruajtjes, por n\u00ebse vdev me LOG ka nj\u00eb performanc\u00eb shum\u00eb t\u00eb lart\u00eb shkrimi, at\u00ebher\u00eb shkrimet sinkrone do t\u00eb ndodhin m\u00eb shpejt.<\/p>\n

Shtimi i nj\u00eb vdev me LOG n\u00eb rezervuar nuk do nuk mundet<\/b> t\u00eb p\u00ebrmir\u00ebsoj\u00eb performanc\u00ebn e shkrimit asinkron - edhe n\u00ebse e detyroni t\u00eb gjith\u00eb shkrimet n\u00eb ZIL n\u00ebp\u00ebrmjet zfs set sync=always<\/code>, ato do t\u00eb jen\u00eb t\u00eb lidhura me ruajtjen kryesore n\u00eb TXG n\u00eb t\u00eb nj\u00ebjt\u00ebn m\u00ebnyr\u00eb dhe me t\u00eb nj\u00ebjtin rit\u00ebm, ashtu si pa regjistrin. P\u00ebrmir\u00ebsimi i vet\u00ebm i drejtp\u00ebrdrejt\u00eb i performanc\u00ebs \u00ebsht\u00eb vonesa e shkruarjes sinkrone (nd\u00ebrsa nj\u00eb shpejt\u00ebsi m\u00eb e madhe e regjistrit p\u00ebrshpejton ekzekutimin e operacioneve. sync<\/code>).<\/p>\n

Megjithat\u00eb, n\u00eb nj\u00eb mjedis q\u00eb tashm\u00eb k\u00ebrkon nj\u00eb num\u00ebr t\u00eb madh regjistrimesh sinkrone, vdev LOG mund t\u00eb p\u00ebrshpejtoj\u00eb n\u00eb m\u00ebnyr\u00eb indirekte regjistrimin asinkron dhe leximin pa cache. Shkarkimi i regjistrimeve ZIL n\u00eb nj\u00eb vdev LOG t\u00eb ve\u00e7ant\u00eb do t\u00eb thot\u00eb m\u00eb pak konkurrenc\u00eb p\u00ebr IOPS n\u00eb ruajtjen primare, e cila ndihmon n\u00eb p\u00ebrmir\u00ebsimin e performanc\u00ebs s\u00eb t\u00eb gjitha operacioneve t\u00eb leximit dhe shkruarjes n\u00eb nj\u00ebfar\u00eb m\u00ebnyre.<\/p>\n

Snapshotet<\/h3>\n

\nMekani i kopjimit gjat\u00eb shkruarjes gjithashtu \u00ebsht\u00eb nj\u00eb baz\u00eb e nevojshme p\u00ebr snapshots atomike t\u00eb ZFS dhe replikimin inkremental asinkron. N\u00eb nj\u00eb sistem aktiv skedari ka nj\u00eb pem\u00eb treguesish q\u00eb sh\u00ebnon t\u00eb gjitha regjistrimet me t\u00eb dh\u00ebnat aktuale - kur b\u00ebni nj\u00eb snapshot, thjesht b\u00ebni nj\u00eb kopje t\u00eb k\u00ebsaj peme treguesish.<\/p>\n

Kur nj\u00eb regjist\u00ebr n\u00eb sistemin e skedar\u00ebve aktiv rishtypet, ZFS fillimisht shkruan nj\u00eb version t\u00eb ri t\u00eb bllokut n\u00eb hap\u00ebsir\u00ebn e pap\u00ebrdorur. Pastaj, ai shk\u00ebput versionin e vjet\u00ebr t\u00eb bllokut nga sistemi aktual i skedar\u00ebve. Por n\u00ebse ndonj\u00eb snapshot i referohet bllokut t\u00eb vjet\u00ebr, ai mbetet i pandryshuar. Blloku i vjet\u00ebr n\u00eb t\u00eb v\u00ebrtet\u00eb nuk do t\u00eb kthehet n\u00eb hap\u00ebsir\u00eb t\u00eb lir\u00eb derisa t\u00eb gjitha snapshot-et q\u00eb i referohen k\u00ebtij blloku t\u00eb shkat\u00ebrrohen!<\/p>\n

Replikimi<\/h3>\n

\n\"Themelor
\nBiblioteka ime Steam n\u00eb vitin 2015 zinte 158 GiB dhe p\u00ebrfshinte 126,927 skedare. Kjo \u00ebsht\u00eb mjaft af\u00ebr situat\u00ebs optimale p\u00ebr rsync \u2014 replikimi ZFS n\u00eb rrjet ishte \"ve\u00e7se\" 750% m\u00eb i shpejt\u00eb.<\/i><\/p>\n

\"Themelor
\nN\u00eb t\u00eb nj\u00ebjt\u00ebn rrjet, replikimi i nj\u00eb skedari 40-gigabajt t\u00eb imazhit t\u00eb makin\u00ebs virtuale Windows 7 \u00ebsht\u00eb nj\u00eb histori krejt\u00ebsisht ndryshe. Replikimi ZFS ndodh 289 her\u00eb m\u00eb shpejt se rsync \u2013 ose \"vet\u00ebm\" 161 her\u00eb m\u00eb shpejt, n\u00ebse jeni t\u00eb mjaftuesh\u00ebm t\u00eb aft\u00eb p\u00ebr t\u00eb thirrur rsync me \u00e7el\u00ebsin \u2013inplace.<\/i><\/p>\n

\"Themelor
\nKur imazhi i makin\u00ebs virtuale shkall\u00ebzohet, problemet e rsync shkall\u00ebzohen gjithashtu me t\u00eb. Madh\u00ebsia 1.9 TiB nuk \u00ebsht\u00eb aq e madhe p\u00ebr nj\u00eb imazh modern t\u00eb makin\u00ebs virtuale \u2013 por \u00ebsht\u00eb mjaft e madhe q\u00eb replikimi ZFS t\u00eb jet\u00eb 1148 her\u00eb m\u00eb i shpejt\u00eb se rsync, madje edhe me argumentin e rsync \u2013inplace.<\/i><\/p>\n

Sapo t\u00eb kuptoni se si funksionojn\u00eb snapshot-et, do t\u00eb jet\u00eb e leht\u00eb t\u00eb kapni kuptimin e riplikimit. Duke qen\u00eb se nj\u00eb snapshot \u00ebsht\u00eb thjesht nj\u00eb pem\u00eb drejtuesish p\u00ebr regjistrimet, kjo do t\u00eb thot\u00eb se n\u00ebse ne krijojm\u00eb zfs send<\/code> nj\u00eb snapshot, ne d\u00ebrgojm\u00eb gjithashtu k\u00ebt\u00eb pem\u00eb dhe t\u00eb gjitha regjistrimet e saj t\u00eb lidhura. Kur e d\u00ebrgojm\u00eb k\u00ebt\u00eb zfs send<\/code> n\u00eb zfs receive<\/code> n\u00eb objektin e synimit, ai shkruan si p\u00ebrmbajtjen faktike t\u00eb bllokut ashtu edhe pem\u00ebn e drejtuesve q\u00eb referojn\u00eb blloqet n\u00eb setin e t\u00eb dh\u00ebnave t\u00eb synimit.<\/p>\n

Tani b\u00ebhet edhe m\u00eb interesante n\u00eb t\u00eb dytin zfs send<\/code>. Tani kemi dy sisteme, secila p\u00ebrmban poolname\/datasetname@1<\/code>, dhe ju nxirrni nj\u00eb snapshot t\u00eb ri poolname\/datasetname@2<\/code>. Prandaj, n\u00eb pulin origjinal keni datasetname@1<\/code> dhe datasetname@2<\/code>, nd\u00ebrsa n\u00eb pulin e synimit keni vet\u00ebm snapshot-in e par\u00eb. datasetname@1<\/code>.<\/p>\n

Duke qen\u00eb se midis burimit dhe q\u00ebllimit kemi nj\u00eb snapshot t\u00eb p\u00ebrbashk\u00ebt datasetname@1<\/code>, ne mund t\u00eb b\u00ebjm\u00eb inkrementale<\/i> zfs send<\/code> mbi t\u00eb. Kur flasim me sistemin zfs send -i poolname\/datasetname@1 poolname\/datasetname@2<\/code>, kra krahasohet dy pem\u00ebt e treguesve. \u00c7do tregues, q\u00eb ekziston vet\u00ebm n\u00eb @2<\/code>, natyrisht, referon n\u00eb blloqe t\u00eb reja \u2014 prandaj na nevojitet p\u00ebrmbajtja e k\u00ebtyre bllok\u00ebve.<\/p>\n

N\u00eb sistemin e larg\u00ebt, p\u00ebrpunimi i inkrementit d\u00ebrgo<\/code> \u00ebsht\u00eb po aq i thjesht\u00eb. S\u00eb pari regjistrojm\u00eb t\u00eb gjitha sh\u00ebnimet e reja q\u00eb p\u00ebrfshihen n\u00eb rrjedh\u00eb d\u00ebrgo<\/code>, dhe pastaj shtojm\u00eb treguesit n\u00eb k\u00ebto blloqe. Voil\u00e0, e kemi @2<\/code> n\u00eb sistemin e ri!<\/p>\n

Replikimi asinkron inkremental i ZFS \u00ebsht\u00eb nj\u00eb p\u00ebrmir\u00ebsim i madh krahasuar me metodat m\u00eb t\u00eb hershme, jo t\u00eb bazuara n\u00eb snapshot, si rsync. N\u00eb t\u00eb dy rastet d\u00ebrgohen vet\u00ebm t\u00eb dh\u00ebnat e ndryshuara \u2014 por rsync duhet s\u00eb pari t\u00eb lexohen<\/i> t\u00eb lexoj\u00eb t\u00eb dh\u00ebnat nga disku n\u00eb t\u00eb dyja an\u00ebt, p\u00ebr t\u00eb verifikuar shum\u00ebn dhe p\u00ebr ta krahasuar at\u00eb. Ndryshe nga kjo, replikimi i ZFS nuk lexon asgj\u00eb p\u00ebrve\u00e7 pem\u00ebve t\u00eb treguesve \u2014 dhe \u00e7do bllok q\u00eb nuk p\u00ebrfaq\u00ebsohet n\u00eb snapshotin e zakonsh\u00ebm.<\/p>\n

Komprimimi i integruar<\/h3>\n

\nMekanizmi i kopjimit gjat\u00eb regjistrimit e thjeshton gjithashtu sistemin e kompresionit t\u00eb integruar. N\u00eb sistemet tradicionale t\u00eb skedar\u00ebve, kompresimi \u00ebsht\u00eb problematik \u2014 si versioni i vjet\u00ebr ashtu edhe versi i ri i t\u00eb dh\u00ebnave t\u00eb ndryshuara ndodhen n\u00eb t\u00eb nj\u00ebjtin hap\u00ebsir\u00eb.<\/p>\n

N\u00ebse shqyrtojm\u00eb nj\u00eb cop\u00eb t\u00eb dh\u00ebnash n\u00eb mes t\u00eb skedarit, i cili fillon jet\u00ebn e tij si nj\u00eb megabajt i zerove nga 0x00000000 dhe k\u00ebshtu me radh\u00eb \u2014 \u00ebsht\u00eb shum\u00eb e leht\u00eb ta kompresosh deri n\u00eb nj\u00eb sektor n\u00eb disk. Por \u00e7far\u00eb do t\u00eb ndodhte n\u00ebse do ta z\u00ebvend\u00ebsonim k\u00ebt\u00eb megabajt zerosh me nj\u00eb megabajt t\u00eb dh\u00ebnash q\u00eb nuk mund t\u00eb kompresohen, si JPEG ose zhurm\u00eb pseudo-rast\u00ebsore? Papritur, ky megabajt t\u00eb dh\u00ebnash do t\u00eb k\u00ebrkonte jo nj\u00eb, por 256 sektore prej 4 KiB, nd\u00ebrsa n\u00eb k\u00ebt\u00eb vend n\u00eb disk \u00ebsht\u00eb rezervuar vet\u00ebm nj\u00eb sektor.<\/p>\n

ZFS nuk ka k\u00ebt\u00eb problem, pasi regjistrimet e ndryshuara gjithmon\u00eb shkruhen n\u00eb hap\u00ebsir\u00ebn e pap\u00ebrdorur \u2014 blloku origjinal merr vet\u00ebm nj\u00eb sektor 4 KiB, nd\u00ebrsa regjistrimi i ri do t\u00eb marr\u00eb 256, por kjo nuk \u00ebsht\u00eb problem \u2014 nj\u00eb cop\u00eb e ndryshuar nga \u00abmes\u00bb i skedarit do t\u00eb shkruhej n\u00eb hap\u00ebsir\u00ebn e pap\u00ebrdorur pavar\u00ebsisht nga ndryshimi i madh\u00ebsis\u00eb s\u00eb tij, prandaj p\u00ebr ZFS kjo \u00ebsht\u00eb nj\u00eb situat\u00eb krejt e zakonshme.<\/p>\n

Shtypja e integruar ZFS \u00ebsht\u00eb e fikur si parazgjedhje, dhe sistemi ofron algoritme t\u00eb lidhura \u2014 tani midis atyre jan\u00eb LZ4, gzip (1-9), LZJB dhe ZLE.<\/p>\n

N\u00ebse skedari \u00ebsht\u00eb mjaft i madh dhe k\u00ebrkon disa blloqe, t\u00eb gjitha regjistrimet me k\u00ebt\u00eb skedar do t\u00eb ken\u00eb madh\u00ebsi recordsize<\/code>\u00a0\u2014 p\u00ebrfshir\u00eb regjistrimin e fundit, pjesa kryesore e t\u00eb cilit mund t\u00eb jet\u00eb hap\u00ebsir\u00eb e pap\u00ebrdorur<\/a><\/noindex>.<\/p>\n