Këtë pranverë ne kemi diskutuar disa tema hyrëse, për shembull, dhe . Në të dytën, ne madje premtuam të vazhdojmë studimin e performancës së topologjive të ndryshme me shumë disqe në ZFS. Kjo është një sistem skedarësh të ardhshme që tani po implementohet kudo: nga në .
Epo, sot është dita më e përshtatshme për t'u njohur me ZFS, lexues të kureshëm. Thjesht dinë se, sipas një vlerësimi modest të zhvilluesit të OpenZFS, Matt Arens, 'është vërtet e komplikuar.'
Por para se tĂ« arrijmĂ« te numrat â dhe ata do tĂ« jenĂ«, e premtoj â pĂ«r tĂ« gjitha opsionet e konfigurimit me tetĂ« disqe nĂ« ZFS, duhet tĂ« flasim pĂ«r atĂ« si si ZFS i ruan tĂ« dhĂ«nat nĂ« disk.
Zpool, vdev dhe device
Ky diagram i rezervuarit të plotë përfshin tre vdev të ndihmës, një nga çdo klasë, dhe katër për RAIDz2
Zakonisht nuk ka arsye pĂ«r tĂ« krijuar njĂ« rezervuar nga lloje dhe dimensione tĂ« papajtueshme vdev â por nĂ«se dĂ«shironi, asgjĂ« nuk ju pengon tĂ« bĂ«ni kĂ«tĂ«
Për të kuptuar vërtet sistemin e skedarëve ZFS, duhet të shikoni me kujdes në strukturën e saj reale. Së pari, ZFS bashkon nivelet tradicionale të menaxhimit të volumit dhe sistemit të skedarëve. Së dyti, ajo përdor një mekanizëm transaksional të kopjimit në shkrim. Këto veçori do të thotë që sistemi është strukturalisht shumë i ndryshëm nga sistemet e zakonshme të skedarëve dhe grupeve RAID. Grupi i parë i blloqeve themelore për të kuptuar: është rezervuari i ruajtjes (zpool), aparati virtual (vdev) dhe aparati i vërtetë (device).
zpool
Rezervuari i ruajtjes zpool â struktura mĂ« e lartĂ« e ZFS. Ădo rezervuar pĂ«rmban njĂ« ose mĂ« shumĂ« aparate virtuale. NdĂ«rsa secili prej tyre pĂ«rmban njĂ« ose mĂ« shumĂ« aparate tĂ« vĂ«rtetĂ« (device). Pulat virtuale janĂ« blloqe autonome. NjĂ« kompjuter fizik mund tĂ« pĂ«rmbajĂ« dy ose mĂ« shumĂ« rezerva tĂ« veçanta, por secili Ă«shtĂ« plotĂ«sisht i pavarur nga tĂ« tjerĂ«t. RezervuarĂ«t nuk mund tĂ« ndajnĂ« aparate virtuale.
Redundanca e ZFS ndodhet nĂ« nivelin e aparateve virtuale, jo nĂ« nivelin e rezervuara. NĂ« nivelin e rezervuara nuk ka asnjĂ« lloj redundance â nĂ«se humbet ndonjĂ« magazinĂ« vdev ose njĂ« vdev tĂ« veçantĂ«, atĂ«herĂ« humbet gjithashtu tĂ« gjithĂ« rezervuarin.
Pulat e ruajtjes moderne mund tĂ« pĂ«rballojnĂ« humbjen e cache-it ose log-Ă«ve tĂ« pajisjeve virtuale â megjithatĂ«, ata mund tĂ« humbin njĂ« sasi tĂ« vogĂ«l tĂ« tĂ« dhĂ«nave tĂ« papastruara nĂ«se humbasin log-un e vdev gjatĂ« njĂ« ndĂ«rlidhjeje ose dĂ«shtimi tĂ« sistemit.
Ekziston një keqkuptim i zakonshëm që "strips" ZFS shkruhen në të gjithë pulin. Kjo është e pasaktë. Zpool nuk është aspak një RAID0 qesharak; është më tepër një me një mekanizëm të ndërlikuar shpërndarjeje.
PĂ«r shumicĂ«n e rasteve, shĂ«nimet shpĂ«rndahen midis pajisjeve virtuale tĂ« disponueshme sipas hapĂ«sirĂ«s sĂ« lirĂ« tĂ« disponueshme, kĂ«shtu qĂ« teorikisht tĂ« gjitha do tĂ« mbushen njĂ«kohĂ«sisht. NĂ« versionet mĂ« tĂ« vonshme tĂ« ZFS, merret parasysh pĂ«rdorimi aktual (utilizimi) i vdev â nĂ«se njĂ« pajisje virtuale Ă«shtĂ« shumĂ« mĂ« e ngarkuar se njĂ« tjetĂ«r (p.sh., pĂ«r shkak tĂ« ngarkesĂ«s sĂ« leximit), ajo do tĂ« shpĂ«rfillĂ«t pĂ«r shkruan, pavarĂ«sisht nga koeficienti mĂ« i lartĂ« i hapĂ«sirĂ«s sĂ« lirĂ«.
Mekanizmi i pĂ«rcaktimit tĂ« pĂ«rdorimit, i ndĂ«rtuar nĂ« metodat moderne tĂ« shpĂ«rndarjes sĂ« shĂ«nimeve ZFS, mund tĂ« reduktojĂ« vonesĂ«n dhe tĂ« rrisĂ« kapacitetin gjatĂ« periudhave tĂ« ngarkesĂ«s sĂ« pazakontĂ« tĂ« lartĂ« â por kjo nuk Ă«shtĂ« kartĂ«-bllok pĂ«r pĂ«rzierjen e pavullnetshme tĂ« HDD-ve tĂ« ngadalshme dhe SSD-ve tĂ« shpejtĂ« nĂ« njĂ« pul. NjĂ« pul i tillĂ«, i pabarabartĂ«, do tĂ« funksionojĂ« gjithsesi me shpejtĂ«sinĂ« e pajisjes mĂ« tĂ« ngadalshme, pra sikur tĂ« ishte krejtĂ«sisht pĂ«rbĂ«rĂ« nga kĂ«to pajisje.
vdev
Ădo pul ruajtjeje pĂ«rbĂ«het nga njĂ« ose disa pajisje virtuale (virtual device, vdev). NĂ« turn, çdo vdev pĂ«rfshin njĂ« ose mĂ« shumĂ« pajisje reale. Shumica e pajisjeve virtuale pĂ«rdoren pĂ«r ruajtjen e thjeshtĂ« tĂ« tĂ« dhĂ«nave, por ekzistojnĂ« disa klasa ndihmĂ«se tĂ« vdev, duke pĂ«rfshirĂ« CACHE, LOG dhe SPECIAL. Ădo nga kĂ«to lloje vdev mund tĂ« ketĂ« njĂ« nga pesĂ« topologjitĂ«: njĂ« pajisje tĂ« vetme (single-device), RAIDz1, RAIDz2, RAIDz3 ose pasqyrĂ« (mirror).
RAIDz1, RAIDz2 dhe RAIDz3 janë variante të veçanta të asaj që dikur njihej si RAID me dyfishim (diagonal). 1, 2 dhe 3 i referohen numrit të bllokjeve të kontrollit të paracaktuar për secilën brez të të dhënave. Në vend të disqeve të veçanta për sigurimin e kontrollit, pajisjet virtuale RAIDz e shpërndajnë këtë kontroll në mënyrë semi-uniforme mes disqeve. Një masiv RAIDz mund të humbasë aq disqe sa ka bllokje kontrolli; nëse humb edhe një tjetër, do të dalë jashtë funksionit dhe do të shkatërrojë gjithashtu rezervatin e ruajtjes.
NĂ« pajisjet virtuale tĂ« pasqyrĂ«s (mirror vdev), çdo bllok ruhet nĂ« çdo pajisje nĂ« vdev. NdĂ«rsa pasqyrat dyfisha (two-wide) janĂ« mĂ« tĂ« zakonshme, mund tĂ« ketĂ« çdo numĂ«r tĂ« rastĂ«sishĂ«m pajisjesh nĂ« pasqyrĂ« â nĂ« instalime tĂ« mĂ«dha pĂ«r tĂ« pĂ«rmirĂ«suar performancĂ«n e leximit dhe qĂ«ndrueshmĂ«rinĂ«, shpesh pĂ«rdoren pasqyra trefish. NjĂ« pasqyrĂ« vdev mund tĂ« mbijetojĂ« çdo dĂ«shtim, pĂ«r sa kohĂ« qĂ« vazhdon tĂ« funksionojĂ« sĂ« paku njĂ« pajisje nĂ« vdev.
Vdev tĂ« vetme nĂ« thelb janĂ« tĂ« rrezikshme. NjĂ« pajisje virtuale e tillĂ« nuk do tĂ« mbijetojĂ« asnjĂ« dĂ«shtim â dhe nĂ«se pĂ«rdoret si ruajtje ose vdev i veçantĂ«, dĂ«shtimi i saj do tĂ« çojĂ« nĂ« shkatĂ«rrimin e tĂ« gjithĂ« rezervatit. Kujdesuni shumĂ« kĂ«tu.
Pajisjet virtuale CACHE, LOG dhe SPECIAL mund tĂ« krijohen sipas ndonjĂ« prej topologjive tĂ« mĂ«sipĂ«rme â por kujtoni se humbja e njĂ« pajisjeje virtuale SPECIAL do tĂ« thotĂ« humbjen e rezervatit, kĂ«shtu qĂ« rekomandohet qĂ« tĂ« ketĂ« njĂ« topologji tĂ« tepĂ«rt.
device
Kjo Ă«shtĂ« ndoshta termi mĂ« i lehtĂ« pĂ«r t'u kuptuar nĂ« ZFS â Ă«shtĂ« literalisht njĂ« pajisje blloku me qasje tĂ« rastĂ«sishme. Kujtoni se pajisjet virtuale pĂ«rbĂ«hen nga pajisje tĂ« veçanta, ndĂ«rsa rezervati pĂ«rbĂ«het nga pajisje virtuale.
Disqet â magnetike ose solid-state â janĂ« pajisjet mĂ« tĂ« zakonshme bllok qĂ« pĂ«rdoren si blloqe ndĂ«rtimi pĂ«r vdev. MegjithatĂ«, çdo pajisje me njĂ« descriptor nĂ« /dev Ă«shtĂ« nĂ« rregull â kĂ«shtu qĂ« gjithashtu mund tĂ« pĂ«rdoren grupe tĂ« plota RAID harduerike si pajisje tĂ« veçanta.
Një skedar raw i thjeshtë është një nga pajisjet alternative më të rëndësishme bllok nga të cilat mund të ndërtohet një vdev. Pulat testuese nga  janë një mënyrë shumë e dobishme për të provuar komandat e rezervatit dhe për të parë sa hapësirë është në dispozicion në rezervat ose pajisjet virtuale të kësaj topologjie.
Mund tĂ« krijoni njĂ« grup testues nga skedarĂ« tĂ« holluar pĂ«r disa sekonda â por mos harroni mĂ« pas tĂ« fshini tĂ« gjithĂ« grupin dhe komponentĂ«t e tij.
Supozoni se dĂ«shironi tĂ« vendosni njĂ« server me tetĂ« disqe dhe planifikoni tĂ« pĂ«rdorni disqe 10 TB (~9300 GiB) â por nuk jeni tĂ« sigurt se cila topologji i pĂ«rshtatet mĂ« sĂ« miri nevojave tuaja. NĂ« shembullin e mĂ«sipĂ«rm, ne krijojmĂ« njĂ« grup testues nga skedarĂ«t e holluar pĂ«r disa sekonda â dhe tani e dimĂ« se njĂ« RAIDz2 vdev me tetĂ« disqe 10 TB siguron 50 TiB kapacitet tĂ« dobishĂ«m.
Një klasë tjetër e veçantë e pajisjeve është SPARE (rezervë). Pajisjet e nxehta të zëvendësimit, ndryshe nga pajisjet e zakonshme, i përkasin të gjithë grupit dhe jo një vdev të vetëm. Nëse ndonjë vdev në grup dështon, dhe pajisja rezervë është e lidhur me grupin dhe e disponueshme, ajo automatikisht do të bashkohet me vdev-in e dëmtuar.
Pas lidhjes me vdev-in e dëmtuar, pajisja rezervë fillon të marrë kopje ose rikonstruksione të të dhënave që duhet të jenë në pajisjen e munguar. Në RAID-in tradicional, kjo quhet rikuperim (rebuilding), ndërsa në ZFS që quhet "rikuperim mbivendësie" (resilvering).
ĂshtĂ« e rĂ«ndĂ«sishme tĂ« theksohet se pajisjet rezervĂ« nuk zĂ«vendĂ«sojnĂ« pĂ«rherĂ« pajisjet qĂ« kanĂ« dĂ«shtuar. Kjo Ă«shtĂ« vetĂ«m njĂ« zĂ«vendĂ«sim i pĂ«rkohshĂ«m pĂ«r tĂ« shkurtuar kohĂ«n gjatĂ« sĂ« cilĂ«s vdev-i Ă«shtĂ« i degraduar. Pas zĂ«vendĂ«simit tĂ« pajisjes sĂ« dĂ«shtuar nga administratori, ndodh rikuperimi i mbivendĂ«sisĂ« nĂ« kĂ«tĂ« pajisje tĂ« pĂ«rhershme, dhe SPARE shkĂ«putet nga vdev-i dhe kthehet nĂ« funksion si rezervĂ« pĂ«r tĂ« gjithĂ« grupin.
Grupet e të dhënave, blloqet dhe sektoret
Grupi tjetĂ«r i blloqeve ndĂ«rtuese qĂ« duhet tĂ« kuptohet nĂ« udhĂ«timin tonĂ« me ZFS, lidhet mĂ« shumĂ« me mĂ«nyrĂ«n se si organizohen dhe ruhen tĂ« dhĂ«nat. Ne kĂ«tu kalojmĂ« disa nivele â si metaslab â pĂ«r tĂ« shmangur grumbullimin e detajeve, duke ruajtur kuptimin e strukturĂ«s sĂ« pĂ«rgjithshme.
Grupi i të dhënave (dataset)
Kur krijojmĂ« pĂ«r herĂ« tĂ« parĂ« njĂ« grup tĂ« dhĂ«nash, ai tregon gjithĂ« hapĂ«sirĂ«n e disponueshme tĂ« grupit. Pastaj ne vendosim njĂ« kuotĂ« â dhe ndryshojmĂ« pikĂ«n e montimit. Magjia!
Zvol është në thelb një grup të dhënash, i cili i mungon layer-in e tij të sistemit të skedarëve, që ne e zëvendësojmë këtu me një sistem të zakonshëm skedarësh si ext4.
Grupi i të dhënave ZFS është afërsisht i ngjashëm me sistemin standard të skedarëve të montuar. Ashtu si një sistem i zakonshëm skedarësh, në pamje të parë duket "thjesht si një tjetër dosje". Por, ashtu si në sistemet e zakonshme të skedarëve të montuar, secili grup të dhënash ZFS ka setin e vet të pronave bazë.
Para së gjithash, një grup të dhënash mund të ketë një kuotë të caktuar. Nëse vendosni zfs set quota=100G poolname/datasetname, atëherë nuk do të jeni në gjendje të shkruani në dosjen e montuar /poolname/datasetname më shumë se 100 GiB.
A keni vĂ«nĂ« re praninĂ« â dhe mungesĂ«n â e ndarĂ«sve nĂ« fillim tĂ« çdo rreshti? Secili grup tĂ« dhĂ«nash ka vendin e tij si nĂ« hierarkinĂ« ZFS, ashtu edhe nĂ« hierarkinĂ« e montimit tĂ« sistemit. NĂ« hierarkinĂ« ZFS nuk ka ndarĂ«s nĂ« fillim â filloni me emrin e pishinĂ«s dhe pastaj rrugĂ«n nga njĂ« grup tĂ« dhĂ«nash nĂ« tjetrin. PĂ«r shembull, pool/parent/child pĂ«r njĂ« grup tĂ« dhĂ«nash me emrin fĂ«mija nĂ«n grupin e dhĂ«nash prind parent nĂ« njĂ« pishinĂ« me njĂ« emĂ«r krijues pool.
NĂ« mĂ«nyrĂ« tĂ« parazgjedhur, pika e montimit tĂ« grupit tĂ« dhĂ«nash do tĂ« jetĂ« ekuivalente me emrin e tij nĂ« hierarkinĂ« ZFS, me njĂ« ndarĂ«s nĂ« fillim â pishina me emrin pool do tĂ« montojĂ« si /pool, grupi i tĂ« dhĂ«nash parent do tĂ« montohet nĂ« /pool/parent, dhe grupi i dhĂ«nash fĂ«mijĂ« fĂ«mija do tĂ« montohet nĂ« /pool/parent/child. MegjithatĂ«, pika e montimit e sistemit pĂ«r grupin e dhĂ«nash mund tĂ« ndryshohet.
Nëse ne përcaktojmë zfs set mountpoint=/lol pool/parent/child, atëherë grupi i dhënash pool/parent/child do të montohet në sistem si /lol.
PĂ«rveç grupeve tĂ« dhĂ«nash, duhet tĂ« pĂ«rmendim volumin (zvols). NjĂ« volum Ă«shtĂ« afĂ«rsisht i ngjashĂ«m me njĂ« grup tĂ« dhĂ«nash, pĂ«rveçse nuk ka nĂ« tĂ« njĂ« sistem skedarĂ«sh â Ă«shtĂ« thjesht njĂ« pajisje blloku. Ju mund, pĂ«r shembull, tĂ« krijoni zvol me emrin mypool/myzvol, pastaj ta formatoni me njĂ« sistem skedarĂ«sh ext4, dhe mĂ« pas ta montoni kĂ«tĂ« sistem skedarĂ«sh â tani keni njĂ« sistem skedarĂ«sh ext4, por me mbĂ«shtetje pĂ«r tĂ« gjitha funksionet e sigurisĂ« ZFS! Kjo mund tĂ« duket e çuditshme nĂ« njĂ« kompjuter, por ka shumĂ« mĂ« shumĂ« kuptim si njĂ« back-end kur eksportoni njĂ« pajisje iSCSI.
Njësi
Skedari pĂ«rfaqĂ«sohet nga njĂ« ose disa blloqe. Ădo bllok ruhet nĂ« njĂ« pajisje virtuale. MadhĂ«sia e bllokut zakonisht Ă«shtĂ« e barabartĂ« me parametrin recordsize, por mund tĂ« ulet nĂ« 2^ashift, nĂ«se pĂ«rmban metadata ose njĂ« skedar tĂ« vogĂ«l.
Ne vërtet, vërtetë nuk e kemi fjalë për dëmin e madh të performancës, nëse vendosni një ashift shumë të vogël
Në grupin ZFS të gjitha të dhënat, duke përfshirë metadatën, ruhen në blloqe. Madhësia maksimale e bllokut për secilën grup të dhënash përcaktohet në pronën recordsize (madhësia e shënimit). Madhësia e shënimit mund të ndryshojë, por kjo nuk do të ndryshojë madhësinë ose pozicionin e ndonjë blloku që është tashmë shkruar në grupin e dhënash - ajo vepron vetëm për blloqet e reja ndërsa shkruhen.
Nëse nuk është përcaktuar ndryshe, madhësia aktuale e shënimit për default është 128 KiB. Ky është një kompromis i caktuar, ku performanca do të jetë as ideale, as e tmerrshme në shumicën e rasteve. Madhësia e shënimit mund të vendoset në çdo vlerë nga 4K deri në 1M (me konfigurime shtesë recordsize mund të vendoset edhe më shumë, por kjo rrallë është një ide e mirë).
Ădo bllok referon vetĂ«m nĂ« tĂ« dhĂ«nat e njĂ« skedari - nuk mund tĂ« futni dy skeda tĂ« ndryshme nĂ« njĂ« bllok. Ădo skedar Ă«shtĂ« i pĂ«rbĂ«rĂ« nga njĂ« ose disa blloqe, varĂ«sisht nga madhĂ«sia. NĂ«se madhĂ«sia e skedarit Ă«shtĂ« mĂ« e vogĂ«l se madhĂ«sia e shĂ«nimit, ai do tĂ« ruhet nĂ« njĂ« bllok mĂ« tĂ« vogĂ«l - pĂ«r shembull, njĂ« bllok me njĂ« skedar 2 KiB do tĂ« marrĂ« vetĂ«m njĂ« sektor 4 KiB nĂ« disk.
Nëse skedari është mjaft i madh dhe kërkon disa blloqe, atëherë të gjitha shënimet me këtë skedar do të kenë madhësinë recordsize - duke përfshirë shënimin përfundimtar, pjesa kryesore e të cilit mund të rezultojë .
Grupet zvol nuk kanë pronë recordsize - përkundrazi, ato kanë një pronë ekuivalente madhësia e bllokut të volumit.
Sektorët
Sektori, blloku më i fundit, më thelbësor. Ky është njësi fizike më e vogël, e cila mund të shkruhet ose lexohet nga pajisja bazë. Gjatë disa dekadash, shumica e disqeve kanë përdorur sektorë prej 512 byte. Kohët e fundit, shumica e disqeve janë konfiguruar për sektorë 4 KiB, dhe në disa - veçanërisht SSD - sektorët 8 KiB ose madje më shumë.
Në sistemin ZFS ekziston një pronë që lejon të vendosni manualisht madhësinë e sektorit. Kjo pronë ashift. Paksa e ngatërruar, që ashift është një fuqi e dyshes. Për shembull, ashift=9 nënkupton madhësinë e sektorit 2^9, ose 512 byte.
ZFS kërkon nga sistemi operativ informacion të detajuar për çdo pajisje bllok, kur ajo shtohet në një vdev të ri, dhe teorikisht e vendos automatikisht ashift në mënyrë të duhur mbi bazën e këtij informacioni. Fatkeqësisht, shumë disqe gënjejnë për madhësinë e tyre të sektorëve për të ruajtur përputhshmërinë me Windows XP (i cili nuk ishte në gjendje të kuptonte disqe me madhësi të tjera sektorësh).
Kjo do të thotë se administratori i ZFS rekomandohet me ngulm të dijë madhësinë e vërtetë të sektorëve të pajisjeve të tij dhe ta vendosë atë manualisht. ashift. Nëse ashift është vendosur shumë i vogël, atëherë numri i operacioneve të leximit/shkrimit rritet astronomikisht. Pra, shkrimi i "sektorëve" 512-byte në një sektor real 4 KiB nënkupton nevojën për të shkruar "sektorin" e parë, pastaj të lexojë sektorin 4 KiB, ta ndryshojë me "sektorin" e dytë 512-byte, ta shkruajë prapë në sektorin e ri 4 KiB dhe kështu me radhë për çdo shkrim.
Në botën reale, një dënim i tillë ka ndikim tek diskët e ngurtë Samsung EVO, për të cilët duhet të jetë në fuqi ashift=13, por këto SSD gënjejnë për madhësinë e tyre të sektorëve, dhe prandaj vendoset si parazgjedhje ashift=9. Nëse një administrator i avancuar i sistemit nuk e ndryshon këtë parametrin, atëherë ky SSD punon mëngjes si një HDD të zakonshëm.
Për krahasim, nuk ka ndonjë dënim për madhësi tepër të madhe ashift . Përmirësimi real i performancës nuk ka, dhe rritja e hapësirës së papërdorur është përjetësisht e vogël (ose e barabartë me zero kur kompresimi është aktivizuar). Prandaj, ne rekomandojmë ngulmshëm madje edhe për disqet, që me të vërtetë përdorin sektorë 512-byte, të vendosin ashift=12 apo madje ashift=13, për të shikuar me siguri drejt të ardhmes.
Pronësia ashift vendoset për çdo pajisje virtuale vdev, dhe jo për rezervuarin, siç mendojnë shumë, dhe nuk ndryshohet pasi është vendosur. Nëse për fat të keq e keni prishur ashift kur shtoni një vdev të ri në rezervuar, atëherë e keni ndotur përhershmërisht këtë rezervuar me një pajisje me performancë të ulët dhe, për zakon, nuk ka një zgjidhje tjetër përveçse të shkatërroni rezervuarin dhe të filloni gjithçka nga e para. Edhe heqja e vdev-it nuk do të shpëtojë nga konfigurimi i prishur. ashift!
Mekanizmi i kopjimit gjatë shkrimit
Nëse një sistem i zakonshëm të skedarëve duhet të rishkruajë të dhëna - ai ndryshon çdo bllok aty ku ndodhet.
Sistemi i skedarëve me kopjim gjatë shkrimit regjistron një version të ri të bllokut dhe pastaj çel versionin e vjetër
Në një kuptim abstrahues, nëse injorojmë vendndodhjen fizike reale të bllokut, 'kometa e të dhënave' tonë thjeshtohet në një 'krimb të dhënash', i cili lëviz nga e majta në të djathtë në hartën e hapësirës së disponueshme
Tani mund tĂ« kemi njĂ« ide tĂ« qartĂ« se si funksionojnĂ« snapshots me kopjim gjatĂ« shkrimit â çdo bllok mund t'i pĂ«rkasĂ« disa snapshots, dhe do tĂ« ruhet deri sa tĂ« shkatĂ«rrohen tĂ« gjithĂ« snapshots e lidhura
Mekanizmi i kopjimit gjatĂ« shkrimit (Copy on Write, CoW) Ă«shtĂ« themeli i asaj qĂ« e bĂ«n ZFS njĂ« sistem kaq tĂ« shkĂ«lqyer. Koncepti kryesor Ă«shtĂ« i thjeshtĂ« â nĂ«se i kĂ«rkoni njĂ« sistem tradicional skedari tĂ« ndryshojĂ« njĂ« skedar, ai do tĂ« bĂ«jĂ« atĂ« qĂ« i kĂ«rkoni. NĂ«se i kĂ«rkoni njĂ« sistem skedari me kopjim gjatĂ« shkrimit tĂ« bĂ«jĂ« tĂ« njĂ«jtĂ«n gjĂ«, ai do tĂ« thotĂ« 'mirĂ«' â por do t'ju gĂ«njejĂ«.
Në vend të kësaj, sistemi i skedarëve me kopjim gjatë shkrimit regjistron një version të ri të bllokut të ndryshuar dhe pastaj përditëson meta të dhënat e skedarit për të ndarë lidhjen me bllokun e vjetër dhe për të lidhur me të bllokun e ri që sapo e keni regjistruar.
ShkĂ«putja e bllokut tĂ« vjetĂ«r dhe lidhja e bllokut tĂ« ri realizohet me njĂ« operacion, prandaj nuk mund tĂ« ndĂ«rpritet â nĂ«se nĂ«nshkruani energjinĂ« pasi tĂ« ndodhĂ« kjo, keni njĂ« version tĂ« ri tĂ« skedarit, dhe nĂ«se nĂ«nshkruani energjinĂ« mĂ« herĂ«t, atĂ«herĂ« keni versionin e vjetĂ«r. NĂ« çdo rast, nuk do tĂ« ketĂ« konflikte nĂ« sistemin e skedarĂ«ve.
Kopjimi gjatĂ« shkrimit nĂ« ZFS ndodh jo vetĂ«m nĂ« nivelin e sistemit tĂ« skedarĂ«ve, por edhe nĂ« nivelin e menaxhimit tĂ« disqeve. Kjo do tĂ« thotĂ« se ZFS nuk Ă«shtĂ« e prekshme nga hapĂ«sira e shkrimit () â fenomeni kur shiriti ka arritur tĂ« regjistrohet vetĂ«m pjesĂ«risht deri nĂ« dĂ«shtimin e sistemit, me dĂ«mtimin e grupit pas rinisjes. KĂ«tu, shiriti shkruhet atomikisht, vdev gjithmonĂ« Ă«shtĂ« i rregullt, dhe .
ZIL: e journali i qëllimeve ZFS
Sistemi ZFS trajton regjistrimet sinkrone nĂ« njĂ« mĂ«nyrĂ« tĂ« veçantĂ« â ai pĂ«rkohĂ«sisht, por menjĂ«herĂ« i ruan ato nĂ« ZIL, para se mĂ« vonĂ« t'i regjistrojĂ« ato nĂ« mĂ«nyrĂ« tĂ« pĂ«rhershme sĂ« bashku me regjistrimet asinkrone
Zakoni është që të dhënat e regjistruara në ZIL kurrë nuk lexohen më. Por është e mundur pas dështimit të sistemit
SLOG, ose pajisja e dytë LOG, është thjesht një vdev i veçantë - dhe, preferohet, shumë i shpejtë - ku ZIL mund të ruhet ndaras nga ruajtja kryesore.
Pas një dështimi, të gjitha të dhënat e ndotura në ZIL riprodhohen - në këtë rast, ZIL ndodhet në SLOG, kështu që ato riprodhohen pikërisht prej aty.
Ka dy kategori kryesore operacionesh shkrimi - sinkronike (sync) dhe asinkronike (async). Për shumicën e ngarkesave të punës, pjesa më e madhe e operacioneve të shkrimit janë asinkronike - sistemi i skedarëve lejon agregimin e tyre dhe t'i japë ato në grup, duke reduktuar fragmentimin dhe duke rritur ndjeshëm kapacitetin.
Shkrimet sinkronike janë një gjë krejt tjetër. Kur një aplikacion kërkon një shkrim sinkronik, ai i thotë sistemit të skedarëve: "Duhet ta regjistrosh këtë në memorien që nuk humbet energjinë, Qiraja e serverit Windows VPS, dhe deri atëherë nuk mund të bëj asgjë tjetër". Prandaj, shkrimet sinkronike duhet të regjistrohen menjëherë në disk - dhe nëse kjo rrit fragmentimin ose zvogëlon kapacitetin, ashtu qoftë.
ZFS e trajton shkrimin sinkronik ndryshe nga sistemet e zakonshme të skedarëve - në vend që t'i derdhë ato menjëherë në ruajtjen e zakonshme, ZFS i regjistron ato në një zonë të veçantë të ruajtjes, e cila quhet Dita e Qëllimit ZFS - ZFS Intent Log, ose ZIL. Truku është që këto shkrime përveç qëndrojnë në memorie, duke u agreguar bashkë me kërkesat e zakonshme asinkronike për shkrim, për t'u derdhur më vonë në ruajtje si TXG të zakonshëm (grupet e transaksionit, Transaction Groups).
Në mënyrën normale të funksionimit, ZIL regjistrohet dhe kurrë më nuk lexohet. Kur pas disa çastesh shkrimet nga ZIL regjistrohen në ruajtjen kryesore në TXG të zakonshme nga memoria, ato shkëputen nga ZIL. E vetmja herë që diçka lexohesh nga ZIL është gjatë importit të grupit.
NĂ«se ndodh njĂ« dĂ«shtim ZFS - dĂ«shtim i sistemit operativ ose humbje energjie - kur ka tĂ« dhĂ«na nĂ« ZIL, kĂ«to tĂ« dhĂ«na do tĂ« lexohen gjatĂ« importit tĂ« ardhshĂ«m tĂ« grupit (p.sh., kur sistemi rikthehet pas njĂ« dĂ«shtimi). Ădo gjĂ« qĂ« ndodhet nĂ« ZIL do tĂ« lexohet, do tĂ« bashkohet nĂ« grupet TXG, do tĂ« regjistrohet nĂ« ruajtjen kryesore dhe pastaj do tĂ« shkĂ«putet nga ZIL nĂ« procesin e importit.
NjĂ« nga klasat ndihmĂ«se vdev quhet LOG ose SLOG, pajisja sekondare LOG. Ai ka njĂ« detyrĂ« tĂ« vetme â tĂ« ofrojĂ« njĂ« vdev tĂ« veçantĂ« dhe, preferohet, shumĂ« mĂ« tĂ« shpejtĂ«, me njĂ« qĂ«ndrueshmĂ«ri shumĂ« tĂ« lartĂ« nĂ« shkrim, pĂ«r tĂ« ruajtur ZIL, nĂ« vend qĂ« tĂ« ruajĂ« ZIL nĂ« depozitĂ«n kryesore vdev. ZIL vetĂ« sillet nĂ« tĂ« njĂ«jtĂ«n mĂ«nyrĂ« pavarĂ«sisht nga vendi i ruajtjes, por nĂ«se vdev me LOG ka njĂ« performancĂ« shumĂ« tĂ« lartĂ« tĂ« shkrimit, atĂ«herĂ« shkrimet sincronike do tĂ« ndodhin mĂ« shpejt.
Shtimi i vdev me LOG nĂ« rezervuar nuk do nuk mund tĂ« pĂ«rmirĂ«sojĂ« performancĂ«n e shkrimit asinkron â madje edhe nĂ«se ju detyroni tĂ« ekzekutoni tĂ« gjitha shkrimet nĂ« ZIL me anĂ« tĂ« zfs set sync=always, ato do tĂ« jenĂ« gjithsesi tĂ« lidhura me depozitĂ«n kryesore nĂ« TXG nĂ« tĂ« njĂ«jtĂ«n mĂ«nyrĂ« dhe me tĂ« njĂ«jtin ritĂ«m, ashtu si pa ditar. PĂ«rmirĂ«simi i vetĂ«m direkt i performancĂ«s Ă«shtĂ« koha e vonesĂ«s sĂ« shkrimit sinkron (pasi shpejtĂ«sia mĂ« e lartĂ« e ditarit pĂ«rshpejton ekzekutimin e operacioneve. sync).
Megjithatë, në një mjedis që tashmë kërkon një numër të madh shkrimesh sinkron, vdev LOG mund të përshpejtojë në mënyrë indirekte shkrimet asinkrone dhe leximet e pa-cache. Shkarkimi i shkrimeve ZIL në një vdev LOG të veçantë do të thotë më pak konkurrencë për IOPS në depozitën primare, çka ndihmon disi përmirësimin e performancës së të gjitha operacioneve të leximit dhe shkrimit.
Snapshotet
Mekanizmi i kopjimit nĂ« shkrim gjithashtu Ă«shtĂ« njĂ« bazĂ« e nevojshme pĂ«r snapshotet atomike ZFS dhe replikimin inkremental asinkron. NĂ« njĂ« sistem aktiv skedarĂ«sh ka njĂ« pemĂ« treguesish qĂ« tregon tĂ« gjitha shkrimet me tĂ« dhĂ«nat aktuale â kur bĂ«ni njĂ« snapshot, thjesht bĂ«ni njĂ« kopje tĂ« kĂ«saj peme treguesish.
Kur në një sistem aktiv të skedarëve rishkruhet një shkrim, ZFS së pari shkruan versionin e ri të bllokut në hapësirën e papërdorur. Pastaj ndan versionin e vjetër të bllokut nga sistemi i skedarëve aktual. Por nëse ndonjë snapshot i referohet bllokut të vjetër, ai mbetet gjithsesi i pandryshuar. Blloku i vjetër në fakt nuk do të rikuperohet si hapësirë e lirë derisa të gjitha snapshotet që i referohen këtij blloku të shkatërrohen!
Replikimi
Biblioteka ime e Steam nĂ« vitin 2015 zinte 158 GiB dhe pĂ«rfshinte 126,927 skedarĂ«. Kjo Ă«shtĂ« mjaft afĂ«r situatĂ«s optimale pĂ«r rsync â replikimi i ZFS pĂ«rmes rrjetit ishte "vetĂ«m" 750% mĂ« i shpejtĂ«.
Në të njëjtin rrjet, replikimi i një skedari 40-gigabajtësh të imazhit të makinës virtuale Windows 7 është një histori krejt tjetër. Replikimi ZFS ndodh 289 herë më shpejt se rsync, ose 'thjesht' 161 herë më shpejt nëse jeni mjaft të njohur për të thirrur rsync me çelësin --inplace.
Kur imazhi i makinës virtuale shkallëzohet, problemet e rsync-it shkallëzohen gjithashtu me të. Këndi 1.9 TiB nuk është aq i madh për një imazh modern të makinës virtuale, por është mjaft i madh që replikimi ZFS të rezultojë 1148 herë më i shpejtë se rsync, madje edhe me argumentin rsync --inplace.
Sa herë që kuptoni se si funksionojnë snapshot-et, do të jetë e lehtë të kuptoni thelbin e replikimit. Pasi snapshot-i është thjesht një pemë treguesish për regjistrimet, kjo nënkupton se nëse bëjmë zfs send snapshot, ne dërgojmë këtë pemë dhe të gjitha regjistrimet e lidhura me të. Kur e kalojmë këtë zfs send në zfs receive në objektin e synimit, ai shkruan si përmbajtjen faktike të bllokut, ashtu edhe pemën e treguesve që referohen në blloqet, në grupin e të dhënave të synimit.
Gjërat bëhen edhe më interesante në të dytin zfs send. Tani kemi dy sisteme, secila prej të cilave përmban poolname/datasetname@1, ndërsa po merrni një snapshot të ri poolname/datasetname@2.Prandaj, në grupin burimor keni datasetname@1 dhe datasetname@2, ndërsa në grupin e synimit për momentin vetëm snapshot-i i parë. datasetname@1.
Duke qenĂ« se kemi njĂ« snapshot tĂ« pĂ«rbashkĂ«t midis burimit dhe qĂ«llimit, ne mund tĂ« bĂ«jmĂ« datasetname@1inkrementale mbi tĂ«. Kur i themi sistemit zfs send zfs send -i poolname/datasetname@1 poolname/datasetname@2 , ai krahason dy pemĂ« treguesish. Ădo tregues qĂ« ekziston vetĂ«m nĂ«, referohet qartĂ« nĂ« blloqe tĂ« reja - prandaj na nevojitet pĂ«rmbajtja e kĂ«tyre blloqeve. @2NĂ« sistemin e largĂ«t, procesi i inkrementaleve
është po aq i thjeshtë. Së pari, shkruajmë të gjitha regjistrimet e reja të përfshira në kanalin dërgo , e më pas shtojmë treguesit për këto blloqe. Vua, kemi dërgonë sistemin e ri! @2 Replikimi asinkron inkremental i ZFS është një përmirësim të madh krahasuar me metodat e mëparshme që nuk bëjnë përdorim të snapshot-eve, si rsync. Në të dy rastet, transferohen vetëm të dhënat e ndryshuara - por rsync duhet së pari
nga disku tĂ« gjitha tĂ« dhĂ«nat nga tĂ« dyja anĂ«t pĂ«r tĂ« verifikuar shumĂ«n dhe pĂ«r ta krahasuar atĂ«. Ndryshe nga kjo, replikimi ZFS nuk lexon asgjĂ« pĂ«rveç pemĂ«ve tĂ« treguesve - dhe blloqeve tĂ« çdo lloji qĂ« nuk janĂ« tĂ« paraqitura nĂ« snapshot-in e pĂ«rbashkĂ«t. lexohet nga disk, tĂ« gjitha tĂ« dhĂ«nat nga tĂ« dyja anĂ«t, pĂ«r tĂ« kontrolluar shumĂ«n dhe pĂ«r ta krahasuar atĂ«. Ndryshe nga kjo, replikimi ZFS nuk lexon asgjĂ«, pĂ«rveç pemĂ«ve tĂ« treguesve â dhe çdo blloku qĂ« nuk paraqitet nĂ« snapshots e pĂ«rbashkĂ«ta.
Shtypja e integruar
Mekanizmi i kopjimit gjatë shkrimit gjithashtu thjeshton sistemin e shtypjes së integruar. Në sistemet tradicionale të skedarëve, shtypja është problematike - si versioni i vjetër ashtu edhe versioni i ri i të dhënave të modifikuara ndodhen në të njëjtin hapësirë.
Nëse shqyrtojmë një fragment të të dhënave në mes të skedarit, i cili fillon jetën e tij si një megabajt zero nga 0x00000000 e më pas - është shumë e lehtë ta shtypim këtë në një sektor në disk. Por çfarë do të ndodhë nëse ne zëvendësojmë këtë megabajt zerosh me një megabajt të dhënash që nuk mund të shtypen, si JPEG ose zhurmë pseudo-rastësore? Papritmas, ky megabajt të dhënash do të kërkojë jo një, por 256 sektorë me 4 KiB, ndërsa në këtë vend të diskut është rezervuar vetëm një sektor.
ZFS nuk ka një problem të tillë, pasi të dhënat e modifikuara gjithmonë shkruhen në hapësirë të pavendosur - blloku origjinal zë vetëm një sektor 4 KiB, ndërsa shenja e re do të marrë 256, por kjo nuk është problem - fragmenti i sapo modifikuar nga "mes" i skedarit do të shkruhej në hapësirë të pavendosur pavarësisht nëse ka ndryshuar ose jo, prandaj për ZFS kjo është një situatë krejt normale.
Shtypja e integruar ZFS është e çaktivizuar si parazgjedhje dhe sistemi ofron algoritme të lidhura - aktualisht përfshijnë LZ4, gzip (1-9), LZJB dhe ZLE.
- LZ4 â Ă«shtĂ« njĂ« algoritĂ«m i rrjedhshĂ«m, duke ofruar shtypje dhe dekompresim jashtĂ«zakonisht tĂ« shpejtĂ« dhe pĂ«rfitime nĂ« performancĂ« pĂ«r shumicĂ«n e rasteve tĂ« pĂ«rdorimit - madje edhe nĂ« CPU relativisht tĂ« ngadalta.
- GZIP â njĂ« algoritĂ«m i njohur, i dashur nga tĂ« gjithĂ« pĂ«rdoruesit e sistemeve Unix. Ai mund tĂ« realizohet me nivele shtypjeje 1-9, me rritjen e shkallĂ«s sĂ« shtypjes dhe pĂ«rdorimit tĂ« CPU-te ndĂ«rkohĂ« qĂ« i afrohet nivelit 9. Algoritmi Ă«shtĂ« i pĂ«rshtatshĂ«m pĂ«r tĂ« gjitha variantet e pĂ«rdorimit tĂ« teksteve (ose tĂ« tjera qĂ« mund tĂ« kompresohen shumĂ«), por pĂ«rndryshe shpesh shkakton probleme me CPU - pĂ«rdoreni me kujdes, veçanĂ«risht nĂ« nivelet mĂ« tĂ« larta.
- LZJB â algoritmi origjinal nĂ« ZFS. Ai Ă«shtĂ« i tejkaluar dhe nuk duhet tĂ« pĂ«rdoret mĂ«, LZ4 e tejkalon atĂ« nĂ« çdo aspekt.
- ZLE â kodimi i nivelit zero, Zero Level Encoding. Ai nĂ« pĂ«rgjithĂ«si nuk prek tĂ« dhĂ«nat normale, por kompreson sekuenca tĂ« mĂ«dha zeros. E dobishme pĂ«r grupe tĂ« dhĂ«nash plotĂ«sisht tĂ« padihet (p.sh., JPEG, MP4 ose formate tĂ« tjera qĂ« janĂ« tashmĂ« kompaktuar), pasi injoron tĂ« dhĂ«nat e pa kompresuara, por kompreson hapĂ«sirĂ«n e papĂ«rdorur nĂ« regjistrat pĂ«rfundimtarĂ«.
Ne rekomandojmë kompresimin LZ4 për pothuajse të gjitha rastet e përdorimit; ndëshkimi për performancën kur haset me të dhëna të pa kompresuara është shumë i vogël, dhe e ndjeshme performanca për të dhënat tipike është e rëndësishme. Kopjimi i imazhit të makinës virtuale për një instalim të ri të sistemit operativ Windows (sistem operativ i sapoinstaluar, pa të dhëna brenda akoma) me compression=lz4 ka kaluar 27% më shpejt se me compression=none, në .
ARC â zĂ«vendĂ«simi adaptiv i caches
ZFS është e vetmja sistem files moderne që dimë që përdor mekanizmin e vet të përmirësimit të leximin, dhe nuk mbështetet në caches të faqeve të sistemit operativ për të mbajtur kopje të blloqeve të lexuara rishtazi në memoria RAM.
MegjithĂ«se cache-ja e vet nuk Ă«shtĂ« pa problemet e saj â ZFS nuk mund tĂ« reagojĂ« pĂ«r kĂ«rkesat e reja pĂ«r ndarje memories aq shpejt sa bĂ«rthama, kĂ«shtu qĂ« njĂ« thirrje e re malloc() pĂ«r ndarjen e memories mund tĂ« dĂ«shtojĂ«, nĂ«se i nevojitet memoria RAM e zĂ«nĂ« aktualisht nga ARC. Por ka arsye tĂ« forta pĂ«r tĂ« pĂ«rdorur cache-nĂ« e vet, tĂ« paktĂ«n tani.
Të gjitha sistemet operative moderne, përfshirë MacOS, Windows, Linux dhe BSD, përdorin algoritmin LRU (Më pak frekuent përdorur) për të zbatuar caches të faqeve. Ky është një algoritëm primitiv, i cili rrit bllokun e cache-t "lart në rend" pas çdo leximi dhe hedh blloqet "poshtë në rend" sipas nevojës, për të shtuar humbjet e reja të caches (blloqet që duhet të jenë lexuar nga disku, e jo nga cache) lart.
Zakonisht algoritmi funksionon mirĂ«, por nĂ« sisteme me grupe tĂ« mĂ«dha tĂ« dhĂ«nash, LRU lehtĂ« tĂ« çojĂ« nĂ« treshing â heqjen e blloqeve qĂ« nevojiten shpesh, pĂ«r tĂ« liruar hapĂ«sirĂ« pĂ«r blloqet qĂ« kurrĂ« mĂ« nuk do tĂ« lexohen nga cache.
 â njĂ« algoritĂ«m shumĂ« mĂ« pak naiv, i cili mund tĂ« konsiderohet si njĂ« memorie 'e peshkuar'. Pas çdo leximi tĂ« bllokut tĂ« caches, ai bĂ«het pak 'mĂ« i rĂ«ndĂ«' dhe bĂ«het mĂ« e vĂ«shtirĂ« tĂ« dĂ«shtohet - dhe madje edhe pas dĂ«shtimit, blloku ndiqet pĂ«r njĂ« periudhĂ« tĂ« caktuar kohe. NjĂ« bllok qĂ« Ă«shtĂ« dĂ«buar, por pastaj duhet tĂ« lexohet pĂ«rsĂ«ri nĂ« cache, gjithashtu do tĂ« bĂ«het 'mĂ« i rĂ«ndĂ«'.
