{"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":"Bazat e ZFS: sistemi i ruajtjes dhe performanca","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Bazat e ZFS: sistemi i ruajtjes dhe performanca\" src=\"\/wp-content\/uploads\/2020\/06\/70d75786f36a92a0407107fb79bee721.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nK\u00ebt\u00eb pranver\u00eb ne kemi diskutuar disa tema hyr\u00ebse, p\u00ebr shembull, <noindex><a rel=\"nofollow\" href=\"https:\/\/arstechnica.com\/gadgets\/2020\/02\/how-fast-are-your-disks-find-out-the-open-source-way-with-fio\/\">si t\u00eb kontrolloni shpejt\u00ebsin\u00eb e disqeve tuaj<\/a><\/noindex> dhe <noindex><a rel=\"nofollow\" href=\"https:\/\/arstechnica.com\/information-technology\/2020\/04\/understanding-raid-how-performance-scales-from-one-disk-to-eight\/\">\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 skedar\u00ebsh t\u00eb ardhshme q\u00eb tani po implementohet kudo: nga <noindex><a rel=\"nofollow\" href=\"https:\/\/arstechnica.com\/gadgets\/2016\/06\/a-zfs-developers-analysis-of-the-good-and-bad-in-apples-new-apfs-file-system\/\">Apple<\/a><\/noindex> n\u00eb <noindex><a rel=\"nofollow\" href=\"https:\/\/arstechnica.com\/information-technology\/2020\/05\/ubuntu-20-04-welcome-to-the-future-linux-lts-disciples\/\">Ubuntu<\/a><\/noindex>.<br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><br \/>\nEpo, sot \u00ebsht\u00eb dita m\u00eb e p\u00ebrshtatshme p\u00ebr t'u njohur me ZFS, lexues t\u00eb kuresh\u00ebm. Thjesht din\u00eb se, sipas nj\u00eb vler\u00ebsimi modest t\u00eb zhvilluesit t\u00eb OpenZFS, Matt Arens, '\u00ebsht\u00eb v\u00ebrtet e komplikuar.'<\/p>\n<p>Por para se t\u00eb arrijm\u00eb te numrat \u2014 dhe ata do t\u00eb jen\u00eb, e premtoj \u2014 p\u00ebr t\u00eb gjitha opsionet e konfigurimit me tet\u00eb disqe n\u00eb ZFS, duhet t\u00eb flasim p\u00ebr at\u00eb <i>si<\/i> si ZFS i ruan t\u00eb dh\u00ebnat n\u00eb disk.<\/p>\n<h1>Zpool, vdev dhe device<\/h1>\n<p>\n<img decoding=\"async\" alt=\"Bazat e ZFS: sistemi i ruajtjes dhe performanca\" src=\"\/wp-content\/uploads\/2020\/06\/d881cb44e935480a6f2c30795d6afaf1.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Ky kjo diagram\u00eb e rezervuarit t\u00eb plot\u00eb p\u00ebrmban tre vdev t\u00eb ndihm\u00ebs, nj\u00eb nga \u00e7do klas\u00eb, dhe kat\u00ebr p\u00ebr RAIDz2.<\/i><\/p>\n<p><img decoding=\"async\" alt=\"Bazat e ZFS: sistemi i ruajtjes dhe performanca\" src=\"\/wp-content\/uploads\/2020\/06\/fa52fcf700cc72105a90e4ddc4724d9a.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Zakonisht nuk ka arsye p\u00ebr t\u00eb krijuar nj\u00eb rezervuar nga lloje dhe dimensione t\u00eb papajtueshme vdev \u2014 por n\u00ebse d\u00ebshironi, asgj\u00eb nuk ju pengon t\u00eb b\u00ebni k\u00ebt\u00eb<\/i><\/p>\n<p>P\u00ebr t\u00eb kuptuar v\u00ebrtet sistemin e skedar\u00ebve ZFS, duhet t\u00eb shikoni me kujdes n\u00eb struktur\u00ebn e saj reale. S\u00eb pari, ZFS bashkon nivelet tradicionale t\u00eb menaxhimit t\u00eb volumit dhe sistemit t\u00eb skedar\u00ebve. S\u00eb dyti, ajo p\u00ebrdor nj\u00eb mekaniz\u00ebm transaksional t\u00eb kopjimit n\u00eb shkrim. K\u00ebto ve\u00e7ori do t\u00eb thot\u00eb q\u00eb sistemi \u00ebsht\u00eb strukturalisht shum\u00eb i ndrysh\u00ebm nga sistemet e zakonshme t\u00eb skedar\u00ebve dhe grupeve RAID. Grupi i par\u00eb i blloqeve themelore p\u00ebr t\u00eb kuptuar: \u00ebsht\u00eb rezervuari i ruajtjes (zpool), aparati virtual (vdev) dhe aparati i v\u00ebrtet\u00eb (device).<\/p>\n<h3>zpool<\/h3>\n<p>\nRezervuari i ruajtjes zpool \u2014 struktura m\u00eb e lart\u00eb e ZFS. \u00c7do rezervuar p\u00ebrmban nj\u00eb ose m\u00eb shum\u00eb aparate virtuale. Nd\u00ebrsa secili prej tyre p\u00ebrmban nj\u00eb ose m\u00eb shum\u00eb aparate t\u00eb v\u00ebrtet\u00eb (device). Pulat virtuale jan\u00eb blloqe autonome. Nj\u00eb kompjuter fizik mund t\u00eb p\u00ebrmbaj\u00eb dy ose m\u00eb shum\u00eb rezerva t\u00eb ve\u00e7anta, por secili \u00ebsht\u00eb plot\u00ebsisht i pavarur nga t\u00eb tjer\u00ebt. Rezervuar\u00ebt nuk mund t\u00eb ndajn\u00eb aparate virtuale.<\/p>\n<p>Redundanca e ZFS ndodhet n\u00eb nivelin e aparateve virtuale, jo n\u00eb nivelin e rezervuara. N\u00eb nivelin e rezervuara nuk ka asnj\u00eb lloj redundance \u2014 n\u00ebse humbet ndonj\u00eb magazin\u00eb vdev ose nj\u00eb vdev t\u00eb ve\u00e7ant\u00eb, at\u00ebher\u00eb humbet gjithashtu t\u00eb gjith\u00eb rezervuarin.<\/p>\n<p>Pulat e ruajtjes moderne mund t\u00eb p\u00ebrballojn\u00eb humbjen e cache-it ose log-\u00ebve t\u00eb pajisjeve virtuale \u2014 megjithat\u00eb, ata mund t\u00eb humbin nj\u00eb sasi t\u00eb vog\u00ebl t\u00eb t\u00eb dh\u00ebnave t\u00eb papastruara n\u00ebse humbasin log-un e vdev gjat\u00eb nj\u00eb nd\u00ebrlidhjeje ose d\u00ebshtimi t\u00eb sistemit.<\/p>\n<p>Ekziston nj\u00eb keqkuptim i zakonsh\u00ebm q\u00eb \"strips\" ZFS shkruhen n\u00eb t\u00eb gjith\u00eb pulin. Kjo \u00ebsht\u00eb e pasakt\u00eb. Zpool nuk \u00ebsht\u00eb aspak nj\u00eb RAID0 qesharak; \u00ebsht\u00eb m\u00eb tep\u00ebr nj\u00eb <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Non-RAID_drive_architectures#JBOD\">JBOD<\/a><\/noindex> me nj\u00eb mekaniz\u00ebm t\u00eb nd\u00ebrlikuar shp\u00ebrndarjeje.<\/p>\n<p>P\u00ebr shumic\u00ebn e rasteve, sh\u00ebnimet shp\u00ebrndahen midis pajisjeve virtuale t\u00eb disponueshme sipas hap\u00ebsir\u00ebs s\u00eb lir\u00eb t\u00eb disponueshme, k\u00ebshtu q\u00eb teorikisht t\u00eb gjitha do t\u00eb mbushen nj\u00ebkoh\u00ebsisht. N\u00eb versionet m\u00eb t\u00eb vonshme t\u00eb ZFS, merret parasysh p\u00ebrdorimi aktual (utilizimi) i vdev \u2014 n\u00ebse nj\u00eb pajisje virtuale \u00ebsht\u00eb shum\u00eb m\u00eb e ngarkuar se nj\u00eb tjet\u00ebr (p.sh., p\u00ebr shkak t\u00eb ngarkes\u00ebs s\u00eb leximit), ajo do t\u00eb shp\u00ebrfill\u00ebt p\u00ebr shkruan, pavar\u00ebsisht nga koeficienti m\u00eb i lart\u00eb i hap\u00ebsir\u00ebs s\u00eb lir\u00eb.<\/p>\n<p>Mekanizmi i p\u00ebrcaktimit t\u00eb p\u00ebrdorimit, i nd\u00ebrtuar n\u00eb metodat moderne t\u00eb shp\u00ebrndarjes s\u00eb sh\u00ebnimeve ZFS, mund t\u00eb reduktoj\u00eb vones\u00ebn dhe t\u00eb rris\u00eb kapacitetin gjat\u00eb periudhave t\u00eb ngarkes\u00ebs s\u00eb pazakont\u00eb t\u00eb lart\u00eb \u2014 por kjo nuk \u00ebsht\u00eb <i>kart\u00eb-bllok<\/i> p\u00ebr p\u00ebrzierjen e pavullnetshme t\u00eb HDD-ve t\u00eb ngadalshme dhe SSD-ve t\u00eb shpejt\u00eb n\u00eb nj\u00eb pul. Nj\u00eb pul i till\u00eb, i pabarabart\u00eb, do t\u00eb funksionoj\u00eb gjithsesi me shpejt\u00ebsin\u00eb e pajisjes m\u00eb t\u00eb ngadalshme, pra sikur t\u00eb ishte krejt\u00ebsisht p\u00ebrb\u00ebr\u00eb nga k\u00ebto pajisje.<\/p>\n<h3>vdev<\/h3>\n<p>\n\u00c7do pul ruajtjeje p\u00ebrb\u00ebhet nga nj\u00eb ose disa pajisje virtuale (virtual device, vdev). N\u00eb turn, \u00e7do vdev p\u00ebrfshin nj\u00eb ose m\u00eb shum\u00eb pajisje reale. Shumica e pajisjeve virtuale p\u00ebrdoren p\u00ebr ruajtjen e thjesht\u00eb t\u00eb t\u00eb dh\u00ebnave, por ekzistojn\u00eb disa klasa ndihm\u00ebse t\u00eb vdev, duke p\u00ebrfshir\u00eb CACHE, LOG dhe SPECIAL. \u00c7do nga k\u00ebto lloje vdev mund t\u00eb ket\u00eb nj\u00eb nga pes\u00eb topologjit\u00eb: nj\u00eb pajisje t\u00eb vetme (single-device), RAIDz1, RAIDz2, RAIDz3 ose pasqyr\u00eb (mirror).<\/p>\n<p>RAIDz1, RAIDz2 dhe RAIDz3 jan\u00eb variante t\u00eb ve\u00e7anta t\u00eb asaj q\u00eb dikur njihej si RAID me dyfishim (diagonal). 1, 2 dhe 3 i referohen numrit t\u00eb bllokjeve t\u00eb kontrollit t\u00eb paracaktuar p\u00ebr secil\u00ebn brez t\u00eb t\u00eb dh\u00ebnave. N\u00eb vend t\u00eb disqeve t\u00eb ve\u00e7anta p\u00ebr sigurimin e kontrollit, pajisjet virtuale RAIDz e shp\u00ebrndajn\u00eb k\u00ebt\u00eb kontroll n\u00eb m\u00ebnyr\u00eb semi-uniforme mes disqeve. Nj\u00eb masiv RAIDz mund t\u00eb humbas\u00eb aq disqe sa ka bllokje kontrolli; n\u00ebse humb edhe nj\u00eb tjet\u00ebr, do t\u00eb dal\u00eb jasht\u00eb funksionit dhe do t\u00eb shkat\u00ebrroj\u00eb gjithashtu rezervatin e ruajtjes.<\/p>\n<p>N\u00eb pajisjet virtuale t\u00eb pasqyr\u00ebs (mirror vdev), \u00e7do bllok ruhet n\u00eb \u00e7do pajisje n\u00eb vdev. Nd\u00ebrsa pasqyrat dyfisha (two-wide) jan\u00eb m\u00eb t\u00eb zakonshme, mund t\u00eb ket\u00eb \u00e7do num\u00ebr t\u00eb rast\u00ebsish\u00ebm pajisjesh n\u00eb pasqyr\u00eb \u2014 n\u00eb instalime t\u00eb m\u00ebdha p\u00ebr t\u00eb p\u00ebrmir\u00ebsuar performanc\u00ebn e leximit dhe q\u00ebndrueshm\u00ebrin\u00eb, shpesh p\u00ebrdoren pasqyra trefish. Nj\u00eb pasqyr\u00eb vdev mund t\u00eb mbijetoj\u00eb \u00e7do d\u00ebshtim, p\u00ebr sa koh\u00eb q\u00eb vazhdon t\u00eb funksionoj\u00eb s\u00eb paku nj\u00eb pajisje n\u00eb vdev.<\/p>\n<p>Vdev t\u00eb vetme n\u00eb thelb jan\u00eb t\u00eb rrezikshme. Nj\u00eb pajisje virtuale e till\u00eb nuk do t\u00eb mbijetoj\u00eb asnj\u00eb d\u00ebshtim \u2014 dhe n\u00ebse p\u00ebrdoret si ruajtje ose vdev i ve\u00e7ant\u00eb, d\u00ebshtimi i saj do t\u00eb \u00e7oj\u00eb n\u00eb shkat\u00ebrrimin e t\u00eb gjith\u00eb rezervatit. Kujdesuni shum\u00eb k\u00ebtu.<\/p>\n<p>Pajisjet virtuale CACHE, LOG dhe SPECIAL mund t\u00eb krijohen sipas ndonj\u00eb prej topologjive t\u00eb m\u00ebsip\u00ebrme \u2014 por kujtoni se humbja e nj\u00eb pajisjeje virtuale SPECIAL do t\u00eb thot\u00eb humbjen e rezervatit, k\u00ebshtu q\u00eb rekomandohet q\u00eb t\u00eb ket\u00eb nj\u00eb topologji t\u00eb tep\u00ebrt.<\/p>\n<h3>device<\/h3>\n<p>\nKjo \u00ebsht\u00eb ndoshta termi m\u00eb i leht\u00eb p\u00ebr t'u kuptuar n\u00eb ZFS \u2014 \u00ebsht\u00eb literalisht nj\u00eb pajisje blloku me qasje t\u00eb rast\u00ebsishme. Kujtoni se pajisjet virtuale p\u00ebrb\u00ebhen nga pajisje t\u00eb ve\u00e7anta, nd\u00ebrsa rezervati p\u00ebrb\u00ebhet nga pajisje virtuale.<\/p>\n<p>Disqet \u2014 magnetike ose solid-state \u2014 jan\u00eb pajisjet m\u00eb t\u00eb zakonshme bllok q\u00eb p\u00ebrdoren si blloqe nd\u00ebrtimi p\u00ebr vdev. Megjithat\u00eb, \u00e7do pajisje me nj\u00eb descriptor n\u00eb \/dev \u00ebsht\u00eb n\u00eb rregull \u2014 k\u00ebshtu q\u00eb gjithashtu mund t\u00eb p\u00ebrdoren grupe t\u00eb plota RAID harduerike si pajisje t\u00eb ve\u00e7anta.<\/p>\n<p>Nj\u00eb skedar raw i thjesht\u00eb \u00ebsht\u00eb nj\u00eb nga pajisjet alternative m\u00eb t\u00eb r\u00ebnd\u00ebsishme bllok nga t\u00eb cilat mund t\u00eb nd\u00ebrtohet nj\u00eb vdev. Pulat testuese nga <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Sparse_file\">skedar\u00eb t\u00eb holl\u00eb<\/a><\/noindex>\u00a0jan\u00eb nj\u00eb m\u00ebnyr\u00eb shum\u00eb e dobishme p\u00ebr t\u00eb provuar komandat e rezervatit dhe p\u00ebr t\u00eb par\u00eb sa hap\u00ebsir\u00eb \u00ebsht\u00eb n\u00eb dispozicion n\u00eb rezervat ose pajisjet virtuale t\u00eb k\u00ebsaj topologjie.<\/p>\n<p><img decoding=\"async\" alt=\"Bazat e ZFS: sistemi i ruajtjes dhe performanca\" src=\"\/wp-content\/uploads\/2020\/06\/d9bea0e4a6842742a7dbac2f9b1ba394.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Mund t\u00eb krijoni nj\u00eb grup testues nga skedar\u00eb t\u00eb holluar p\u00ebr disa sekonda \u2014 por mos harroni m\u00eb pas t\u00eb fshini t\u00eb gjith\u00eb grupin dhe komponent\u00ebt e tij.<\/i> <\/p>\n<p>Supozoni se d\u00ebshironi t\u00eb vendosni nj\u00eb server me tet\u00eb disqe dhe planifikoni t\u00eb p\u00ebrdorni disqe 10 TB (~9300 GiB) \u2014 por nuk jeni t\u00eb sigurt se cila topologji i p\u00ebrshtatet m\u00eb s\u00eb miri nevojave tuaja. N\u00eb shembullin e m\u00ebsip\u00ebrm, ne krijojm\u00eb nj\u00eb grup testues nga skedar\u00ebt e holluar p\u00ebr disa sekonda \u2014 dhe tani e dim\u00eb se nj\u00eb RAIDz2 vdev me tet\u00eb disqe 10 TB siguron 50 TiB kapacitet t\u00eb dobish\u00ebm.<\/p>\n<p>Nj\u00eb klas\u00eb tjet\u00ebr e ve\u00e7ant\u00eb e pajisjeve \u00ebsht\u00eb SPARE (rezerv\u00eb). Pajisjet e nxehta t\u00eb z\u00ebvend\u00ebsimit, ndryshe nga pajisjet e zakonshme, i p\u00ebrkasin t\u00eb gjith\u00eb grupit dhe jo nj\u00eb vdev t\u00eb vet\u00ebm. N\u00ebse ndonj\u00eb vdev n\u00eb grup d\u00ebshton, dhe pajisja rezerv\u00eb \u00ebsht\u00eb e lidhur me grupin dhe e disponueshme, ajo automatikisht do t\u00eb bashkohet me vdev-in e d\u00ebmtuar.<\/p>\n<p>Pas lidhjes 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, kjo quhet rikuperim (rebuilding), nd\u00ebrsa n\u00eb ZFS q\u00eb quhet \"rikuperim mbivend\u00ebsie\" (resilvering).<\/p>\n<p>\u00cbsht\u00eb e r\u00ebnd\u00ebsishme t\u00eb theksohet se pajisjet rezerv\u00eb nuk z\u00ebvend\u00ebsojn\u00eb p\u00ebrher\u00eb pajisjet q\u00eb kan\u00eb d\u00ebshtuar. Kjo \u00ebsht\u00eb vet\u00ebm nj\u00eb z\u00ebvend\u00ebsim i p\u00ebrkohsh\u00ebm p\u00ebr t\u00eb shkurtuar koh\u00ebn gjat\u00eb s\u00eb cil\u00ebs vdev-i \u00ebsht\u00eb i degraduar. Pas z\u00ebvend\u00ebsimit t\u00eb pajisjes s\u00eb d\u00ebshtuar nga administratori, ndodh rikuperimi i mbivend\u00ebsis\u00eb n\u00eb k\u00ebt\u00eb pajisje t\u00eb p\u00ebrhershme, dhe SPARE shk\u00ebputet nga vdev-i dhe kthehet n\u00eb funksion si rezerv\u00eb p\u00ebr t\u00eb gjith\u00eb grupin.<\/p>\n<h1>Grupet e t\u00eb dh\u00ebnave, blloqet dhe sektoret<\/h1>\n<p>\nGrupi tjet\u00ebr i blloqeve nd\u00ebrtuese q\u00eb duhet t\u00eb kuptohet n\u00eb udh\u00ebtimin ton\u00eb me ZFS, lidhet m\u00eb shum\u00eb me m\u00ebnyr\u00ebn se si organizohen dhe ruhen t\u00eb dh\u00ebnat. Ne k\u00ebtu kalojm\u00eb disa nivele \u2014 si metaslab \u2014 p\u00ebr t\u00eb shmangur grumbullimin e detajeve, duke ruajtur kuptimin e struktur\u00ebs s\u00eb p\u00ebrgjithshme.<\/p>\n<h3>Grupi i t\u00eb dh\u00ebnave (dataset)<\/h3>\n<p>\n<img decoding=\"async\" alt=\"Bazat e ZFS: sistemi i ruajtjes dhe performanca\" src=\"\/wp-content\/uploads\/2020\/06\/6a4dc218bd1c57989739d5072f13804c.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Kur 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 grupit. Pastaj ne vendosim nj\u00eb kuot\u00eb \u2014 dhe ndryshojm\u00eb pik\u00ebn e montimit. Magjia!<\/i> <\/p>\n<p><img decoding=\"async\" alt=\"Bazat e ZFS: sistemi i ruajtjes dhe performanca\" src=\"\/wp-content\/uploads\/2020\/06\/aeb6763d6e78e3cc7ee8b1d39ee98b46.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Zvol \u00ebsht\u00eb n\u00eb thelb nj\u00eb grup t\u00eb dh\u00ebnash, i cili i mungon layer-in e tij t\u00eb sistemit t\u00eb skedar\u00ebve, q\u00eb ne e z\u00ebvend\u00ebsojm\u00eb k\u00ebtu me nj\u00eb sistem t\u00eb zakonsh\u00ebm skedar\u00ebsh si ext4.<\/i> <\/p>\n<p>Grupi i t\u00eb dh\u00ebnave ZFS \u00ebsht\u00eb af\u00ebrsisht i ngjash\u00ebm me sistemin standard t\u00eb skedar\u00ebve t\u00eb montuar. Ashtu si nj\u00eb sistem i zakonsh\u00ebm skedar\u00ebsh, n\u00eb pamje t\u00eb par\u00eb duket \"thjesht si nj\u00eb tjet\u00ebr dosje\". Por, ashtu si n\u00eb sistemet e zakonshme t\u00eb skedar\u00ebve t\u00eb montuar, secili grup t\u00eb dh\u00ebnash ZFS ka setin e vet t\u00eb pronave baz\u00eb.<\/p>\n<p>Para s\u00eb gjithash, nj\u00eb grup t\u00eb dh\u00ebnash mund t\u00eb ket\u00eb nj\u00eb kuot\u00eb t\u00eb caktuar. N\u00ebse vendosni <code>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 <code>\/poolname\/datasetname<\/code> m\u00eb shum\u00eb se 100 GiB.<\/p>\n<p>A keni v\u00ebn\u00eb re pranin\u00eb \u2013 dhe munges\u00ebn \u2013 e ndar\u00ebsve n\u00eb fillim t\u00eb \u00e7do rreshti? Secili grup t\u00eb dh\u00ebnash ka vendin e tij si n\u00eb hierarkin\u00eb ZFS, ashtu edhe n\u00eb hierarkin\u00eb e montimit t\u00eb sistemit. N\u00eb hierarkin\u00eb ZFS nuk ka ndar\u00ebs n\u00eb fillim \u2013 filloni me emrin e pishin\u00ebs dhe pastaj rrug\u00ebn nga nj\u00eb grup t\u00eb dh\u00ebnash n\u00eb tjetrin. P\u00ebr shembull, <code>pool\/parent\/child<\/code> p\u00ebr nj\u00eb grup t\u00eb dh\u00ebnash me emrin <code>f\u00ebmija<\/code> n\u00ebn grupin e dh\u00ebnash prind <code>parent<\/code> n\u00eb nj\u00eb pishin\u00eb me nj\u00eb em\u00ebr krijues <code>pool<\/code>.<\/p>\n<p>N\u00eb m\u00ebnyr\u00eb t\u00eb parazgjedhur, pika e montimit t\u00eb grupit t\u00eb dh\u00ebnash do t\u00eb jet\u00eb ekuivalente me emrin e tij n\u00eb hierarkin\u00eb ZFS, me nj\u00eb ndar\u00ebs n\u00eb fillim \u2013 pishina me emrin <code>pool<\/code> do t\u00eb montoj\u00eb si <code>\/pool<\/code>, grupi i t\u00eb dh\u00ebnash <code>parent<\/code> do t\u00eb montohet n\u00eb <code>\/pool\/parent<\/code>, dhe grupi i dh\u00ebnash f\u00ebmij\u00eb <code>f\u00ebmija<\/code> do t\u00eb montohet n\u00eb <code>\/pool\/parent\/child<\/code>. Megjithat\u00eb, pika e montimit e sistemit p\u00ebr grupin e dh\u00ebnash mund t\u00eb ndryshohet.<\/p>\n<p>N\u00ebse ne p\u00ebrcaktojm\u00eb <code>zfs set mountpoint=\/lol pool\/parent\/child<\/code>, at\u00ebher\u00eb grupi i dh\u00ebnash <code>pool\/parent\/child<\/code> do t\u00eb montohet n\u00eb sistem si <code>\/lol<\/code>.<\/p>\n<p>P\u00ebrve\u00e7 grupeve t\u00eb dh\u00ebnash, duhet t\u00eb p\u00ebrmendim volumin (zvols). Nj\u00eb volum \u00ebsht\u00eb af\u00ebrsisht i ngjash\u00ebm me nj\u00eb grup t\u00eb dh\u00ebnash, p\u00ebrve\u00e7se nuk ka n\u00eb t\u00eb nj\u00eb sistem skedar\u00ebsh \u2013 \u00ebsht\u00eb thjesht nj\u00eb pajisje blloku. Ju mund, p\u00ebr shembull, t\u00eb krijoni <code>zvol<\/code> me emrin <code>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 \u2013 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 back-end kur eksportoni nj\u00eb pajisje iSCSI.<\/p>\n<h3>Nj\u00ebsi<\/h3>\n<p>\n<img decoding=\"async\" alt=\"Bazat e ZFS: sistemi i ruajtjes dhe performanca\" src=\"\/wp-content\/uploads\/2020\/06\/ce96416cd2fa08ff615f13ccec72e838.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Skedari p\u00ebrfaq\u00ebsohet nga nj\u00eb ose disa blloqe. \u00c7do bllok ruhet n\u00eb nj\u00eb pajisje virtuale. Madh\u00ebsia e bllokut zakonisht \u00ebsht\u00eb e barabart\u00eb me parametrin <b>recordsize<\/b>, por mund t\u00eb ulet n\u00eb <b>2^ashift<\/b>, n\u00ebse p\u00ebrmban metadata ose nj\u00eb skedar t\u00eb vog\u00ebl.<\/i><\/p>\n<p><img decoding=\"async\" alt=\"Bazat e ZFS: sistemi i ruajtjes dhe performanca\" src=\"\/wp-content\/uploads\/2020\/06\/f31c25e34af12a9a96b60a46c2924053.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Ne v\u00ebrtet, <b>v\u00ebrtet\u00eb<\/b> nuk e kemi fjal\u00eb p\u00ebr d\u00ebmin e madh t\u00eb performanc\u00ebs, n\u00ebse vendosni nj\u00eb ashift shum\u00eb t\u00eb vog\u00ebl<\/i><\/p>\n<p>N\u00eb grupin ZFS t\u00eb gjitha t\u00eb dh\u00ebnat, duke p\u00ebrfshir\u00eb metadat\u00ebn, ruhen n\u00eb blloqe. Madh\u00ebsia maksimale e bllokut p\u00ebr secil\u00ebn grup t\u00eb dh\u00ebnash p\u00ebrcaktohet n\u00eb pron\u00ebn <code>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 ndonj\u00eb blloku q\u00eb \u00ebsht\u00eb tashm\u00eb shkruar n\u00eb grupin e dh\u00ebnash - ajo vepron vet\u00ebm p\u00ebr blloqet e reja nd\u00ebrsa shkruhen.<\/p>\n<p>N\u00ebse nuk \u00ebsht\u00eb p\u00ebrcaktuar ndryshe, madh\u00ebsia aktuale e sh\u00ebnimit p\u00ebr default \u00ebsht\u00eb 128 KiB. Ky \u00ebsht\u00eb nj\u00eb kompromis i caktuar, ku performanca do t\u00eb jet\u00eb as ideale, as e tmerrshme n\u00eb shumic\u00ebn e rasteve. <code>Madh\u00ebsia e sh\u00ebnimit<\/code> mund t\u00eb vendoset n\u00eb \u00e7do vler\u00eb nga 4K deri n\u00eb 1M (me konfigurime shtes\u00eb <code>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<p>\u00c7do bllok referon vet\u00ebm n\u00eb t\u00eb dh\u00ebnat e nj\u00eb skedari - nuk mund t\u00eb futni dy skeda t\u00eb ndryshme n\u00eb nj\u00eb bllok. \u00c7do skedar \u00ebsht\u00eb i p\u00ebrb\u00ebr\u00eb nga nj\u00eb ose disa blloqe, var\u00ebsisht nga madh\u00ebsia. 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 skedar 2 KiB do t\u00eb marr\u00eb vet\u00ebm nj\u00eb sektor 4 KiB n\u00eb disk.<\/p>\n<p>N\u00ebse skedari \u00ebsht\u00eb mjaft i madh dhe k\u00ebrkon disa blloqe, at\u00ebher\u00eb t\u00eb gjitha sh\u00ebnimet me k\u00ebt\u00eb skedar do t\u00eb ken\u00eb madh\u00ebsin\u00eb <code>recordsize<\/code>\u00a0- duke p\u00ebrfshir\u00eb sh\u00ebnimin p\u00ebrfundimtar, pjesa kryesore e t\u00eb cilit mund t\u00eb rezultoj\u00eb <noindex><a rel=\"nofollow\" href=\"https:\/\/whatis.techtarget.com\/definition\/slack-space-file-slack-space\">n\u00eb hap\u00ebsir\u00eb t\u00eb pa p\u00ebrdorur.<\/a><\/noindex>.<\/p>\n<p>Grupet zvol nuk kan\u00eb pron\u00eb <code>recordsize<\/code>\u00a0- p\u00ebrkundrazi, ato kan\u00eb nj\u00eb pron\u00eb ekuivalente <code>madh\u00ebsia e bllokut t\u00eb volumit<\/code>.<\/p>\n<h3>Sektor\u00ebt<\/h3>\n<p>\nSektori, blloku m\u00eb i fundit, m\u00eb thelb\u00ebsor. Ky \u00ebsht\u00eb nj\u00ebsi fizike m\u00eb e vog\u00ebl, e cila mund t\u00eb shkruhet ose lexohet nga pajisja baz\u00eb. Gjat\u00eb disa dekadash, shumica e disqeve kan\u00eb p\u00ebrdorur sektor\u00eb prej 512 byte. Koh\u00ebt e fundit, shumica e disqeve jan\u00eb konfiguruar p\u00ebr sektor\u00eb 4 KiB, dhe n\u00eb disa - ve\u00e7an\u00ebrisht SSD - sektor\u00ebt 8 KiB ose madje m\u00eb shum\u00eb.<\/p>\n<p>N\u00eb sistemin ZFS ekziston nj\u00eb pron\u00eb q\u00eb lejon t\u00eb vendosni manualisht madh\u00ebsin\u00eb e sektorit. Kjo pron\u00eb <code>ashift<\/code>. Paksa e ngat\u00ebrruar, q\u00eb ashift \u00ebsht\u00eb nj\u00eb fuqi e dyshes. P\u00ebr shembull, <code>ashift=9<\/code> n\u00ebnkupton madh\u00ebsin\u00eb e sektorit 2^9, ose 512 byte.<\/p>\n<p>ZFS k\u00ebrkon nga sistemi operativ informacion t\u00eb detajuar p\u00ebr \u00e7do pajisje bllok, kur ajo shtohet n\u00eb nj\u00eb vdev t\u00eb ri, dhe teorikisht e vendos automatikisht ashift n\u00eb m\u00ebnyr\u00eb t\u00eb duhur mbi baz\u00ebn e k\u00ebtij informacioni. Fatkeq\u00ebsisht, shum\u00eb disqe g\u00ebnjejn\u00eb p\u00ebr madh\u00ebsin\u00eb e tyre t\u00eb sektor\u00ebve p\u00ebr t\u00eb ruajtur p\u00ebrputhshm\u00ebrin\u00eb me Windows XP (i cili nuk ishte n\u00eb gjendje t\u00eb kuptonte disqe me madh\u00ebsi t\u00eb tjera sektor\u00ebsh).<\/p>\n<p>Kjo do t\u00eb thot\u00eb se administratori i ZFS rekomandohet me ngulm t\u00eb dij\u00eb madh\u00ebsin\u00eb e v\u00ebrtet\u00eb t\u00eb sektor\u00ebve t\u00eb pajisjeve t\u00eb tij dhe ta vendos\u00eb at\u00eb manualisht. <code>ashift<\/code>. N\u00ebse ashift \u00ebsht\u00eb vendosur shum\u00eb i vog\u00ebl, at\u00ebher\u00eb numri i operacioneve t\u00eb leximit\/shkrimit rritet astronomikisht. Pra, shkrimi i \"sektor\u00ebve\" 512-byte n\u00eb nj\u00eb sektor real 4 KiB n\u00ebnkupton nevoj\u00ebn p\u00ebr t\u00eb shkruar \"sektorin\" e par\u00eb, pastaj t\u00eb lexoj\u00eb sektorin 4 KiB, ta ndryshoj\u00eb me \"sektorin\" e dyt\u00eb 512-byte, ta shkruaj\u00eb prap\u00eb n\u00eb sektorin e ri 4 KiB dhe k\u00ebshtu me radh\u00eb p\u00ebr \u00e7do shkrim.<\/p>\n<p>N\u00eb bot\u00ebn reale, nj\u00eb d\u00ebnim i till\u00eb ka ndikim tek disk\u00ebt e ngurt\u00eb Samsung EVO, p\u00ebr t\u00eb cil\u00ebt duhet t\u00eb jet\u00eb n\u00eb fuqi <code>ashift=13<\/code>, por k\u00ebto SSD g\u00ebnjejn\u00eb p\u00ebr madh\u00ebsin\u00eb e tyre t\u00eb sektor\u00ebve, dhe prandaj vendoset si parazgjedhje <code>ashift=9<\/code>. N\u00ebse nj\u00eb administrator i avancuar i sistemit nuk e ndryshon k\u00ebt\u00eb parametrin, at\u00ebher\u00eb ky SSD punon <i>m\u00ebngjes<\/i> si nj\u00eb HDD t\u00eb zakonsh\u00ebm.<\/p>\n<p>P\u00ebr krahasim, nuk ka ndonj\u00eb d\u00ebnim p\u00ebr madh\u00ebsi tep\u00ebr t\u00eb madhe <code>ashift<\/code> . P\u00ebrmir\u00ebsimi real i performanc\u00ebs nuk ka, dhe rritja e hap\u00ebsir\u00ebs s\u00eb pap\u00ebrdorur \u00ebsht\u00eb p\u00ebrjet\u00ebsisht e vog\u00ebl (ose e barabart\u00eb me zero kur kompresimi \u00ebsht\u00eb aktivizuar). Prandaj, ne rekomandojm\u00eb ngulmsh\u00ebm madje edhe p\u00ebr disqet, q\u00eb me t\u00eb v\u00ebrtet\u00eb p\u00ebrdorin sektor\u00eb 512-byte, t\u00eb vendosin <code>ashift=12<\/code> apo madje <code>ashift=13<\/code>, p\u00ebr t\u00eb shikuar me siguri drejt t\u00eb ardhmes.<\/p>\n<p>Pron\u00ebsia <code>ashift<\/code> vendoset p\u00ebr \u00e7do pajisje virtuale vdev, dhe <i>jo p\u00ebr rezervuarin<\/i>, si\u00e7 mendojn\u00eb shum\u00eb, dhe nuk ndryshohet pasi \u00ebsht\u00eb vendosur. N\u00ebse p\u00ebr fat t\u00eb keq e keni prishur <code>ashift<\/code> kur shtoni nj\u00eb vdev t\u00eb ri n\u00eb rezervuar, at\u00ebher\u00eb e keni ndotur p\u00ebrhershm\u00ebrisht k\u00ebt\u00eb rezervuar me nj\u00eb pajisje me performanc\u00eb t\u00eb ul\u00ebt dhe, p\u00ebr zakon, nuk ka nj\u00eb zgjidhje tjet\u00ebr p\u00ebrve\u00e7se t\u00eb shkat\u00ebrroni rezervuarin dhe t\u00eb filloni gjith\u00e7ka nga e para. Edhe heqja e vdev-it nuk do t\u00eb shp\u00ebtoj\u00eb nga konfigurimi i prishur. <code>ashift<\/code>!<\/p>\n<h3>Mekanizmi i kopjimit gjat\u00eb shkrimit<\/h3>\n<p>\n<img decoding=\"async\" alt=\"Bazat e ZFS: sistemi i ruajtjes dhe performanca\" src=\"\/wp-content\/uploads\/2020\/06\/eb222dbcc3de428ff2b1c2c72b145db0.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>N\u00ebse nj\u00eb sistem i zakonsh\u00ebm t\u00eb skedar\u00ebve duhet t\u00eb rishkruaj\u00eb t\u00eb dh\u00ebna - ai ndryshon \u00e7do bllok aty ku ndodhet.<\/i><\/p>\n<p><img decoding=\"async\" alt=\"Bazat e ZFS: sistemi i ruajtjes dhe performanca\" src=\"\/wp-content\/uploads\/2020\/06\/ba2474808b32667902966e4c9e69081a.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Sistemi i skedar\u00ebve me kopjim gjat\u00eb shkrimit regjistron nj\u00eb version t\u00eb ri t\u00eb bllokut dhe pastaj \u00e7el versionin e vjet\u00ebr<\/i><\/p>\n<p><img decoding=\"async\" alt=\"Bazat e ZFS: sistemi i ruajtjes dhe performanca\" src=\"\/wp-content\/uploads\/2020\/06\/3b00dad44eb588ed793d2d5df7852892.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>N\u00eb nj\u00eb kuptim abstrahues, n\u00ebse injorojm\u00eb vendndodhjen fizike reale t\u00eb bllokut, 'kometa e t\u00eb dh\u00ebnave' ton\u00eb thjeshtohet n\u00eb nj\u00eb 'krimb t\u00eb dh\u00ebnash', i cili l\u00ebviz nga e majta n\u00eb t\u00eb djatht\u00eb n\u00eb hart\u00ebn e hap\u00ebsir\u00ebs s\u00eb disponueshme<\/i><\/p>\n<p><img decoding=\"async\" alt=\"Bazat e ZFS: sistemi i ruajtjes dhe performanca\" src=\"\/wp-content\/uploads\/2020\/06\/8c2c38dbc8a5e633c466d5c7f230951f.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Tani mund t\u00eb kemi nj\u00eb ide t\u00eb qart\u00eb se si funksionojn\u00eb snapshots me kopjim gjat\u00eb shkrimit \u2014 \u00e7do bllok mund t'i p\u00ebrkas\u00eb disa snapshots, dhe do t\u00eb ruhet deri sa t\u00eb shkat\u00ebrrohen t\u00eb gjith\u00eb snapshots e lidhura<\/i><\/p>\n<p>Mekanizmi i kopjimit gjat\u00eb shkrimit (Copy on Write, CoW) \u00ebsht\u00eb themeli i asaj q\u00eb e b\u00ebn ZFS nj\u00eb sistem kaq t\u00eb shk\u00eblqyer. Koncepti kryesor \u00ebsht\u00eb i thjesht\u00eb \u2014 n\u00ebse i k\u00ebrkoni nj\u00eb sistem tradicional skedari t\u00eb ndryshoj\u00eb nj\u00eb skedar, ai do t\u00eb b\u00ebj\u00eb at\u00eb q\u00eb i k\u00ebrkoni. N\u00ebse i k\u00ebrkoni nj\u00eb sistem skedari me kopjim gjat\u00eb shkrimit t\u00eb b\u00ebj\u00eb t\u00eb nj\u00ebjt\u00ebn gj\u00eb, ai do t\u00eb thot\u00eb 'mir\u00eb' \u2014 por do t'ju g\u00ebnjej\u00eb.<\/p>\n<p>N\u00eb vend t\u00eb k\u00ebsaj, sistemi i skedar\u00ebve me kopjim gjat\u00eb shkrimit regjistron nj\u00eb version t\u00eb ri t\u00eb bllokut t\u00eb ndryshuar dhe pastaj p\u00ebrdit\u00ebson meta t\u00eb dh\u00ebnat e skedarit p\u00ebr t\u00eb ndar\u00eb lidhjen me bllokun e vjet\u00ebr dhe p\u00ebr t\u00eb lidhur me t\u00eb bllokun e ri q\u00eb sapo e keni regjistruar.<\/p>\n<p>Shk\u00ebputja e bllokut t\u00eb vjet\u00ebr dhe lidhja e bllokut t\u00eb ri realizohet me nj\u00eb operacion, prandaj nuk mund t\u00eb nd\u00ebrpritet \u2014 n\u00ebse n\u00ebnshkruani energjin\u00eb pasi t\u00eb ndodh\u00eb kjo, keni nj\u00eb version t\u00eb ri t\u00eb skedarit, dhe n\u00ebse n\u00ebnshkruani energjin\u00eb m\u00eb her\u00ebt, at\u00ebher\u00eb keni versionin e vjet\u00ebr. N\u00eb \u00e7do rast, nuk do t\u00eb ket\u00eb konflikte n\u00eb sistemin e skedar\u00ebve.<\/p>\n<p>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 prekshme nga hap\u00ebsira e shkrimit (<noindex><a rel=\"nofollow\" href=\"http:\/\/www.raid-recovery-guide.com\/raid5-write-hole.aspx\">vrim\u00eb n\u00eb RAID<\/a><\/noindex>) \u2014 fenomeni kur shiriti ka arritur t\u00eb regjistrohet vet\u00ebm pjes\u00ebrisht deri n\u00eb d\u00ebshtimin e sistemit, me d\u00ebmtimin e grupit pas rinisjes. K\u00ebtu, shiriti shkruhet atomikisht, vdev gjithmon\u00eb \u00ebsht\u00eb i rregullt, dhe <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Bob%27s_your_uncle\">Bobi \u00ebsht\u00eb xhaxhai yt<\/a><\/noindex>.<\/p>\n<h3>ZIL: e journali i q\u00ebllimeve ZFS<\/h3>\n<p>\n<img decoding=\"async\" alt=\"Bazat e ZFS: sistemi i ruajtjes dhe performanca\" src=\"\/wp-content\/uploads\/2020\/06\/8d08b7bce60a1e3698fd0ec02494e6fe.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Sistemi ZFS trajton regjistrimet sinkrone n\u00eb nj\u00eb m\u00ebnyr\u00eb t\u00eb ve\u00e7ant\u00eb \u2014 ai p\u00ebrkoh\u00ebsisht, por menj\u00ebher\u00eb i ruan ato n\u00eb ZIL, para se m\u00eb von\u00eb t'i regjistroj\u00eb ato n\u00eb m\u00ebnyr\u00eb t\u00eb p\u00ebrhershme s\u00eb bashku me regjistrimet asinkrone<\/i><\/p>\n<p><img decoding=\"async\" alt=\"Bazat e ZFS: sistemi i ruajtjes dhe performanca\" src=\"\/wp-content\/uploads\/2020\/06\/2119ef409a7d8c9599ee63292452d80d.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Zakoni \u00ebsht\u00eb q\u00eb t\u00eb dh\u00ebnat e regjistruara n\u00eb ZIL kurr\u00eb nuk lexohen m\u00eb. Por \u00ebsht\u00eb e mundur pas d\u00ebshtimit t\u00eb sistemit<\/i><\/p>\n<p><img decoding=\"async\" alt=\"Bazat e ZFS: sistemi i ruajtjes dhe performanca\" src=\"\/wp-content\/uploads\/2020\/06\/88a62163b0fb9f14a41102821dfabb5f.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>SLOG, ose pajisja e dyt\u00eb LOG, \u00ebsht\u00eb thjesht nj\u00eb vdev i ve\u00e7ant\u00eb - dhe, preferohet, shum\u00eb i shpejt\u00eb - ku ZIL mund t\u00eb ruhet ndaras nga ruajtja kryesore.<\/i><\/p>\n<p><img decoding=\"async\" alt=\"Bazat e ZFS: sistemi i ruajtjes dhe performanca\" src=\"\/wp-content\/uploads\/2020\/06\/819f7c21714adafe226028e95990f1df.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Pas nj\u00eb d\u00ebshtimi, t\u00eb gjitha t\u00eb dh\u00ebnat e ndotura n\u00eb ZIL riprodhohen - n\u00eb k\u00ebt\u00eb rast, ZIL ndodhet n\u00eb SLOG, k\u00ebshtu q\u00eb ato riprodhohen pik\u00ebrisht prej aty.<\/i><\/p>\n<p>Ka dy kategori kryesore operacionesh shkrimi - sinkronike (sync) dhe asinkronike (async). P\u00ebr shumic\u00ebn e ngarkesave t\u00eb pun\u00ebs, pjesa m\u00eb e madhe e operacioneve t\u00eb shkrimit jan\u00eb asinkronike - sistemi i skedar\u00ebve lejon agregimin e tyre dhe t'i jap\u00eb ato n\u00eb grup, duke reduktuar fragmentimin dhe duke rritur ndjesh\u00ebm kapacitetin.<\/p>\n<p>Shkrimet sinkronike jan\u00eb nj\u00eb gj\u00eb krejt tjet\u00ebr. Kur nj\u00eb aplikacion k\u00ebrkon nj\u00eb shkrim sinkronik, ai i thot\u00eb sistemit t\u00eb skedar\u00ebve: \"Duhet ta regjistrosh k\u00ebt\u00eb n\u00eb memorien q\u00eb nuk humbet energjin\u00eb, <i>Qiraja e serverit Windows VPS<\/i>, dhe deri at\u00ebher\u00eb nuk mund t\u00eb b\u00ebj asgj\u00eb tjet\u00ebr\". Prandaj, shkrimet sinkronike duhet t\u00eb regjistrohen menj\u00ebher\u00eb n\u00eb disk - dhe n\u00ebse kjo rrit fragmentimin ose zvog\u00eblon kapacitetin, ashtu qoft\u00eb.<\/p>\n<p>ZFS e trajton shkrimin sinkronik ndryshe nga sistemet e zakonshme t\u00eb skedar\u00ebve - n\u00eb vend q\u00eb t'i derdh\u00eb ato menj\u00ebher\u00eb n\u00eb ruajtjen e zakonshme, ZFS i regjistron ato n\u00eb nj\u00eb zon\u00eb t\u00eb ve\u00e7ant\u00eb t\u00eb ruajtjes, e cila quhet Dita e Q\u00ebllimit ZFS - ZFS Intent Log, ose ZIL. Truku \u00ebsht\u00eb q\u00eb k\u00ebto shkrime <i>p\u00ebrve\u00e7<\/i> q\u00ebndrojn\u00eb n\u00eb memorie, duke u agreguar bashk\u00eb me k\u00ebrkesat e zakonshme asinkronike p\u00ebr shkrim, p\u00ebr t'u derdhur m\u00eb von\u00eb n\u00eb ruajtje si TXG t\u00eb zakonsh\u00ebm (grupet e transaksionit, Transaction Groups).<\/p>\n<p>N\u00eb m\u00ebnyr\u00ebn normale t\u00eb funksionimit, ZIL regjistrohet dhe kurr\u00eb m\u00eb nuk lexohet. Kur pas disa \u00e7astesh shkrimet nga ZIL regjistrohen n\u00eb ruajtjen kryesore n\u00eb TXG t\u00eb zakonshme nga memoria, ato shk\u00ebputen nga ZIL. E vetmja her\u00eb q\u00eb di\u00e7ka lexohesh nga ZIL \u00ebsht\u00eb gjat\u00eb importit t\u00eb grupit.<\/p>\n<p>N\u00ebse ndodh nj\u00eb d\u00ebshtim ZFS - d\u00ebshtim i sistemit operativ ose humbje energjie - kur ka t\u00eb dh\u00ebna n\u00eb ZIL, k\u00ebto t\u00eb dh\u00ebna do t\u00eb lexohen gjat\u00eb importit t\u00eb ardhsh\u00ebm t\u00eb grupit (p.sh., kur sistemi rikthehet pas nj\u00eb d\u00ebshtimi). \u00c7do gj\u00eb q\u00eb ndodhet n\u00eb ZIL do t\u00eb lexohet, do t\u00eb bashkohet n\u00eb grupet TXG, do t\u00eb regjistrohet n\u00eb ruajtjen kryesore dhe pastaj do t\u00eb shk\u00ebputet nga ZIL n\u00eb procesin e importit.<\/p>\n<p>Nj\u00eb nga klasat ndihm\u00ebse vdev quhet LOG ose SLOG, pajisja sekondare LOG. Ai ka nj\u00eb detyr\u00eb t\u00eb vetme \u2014 t\u00eb ofroj\u00eb nj\u00eb vdev t\u00eb ve\u00e7ant\u00eb dhe, preferohet, shum\u00eb m\u00eb t\u00eb shpejt\u00eb, me nj\u00eb q\u00ebndrueshm\u00ebri shum\u00eb t\u00eb lart\u00eb n\u00eb shkrim, p\u00ebr t\u00eb ruajtur ZIL, n\u00eb vend q\u00eb t\u00eb ruaj\u00eb ZIL n\u00eb depozit\u00ebn kryesore vdev. ZIL vet\u00eb sillet n\u00eb t\u00eb nj\u00ebjt\u00ebn m\u00ebnyr\u00eb pavar\u00ebsisht nga vendi i ruajtjes, por n\u00ebse vdev me LOG ka nj\u00eb performanc\u00eb shum\u00eb t\u00eb lart\u00eb t\u00eb shkrimit, at\u00ebher\u00eb shkrimet sincronike do t\u00eb ndodhin m\u00eb shpejt.<\/p>\n<p>Shtimi i vdev me LOG n\u00eb rezervuar nuk do <b>nuk mund<\/b> t\u00eb p\u00ebrmir\u00ebsoj\u00eb performanc\u00ebn e shkrimit asinkron \u2014 madje edhe n\u00ebse ju detyroni t\u00eb ekzekutoni t\u00eb gjitha shkrimet n\u00eb ZIL me an\u00eb t\u00eb <code>zfs set sync=always<\/code>, ato do t\u00eb jen\u00eb gjithsesi t\u00eb lidhura me depozit\u00ebn 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 ditar. P\u00ebrmir\u00ebsimi i vet\u00ebm direkt i performanc\u00ebs \u00ebsht\u00eb koha e vones\u00ebs s\u00eb shkrimit sinkron (pasi shpejt\u00ebsia m\u00eb e lart\u00eb e ditarit p\u00ebrshpejton ekzekutimin e operacioneve. <code>sync<\/code>).<\/p>\n<p>Megjithat\u00eb, n\u00eb nj\u00eb mjedis q\u00eb tashm\u00eb k\u00ebrkon nj\u00eb num\u00ebr t\u00eb madh shkrimesh sinkron, vdev LOG mund t\u00eb p\u00ebrshpejtoj\u00eb n\u00eb m\u00ebnyr\u00eb indirekte shkrimet asinkrone dhe leximet e pa-cache. Shkarkimi i shkrimeve 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 depozit\u00ebn primare, \u00e7ka ndihmon disi p\u00ebrmir\u00ebsimin e performanc\u00ebs s\u00eb t\u00eb gjitha operacioneve t\u00eb leximit dhe shkrimit.<\/p>\n<h3>Snapshotet<\/h3>\n<p>\nMekanizmi i kopjimit n\u00eb shkrim gjithashtu \u00ebsht\u00eb nj\u00eb baz\u00eb e nevojshme p\u00ebr snapshotet atomike ZFS dhe replikimin inkremental asinkron. N\u00eb nj\u00eb sistem aktiv skedar\u00ebsh ka nj\u00eb pem\u00eb treguesish q\u00eb tregon t\u00eb gjitha shkrimet me t\u00eb dh\u00ebnat aktuale \u2014 kur b\u00ebni nj\u00eb snapshot, thjesht b\u00ebni nj\u00eb kopje t\u00eb k\u00ebsaj peme treguesish.<\/p>\n<p>Kur n\u00eb nj\u00eb sistem aktiv t\u00eb skedar\u00ebve rishkruhet nj\u00eb shkrim, ZFS s\u00eb pari shkruan versionin e ri t\u00eb bllokut n\u00eb hap\u00ebsir\u00ebn e pap\u00ebrdorur. Pastaj ndan versionin e vjet\u00ebr t\u00eb bllokut nga sistemi i skedar\u00ebve aktual. Por n\u00ebse ndonj\u00eb snapshot i referohet bllokut t\u00eb vjet\u00ebr, ai mbetet gjithsesi i pandryshuar. Blloku i vjet\u00ebr n\u00eb fakt nuk do t\u00eb rikuperohet si hap\u00ebsir\u00eb e lir\u00eb derisa t\u00eb gjitha snapshotet q\u00eb i referohen k\u00ebtij blloku t\u00eb shkat\u00ebrrohen!<\/p>\n<h3>Replikimi<\/h3>\n<p>\n<img decoding=\"async\" alt=\"Bazat e ZFS: sistemi i ruajtjes dhe performanca\" src=\"\/wp-content\/uploads\/2020\/06\/647fe6cc348861b653b004640244cf88.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Biblioteka ime e Steam n\u00eb vitin 2015 zinte 158 GiB dhe p\u00ebrfshinte 126,927 skedar\u00eb. Kjo \u00ebsht\u00eb mjaft af\u00ebr situat\u00ebs optimale p\u00ebr rsync \u2014 replikimi i ZFS p\u00ebrmes rrjetit ishte \"vet\u00ebm\" 750% m\u00eb i shpejt\u00eb.<\/i><\/p>\n<p><img decoding=\"async\" alt=\"Bazat e ZFS: sistemi i ruajtjes dhe performanca\" src=\"\/wp-content\/uploads\/2020\/06\/2849be8d2dc5c9f30f23c3bbc20e9022.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>N\u00eb t\u00eb nj\u00ebjt\u00ebn rrjet, riprodhimi i nj\u00eb skedari imazhi virtual t\u00eb makin\u00ebs Windows 7 me kapacitet 40 GiB \u00ebsht\u00eb nj\u00eb histori krejt tjet\u00ebr. Riprodhimi ZFS ndodh 289 her\u00eb m\u00eb shpejt se rsync \u2013 ose \"vet\u00ebm\" 161 her\u00eb m\u00eb shpejt, n\u00ebse jeni mjaft t\u00eb zgjuar t\u00eb thirrni rsync me \u00e7el\u00ebsin --inplace.<\/i><\/p>\n<p><img decoding=\"async\" alt=\"Bazat e ZFS: sistemi i ruajtjes dhe performanca\" src=\"\/wp-content\/uploads\/2020\/06\/9a57e4faa0eaf0f687ae24b965a1bf81.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Kur imazhi i makin\u00ebs virtuale zmadhohet, problemet e rsync zmadhohen gjithashtu me t\u00eb. Madh\u00ebsia 1.9 TiB nuk \u00ebsht\u00eb aq e madhe p\u00ebr nj\u00eb imazh virtual t\u00eb makin\u00ebs moderne \u2013 por \u00ebsht\u00eb e mjaftueshme q\u00eb riprodhimi ZFS t\u00eb rezultoj\u00eb 1148 her\u00eb m\u00eb shpejt se rsync, edhe me argumentin rsync --inplace.<\/i><\/p>\n<p>Sa her\u00eb q\u00eb kuptoni se si funksionojn\u00eb snapshot-et, do t\u00eb jet\u00eb e leht\u00eb t\u00eb kuptoni thelbin e replikimit. Pasi snapshot-i \u00ebsht\u00eb thjesht nj\u00eb pem\u00eb treguesish p\u00ebr regjistrimet, kjo n\u00ebnkupton se n\u00ebse b\u00ebjm\u00eb <code>zfs send<\/code> snapshot, ne d\u00ebrgojm\u00eb k\u00ebt\u00eb pem\u00eb dhe t\u00eb gjitha regjistrimet e lidhura me t\u00eb. Kur e kalojm\u00eb k\u00ebt\u00eb <code>zfs send<\/code> n\u00eb <code>zfs receive<\/code> n\u00eb objektin e synimit, ai shkruan si p\u00ebrmbajtjen faktike t\u00eb bllokut, ashtu edhe pem\u00ebn e treguesve q\u00eb referohen n\u00eb blloqet, n\u00eb grupin e t\u00eb dh\u00ebnave t\u00eb synimit.<\/p>\n<p>Gj\u00ebrat b\u00ebhen edhe m\u00eb interesante n\u00eb t\u00eb dytin <code>zfs send<\/code>. Tani kemi dy sisteme, secila prej t\u00eb cilave p\u00ebrmban <code>poolname\/datasetname@1<\/code>, nd\u00ebrsa po merrni nj\u00eb snapshot t\u00eb ri <code>poolname\/datasetname@2.<\/code>Prandaj, n\u00eb grupin burimor keni <code>datasetname@1<\/code> dhe <code>datasetname@2<\/code>, nd\u00ebrsa n\u00eb grupin e synimit p\u00ebr momentin vet\u00ebm snapshot-i i par\u00eb. <code>datasetname@1<\/code>.<\/p>\n<p>Duke qen\u00eb se kemi nj\u00eb snapshot t\u00eb p\u00ebrbashk\u00ebt midis burimit dhe q\u00ebllimit, ne mund t\u00eb b\u00ebjm\u00eb <code>datasetname@1<\/code>inkrementale <i>mbi t\u00eb. Kur i themi sistemit<\/i> <code>zfs send<\/code> zfs send -i poolname\/datasetname@1 poolname\/datasetname@2 <code>, ai krahason dy pem\u00eb treguesish. \u00c7do tregues q\u00eb ekziston vet\u00ebm n\u00eb<\/code>, referohet qart\u00eb n\u00eb blloqe t\u00eb reja - prandaj na nevojitet p\u00ebrmbajtja e k\u00ebtyre blloqeve. <code>@2<\/code>N\u00eb sistemin e larg\u00ebt, procesi i inkrementaleve<\/p>\n<p>\u00ebsht\u00eb po aq i thjesht\u00eb. S\u00eb pari, shkruajm\u00eb t\u00eb gjitha regjistrimet e reja t\u00eb p\u00ebrfshira n\u00eb kanalin <code>d\u00ebrgo<\/code> , e m\u00eb pas shtojm\u00eb treguesit p\u00ebr k\u00ebto blloqe. Vua, kemi <code>d\u00ebrgo<\/code>n\u00eb sistemin e ri! <code>@2<\/code> Replikimi asinkron inkremental i ZFS \u00ebsht\u00eb nj\u00eb p\u00ebrmir\u00ebsim t\u00eb madh krahasuar me metodat e m\u00ebparshme q\u00eb nuk b\u00ebjn\u00eb p\u00ebrdorim t\u00eb snapshot-eve, si rsync. N\u00eb t\u00eb dy rastet, transferohen vet\u00ebm t\u00eb dh\u00ebnat e ndryshuara - por rsync duhet s\u00eb pari<\/p>\n<p>nga disku t\u00eb gjitha t\u00eb dh\u00ebnat nga t\u00eb dyja an\u00ebt p\u00ebr t\u00eb verifikuar shum\u00ebn dhe p\u00ebr ta krahasuar at\u00eb. Ndryshe nga kjo, replikimi ZFS nuk lexon asgj\u00eb p\u00ebrve\u00e7 pem\u00ebve t\u00eb treguesve - dhe blloqeve t\u00eb \u00e7do lloji q\u00eb nuk jan\u00eb t\u00eb paraqitura n\u00eb snapshot-in e p\u00ebrbashk\u00ebt. <i>lexohet<\/i> nga disk, t\u00eb gjitha t\u00eb dh\u00ebnat nga t\u00eb dyja an\u00ebt, p\u00ebr t\u00eb kontrolluar shum\u00ebn dhe p\u00ebr ta krahasuar at\u00eb. Ndryshe nga kjo, replikimi ZFS nuk lexon asgj\u00eb, p\u00ebrve\u00e7 pem\u00ebve t\u00eb treguesve \u2014 dhe \u00e7do blloku q\u00eb nuk paraqitet n\u00eb snapshots e p\u00ebrbashk\u00ebta.<\/p>\n<h3>Shtypja e integruar<\/h3>\n<p>\nMekanizmi i kopjimit gjat\u00eb shkrimit gjithashtu thjeshton sistemin e shtypjes s\u00eb integruar. N\u00eb sistemet tradicionale t\u00eb skedar\u00ebve, shtypja \u00ebsht\u00eb problematike - si versioni i vjet\u00ebr ashtu edhe versioni i ri i t\u00eb dh\u00ebnave t\u00eb modifikuara ndodhen n\u00eb t\u00eb nj\u00ebjtin hap\u00ebsir\u00eb.<\/p>\n<p>N\u00ebse shqyrtojm\u00eb nj\u00eb fragment t\u00eb t\u00eb dh\u00ebnave n\u00eb mes t\u00eb skedarit, i cili fillon jet\u00ebn e tij si nj\u00eb megabajt zero nga 0x00000000 e m\u00eb pas - \u00ebsht\u00eb shum\u00eb e leht\u00eb ta shtypim k\u00ebt\u00eb n\u00eb nj\u00eb sektor n\u00eb disk. Por \u00e7far\u00eb do t\u00eb ndodh\u00eb n\u00ebse ne z\u00ebvend\u00ebsojm\u00eb k\u00ebt\u00eb megabajt zerosh me nj\u00eb megabajt t\u00eb dh\u00ebnash q\u00eb nuk mund t\u00eb shtypen, si JPEG ose zhurm\u00eb pseudo-rast\u00ebsore? Papritmas, ky megabajt t\u00eb dh\u00ebnash do t\u00eb k\u00ebrkoj\u00eb jo nj\u00eb, por 256 sektor\u00eb me 4 KiB, nd\u00ebrsa n\u00eb k\u00ebt\u00eb vend t\u00eb diskut \u00ebsht\u00eb rezervuar vet\u00ebm nj\u00eb sektor.<\/p>\n<p>ZFS nuk ka nj\u00eb problem t\u00eb till\u00eb, pasi t\u00eb dh\u00ebnat e modifikuara gjithmon\u00eb shkruhen n\u00eb hap\u00ebsir\u00eb t\u00eb pavendosur - blloku origjinal z\u00eb vet\u00ebm nj\u00eb sektor 4 KiB, nd\u00ebrsa shenja e re do t\u00eb marr\u00eb 256, por kjo nuk \u00ebsht\u00eb problem - fragmenti i sapo modifikuar nga \"mes\" i skedarit do t\u00eb shkruhej n\u00eb hap\u00ebsir\u00eb t\u00eb pavendosur pavar\u00ebsisht n\u00ebse ka ndryshuar ose jo, prandaj p\u00ebr ZFS kjo \u00ebsht\u00eb nj\u00eb situat\u00eb krejt normale.<\/p>\n<p>Shtypja e integruar ZFS \u00ebsht\u00eb e \u00e7aktivizuar si parazgjedhje dhe sistemi ofron algoritme t\u00eb lidhura - aktualisht p\u00ebrfshijn\u00eb LZ4, gzip (1-9), LZJB dhe ZLE.<\/p>\n<ul>\n<li><b>LZ4<\/b> \u2014 \u00ebsht\u00eb nj\u00eb algorit\u00ebm i rrjedhsh\u00ebm, duke ofruar shtypje dhe dekompresim jasht\u00ebzakonisht t\u00eb shpejt\u00eb dhe p\u00ebrfitime n\u00eb performanc\u00eb p\u00ebr shumic\u00ebn e rasteve t\u00eb p\u00ebrdorimit - madje edhe n\u00eb CPU relativisht t\u00eb ngadalta.\n<\/li>\n<li><b>GZIP<\/b> \u2014 nj\u00eb algorit\u00ebm i njohur, i dashur nga t\u00eb gjith\u00eb p\u00ebrdoruesit e sistemeve Unix. Ai mund t\u00eb realizohet me nivele shtypjeje 1-9, me rritjen e shkall\u00ebs s\u00eb shtypjes dhe p\u00ebrdorimit t\u00eb CPU-te nd\u00ebrkoh\u00eb q\u00eb i afrohet nivelit 9. Algoritmi \u00ebsht\u00eb i p\u00ebrshtatsh\u00ebm p\u00ebr t\u00eb gjitha variantet e p\u00ebrdorimit t\u00eb teksteve (ose t\u00eb tjera q\u00eb mund t\u00eb kompresohen shum\u00eb), por p\u00ebrndryshe shpesh shkakton probleme me CPU - p\u00ebrdoreni me kujdes, ve\u00e7an\u00ebrisht n\u00eb nivelet m\u00eb t\u00eb larta.\n<\/li>\n<li><b>LZJB<\/b> \u2014 algoritmi origjinal n\u00eb ZFS. Ai \u00ebsht\u00eb i tejkaluar dhe nuk duhet t\u00eb p\u00ebrdoret m\u00eb, LZ4 e tejkalon at\u00eb n\u00eb \u00e7do aspekt.\n<\/li>\n<li><b>ZLE<\/b> \u2014 kodimi i nivelit zero, Zero Level Encoding. Ai n\u00eb p\u00ebrgjith\u00ebsi nuk prek t\u00eb dh\u00ebnat normale, por kompreson sekuenca t\u00eb m\u00ebdha zeros. E dobishme p\u00ebr grupe t\u00eb dh\u00ebnash plot\u00ebsisht t\u00eb padihet (p.sh., JPEG, MP4 ose formate t\u00eb tjera q\u00eb jan\u00eb tashm\u00eb kompaktuar), pasi injoron t\u00eb dh\u00ebnat e pa kompresuara, por kompreson hap\u00ebsir\u00ebn e pap\u00ebrdorur n\u00eb regjistrat p\u00ebrfundimtar\u00eb.<\/li>\n<\/ul>\n<p>\nNe rekomandojm\u00eb kompresimin LZ4 p\u00ebr pothuajse t\u00eb gjitha rastet e p\u00ebrdorimit; nd\u00ebshkimi p\u00ebr performanc\u00ebn kur haset me t\u00eb dh\u00ebna t\u00eb pa kompresuara \u00ebsht\u00eb shum\u00eb i vog\u00ebl, dhe <i>e ndjeshme<\/i> performanca p\u00ebr t\u00eb dh\u00ebnat tipike \u00ebsht\u00eb e r\u00ebnd\u00ebsishme. Kopjimi i imazhit t\u00eb makin\u00ebs virtuale p\u00ebr nj\u00eb instalim t\u00eb ri t\u00eb sistemit operativ Windows (sistem operativ i sapoinstaluar, pa t\u00eb dh\u00ebna brenda akoma) me <code>compression=lz4<\/code> ka kaluar 27% m\u00eb shpejt se me <code>compression=none<\/code>, n\u00eb <noindex><a rel=\"nofollow\" href=\"https:\/\/jrs-s.net\/2015\/02\/24\/zfs-compression-yes-you-want-this\/\">k\u00ebtu n\u00eb testin e vitit 2015<\/a><\/noindex>.<\/p>\n<h1>ARC \u2014 z\u00ebvend\u00ebsimi adaptiv i caches<\/h1>\n<p>\nZFS \u00ebsht\u00eb e vetmja sistem files moderne q\u00eb dim\u00eb q\u00eb p\u00ebrdor mekanizmin e vet t\u00eb p\u00ebrmir\u00ebsimit t\u00eb leximin, dhe nuk mb\u00ebshtetet n\u00eb caches t\u00eb faqeve t\u00eb sistemit operativ p\u00ebr t\u00eb mbajtur kopje t\u00eb blloqeve t\u00eb lexuara rishtazi n\u00eb memoria RAM.<\/p>\n<p>Megjith\u00ebse cache-ja e vet nuk \u00ebsht\u00eb pa problemet e saj \u2014 ZFS nuk mund t\u00eb reagoj\u00eb p\u00ebr k\u00ebrkesat e reja p\u00ebr ndarje memories aq shpejt sa b\u00ebrthama, k\u00ebshtu q\u00eb nj\u00eb thirrje e re <code>malloc()<\/code> p\u00ebr ndarjen e memories mund t\u00eb d\u00ebshtoj\u00eb, n\u00ebse i nevojitet memoria RAM e z\u00ebn\u00eb aktualisht nga ARC. Por ka arsye t\u00eb forta p\u00ebr t\u00eb p\u00ebrdorur cache-n\u00eb e vet, t\u00eb pakt\u00ebn tani.<\/p>\n<p>T\u00eb gjitha sistemet operative moderne, p\u00ebrfshir\u00eb MacOS, Windows, Linux dhe BSD, p\u00ebrdorin algoritmin LRU (M\u00eb pak frekuent p\u00ebrdorur) p\u00ebr t\u00eb zbatuar caches t\u00eb faqeve. Ky \u00ebsht\u00eb nj\u00eb algorit\u00ebm primitiv, i cili rrit bllokun e cache-t \"lart n\u00eb rend\" pas \u00e7do leximi dhe hedh blloqet \"posht\u00eb n\u00eb rend\" sipas nevoj\u00ebs, p\u00ebr t\u00eb shtuar humbjet e reja t\u00eb caches (blloqet q\u00eb duhet t\u00eb jen\u00eb lexuar nga disku, e jo nga cache) lart.<\/p>\n<p>Zakonisht algoritmi funksionon mir\u00eb, por n\u00eb sisteme me grupe t\u00eb m\u00ebdha t\u00eb dh\u00ebnash, LRU leht\u00eb t\u00eb \u00e7oj\u00eb n\u00eb treshing \u2014 heqjen e blloqeve q\u00eb nevojiten shpesh, p\u00ebr t\u00eb liruar hap\u00ebsir\u00eb p\u00ebr blloqet q\u00eb kurr\u00eb m\u00eb nuk do t\u00eb lexohen nga cache.<\/p>\n<p><noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Adaptive_replacement_cache\">ARC<\/a><\/noindex>\u00a0\u2014 nj\u00eb algorit\u00ebm shum\u00eb m\u00eb pak naiv, i cili mund t\u00eb konsiderohet si nj\u00eb memorie 'e peshkuar'. Pas \u00e7do leximi t\u00eb bllokut t\u00eb caches, ai b\u00ebhet pak 'm\u00eb i r\u00ebnd\u00eb' dhe b\u00ebhet m\u00eb e v\u00ebshtir\u00eb t\u00eb d\u00ebshtohet - dhe madje edhe pas d\u00ebshtimit, blloku <i>ndiqet<\/i> p\u00ebr nj\u00eb periudh\u00eb t\u00eb caktuar kohe. Nj\u00eb bllok q\u00eb \u00ebsht\u00eb d\u00ebbuar, por pastaj duhet t\u00eb lexohet p\u00ebrs\u00ebri n\u00eb cache, gjithashtu do t\u00eb b\u00ebhet 'm\u00eb i r\u00ebnd\u00eb'.<\/p>\n<p>Si rezultat i gjith\u00eb k\u00ebtyre \u00ebsht\u00eb nj\u00eb cache me nj\u00eb raport shum\u00eb m\u00eb t\u00eb lart\u00eb hit (hit ratio) - raporti midis goditjeve n\u00eb cache (leximi, q\u00eb b\u00ebhet nga cache) dhe humbjeve (leximi nga disku). Kjo \u00ebsht\u00eb nj\u00eb statistik\u00eb tep\u00ebr e r\u00ebnd\u00ebsishme - jo vet\u00ebm q\u00eb vet\u00eb hitet e cache sh\u00ebrbehen me rend t\u00eb shpejt\u00eb, humbjet e caches gjithashtu mund t\u00eb sh\u00ebrbehen m\u00eb shpejt, pasi sa m\u00eb shum\u00eb hitet n\u00eb cache - aq m\u00eb pak k\u00ebrkesa paralel p\u00ebr disk dhe aq m\u00eb pak vones\u00eb p\u00ebr ato humbje t\u00eb mbetura q\u00eb duhet t\u00eb sh\u00ebrbehen nga disku.<\/p>\n<h1>P\u00ebrfundim<\/h1>\n<p>\nPas studimit t\u00eb semantik\u00ebs themelore t\u00eb ZFS - se si funksionon kopjimi n\u00eb shkrim, si dhe marr\u00ebdh\u00ebniet midis grupeve t\u00eb ruajtjes, pajisjeve virtuale, blloqeve, sector\u00ebve dhe skedar\u00ebve - ne jemi gati t\u00eb diskutojm\u00eb performanc\u00ebn reale me numra real\u00eb.<\/p>\n<p>N\u00eb pjes\u00ebn tjet\u00ebr do t\u00eb shqyrtojm\u00eb performanc\u00ebn faktike t\u00eb grupeve me vdev t\u00eb pasqyruar dhe RAIDz, nj\u00ebri n\u00eb krahasim me tjetrin, si dhe n\u00eb krahasim me topologjit\u00eb tradicionale t\u00eb RAID t\u00eb b\u00ebrtham\u00ebs Linux, t\u00eb cilat kemi eksploruar <noindex><a rel=\"nofollow\" href=\"https:\/\/arstechnica.com\/information-technology\/2020\/04\/understanding-raid-how-performance-scales-from-one-disk-to-eight\/\">m\u00eb par\u00eb<\/a><\/noindex>.<\/p>\n<p>Fillimisht ne donim t\u00eb shqyrtonim vet\u00ebm elementet baz\u00eb - vet\u00eb topologjit\u00eb ZFS - por pas <i>e nj\u00eb<\/i> do t\u00eb jemi gati t\u00eb flasim p\u00ebr konfigurimin dhe rregullimin m\u00eb t\u00eb avancuar t\u00eb ZFS, duke p\u00ebrfshir\u00eb p\u00ebrdorimin e llojeve ndihm\u00ebse t\u00eb vdev, si L2ARC, SLOG dhe Special Allocation.<br \/>\n<br \/>Burimi: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/504692\/\">habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u042d\u0442\u043e\u0439 \u0432\u0435\u0441\u043d\u043e\u0439 \u043c\u044b \u0443\u0436\u0435 \u043e\u0431\u0441\u0443\u0434\u0438\u043b\u0438 \u043d\u0435\u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u0432\u0432\u043e\u0434\u043d\u044b\u0435 \u0442\u0435\u043c\u044b, \u043d\u0430\u043f\u0440\u0438\u043c\u0435\u0440, \u043a\u0430\u043a \u043f\u0440\u043e\u0432\u0435\u0440\u0438\u0442\u044c \u0441\u043a\u043e\u0440\u043e\u0441\u0442\u044c \u0432\u0430\u0448\u0438\u0445 \u0434\u0438\u0441\u043a\u043e\u0432 \u0438 \u0447\u0442\u043e \u0442\u0430\u043a\u043e\u0435 RAID. \u0412\u043e \u0432\u0442\u043e\u0440\u043e\u0439 \u0438\u0437 \u043d\u0438\u0445 \u043c\u044b \u0434\u0430\u0436\u0435 \u043f\u043e\u043e\u0431\u0435\u0449\u0430\u043b\u0438 \u043f\u0440\u043e\u0434\u043e\u043b\u0436\u0438\u0442\u044c \u0438\u0437\u0443\u0447\u0435\u043d\u0438\u0435 \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u044c\u043d\u043e\u0441\u0442\u0438 \u0440\u0430\u0437\u043b\u0438\u0447\u043d\u044b\u0445 \u043c\u043d\u043e\u0433\u043e\u0434\u0438\u0441\u043a\u043e\u0432\u044b\u0445 \u0442\u043e\u043f\u043e\u043b\u043e\u0433\u0438\u0439 \u0432 ZFS. \u042d\u0442\u043e \u0444\u0430\u0439\u043b\u043e\u0432\u0430\u044f \u0441\u0438\u0441\u0442\u0435\u043c\u0430 \u0441\u043b\u0435\u0434\u0443\u044e\u0449\u0435\u0433\u043e \u043f\u043e\u043a\u043e\u043b\u0435\u043d\u0438\u044f, \u043a\u043e\u0442\u043e\u0440\u0430\u044f \u0441\u0435\u0439\u0447\u0430\u0441 \u0432\u043d\u0435\u0434\u0440\u044f\u0435\u0442\u0441\u044f \u043f\u043e\u0432\u0441\u044e\u0434\u0443: \u043e\u0442 Apple \u0434\u043e Ubuntu. \u041d\u0443 \u0447\u0442\u043e \u0436, \u0441\u0435\u0433\u043e\u0434\u043d\u044f \u0441\u0430\u043c\u044b\u0439 \u043f\u043e\u0434\u0445\u043e\u0434\u044f\u0449\u0438\u0439 \u0434\u0435\u043d\u044c \u0434\u043b\u044f \u0437\u043d\u0430\u043a\u043e\u043c\u0441\u0442\u0432\u0430 [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":83583,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-83582","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.2.1 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u042d\u0442\u043e\u0439 \u0432\u0435\u0441\u043d\u043e\u0439 \u043c\u044b \u0443\u0436\u0435 \u043e\u0431\u0441\u0443\u0434\u0438\u043b\u0438 \u043d\u0435\u043a\u043e\u0442\u043e\u0440\u044b\u0435.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/sq\/blog\/administrirovanie\/osnovy-zfs-sistema-hraneniya-i-proizvoditelnost\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.2.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"sq_AL\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u041e\u0441\u043d\u043e\u0432\u044b ZFS: \u0441\u0438\u0441\u0442\u0435\u043c\u0430 \u0445\u0440\u0430\u043d\u0435\u043d\u0438\u044f \u0438 \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u044c\u043d\u043e\u0441\u0442\u044c | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u042d\u0442\u043e\u0439 \u0432\u0435\u0441\u043d\u043e\u0439 \u043c\u044b \u0443\u0436\u0435 \u043e\u0431\u0441\u0443\u0434\u0438\u043b\u0438 \u043d\u0435\u043a\u043e\u0442\u043e\u0440\u044b\u0435.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/sq\/blog\/administrirovanie\/osnovy-zfs-sistema-hraneniya-i-proizvoditelnost\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2020-06-01T17:42:21+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-06-01T17:42:21+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47T\u00eb Dh\u00ebnat e ZFS: sistemi i ruajtjes dhe performanca | ProHoster","description":"K\u00ebt\u00eb pranver\u00eb ne kemi diskutuar tashm\u00eb disa.","canonical_url":"https:\/\/prohoster.info\/sq\/blog\/administrirovanie\/osnovy-zfs-sistema-hraneniya-i-proizvoditelnost","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"sq_AL","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u041e\u0441\u043d\u043e\u0432\u044b ZFS: \u0441\u0438\u0441\u0442\u0435\u043c\u0430 \u0445\u0440\u0430\u043d\u0435\u043d\u0438\u044f \u0438 \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u044c\u043d\u043e\u0441\u0442\u044c | ProHoster","og:description":"\u042d\u0442\u043e\u0439 \u0432\u0435\u0441\u043d\u043e\u0439 \u043c\u044b \u0443\u0436\u0435 \u043e\u0431\u0441\u0443\u0434\u0438\u043b\u0438 \u043d\u0435\u043a\u043e\u0442\u043e\u0440\u044b\u0435.","og:url":"https:\/\/prohoster.info\/sq\/blog\/administrirovanie\/osnovy-zfs-sistema-hraneniya-i-proizvoditelnost","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-06-01T17:42:21+00:00","article:modified_time":"2020-06-01T17:42:21+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"83582","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 15:14:37","updated":"2022-09-28 10:00:57","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/posts\/83582","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/comments?post=83582"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/posts\/83582\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/media\/83583"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/media?parent=83582"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/categories?post=83582"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/tags?post=83582"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}