Si rezultat i gjithë këtyre është një cache me një raport shumë më të lartë hit (hit ratio) - raporti midis goditjeve në cache (leximi, që bëhet nga cache) dhe humbjeve (leximi nga disku). Kjo është një statistikë tepër e rëndësishme - jo vetëm që vetë hitet e cache shërbehen me rend të shpejtë, humbjet e caches gjithashtu mund të shërbehen më shpejt, pasi sa më shumë hitet në cache - aq më pak kërkesa paralel për disk dhe aq më pak vonesë për ato humbje të mbetura që duhet të shërbehen nga disku.
PĂ«rfundim
Pas studimit të semantikës themelore të ZFS - se si funksionon kopjimi në shkrim, si dhe marrëdhëniet midis grupeve të ruajtjes, pajisjeve virtuale, blloqeve, sectorëve dhe skedarëve - ne jemi gati të diskutojmë performancën reale me numra realë.
Në pjesën tjetër do të shqyrtojmë performancën faktike të grupeve me vdev të pasqyruar dhe RAIDz, njëri në krahasim me tjetrin, si dhe në krahasim me topologjitë tradicionale të RAID të bërthamës Linux, të cilat kemi eksploruar .
Fillimisht ne donim të shqyrtonim vetëm elementet bazë - vetë topologjitë ZFS - por pas e një do të jemi gati të flasim për konfigurimin dhe rregullimin më të avancuar të ZFS, duke përfshirë përdorimin e llojeve ndihmëse të vdev, si L2ARC, SLOG dhe Special Allocation.
Burimi: habr.com
