Këtë pranverë ne kemi diskutuar disa tema hyrëse, siç janë 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 skedari të gjeneratës së ardhshme, i cili po implementohet kudo: nga deri te .
Ajo që është, sot është dita më e përshtatshme për të njohur me ZFS, lexues të kureshëm. Thjesht dijeni se, sipas vlerësimeve modeste nga zhvilluesi i OpenZFS, Matt Arent, "është vërtetë e vështirë".
Por para se të arrijmë te numrat - dhe ata do të jenë, premtoj - për të gjitha variantet e konfigurimit të tetë disqeve ZFS, duhet të flasim për atë si si ZFS ruan të dhënat në disk.
Zpool, vdev dhe pajisja
Kjo diagramë e informacionit të plotë përmban tre vdev të ndihmës, nga një nga secili klasë, dhe katër për RAIDz2.
Zakonisht nuk ka arsye për të krijuar një pool nga tipe dhe madhësi të ndryshme të vdev - por nëse dëshironi, asgjë nuk ju ndalon ta bëni këtë.
Për të kuptuar vërtetësisht sistemin e skedarëve ZFS, duhen shqyrtuar me kujdes strukturat e tij reale. Së pari, ZFS kombinon nivelet tradicionale të menaxhimit të vëllimeve dhe sistemit të skedarëve. Së dyti, ajo përdor një mekanizëm transaksional të kopjimit gjatë shkruarjes. Këto karakteristika tregojnë se sistemi është strukturalisht shumë i ndryshëm nga sistemet e zakonshme të skedarëve dhe RAID. Grupi i parë i blloqeve themelore për të kuptuar është: kjo është baza e ruajtjes (zpool), pajisja virtuale (vdev) dhe pajisja reale (device).
zpool
Grupi i ruajtjes zpool Ă«shtĂ« struktura mĂ« e lartĂ« e ZFS. Ădo grup pĂ«rmban njĂ« ose mĂ« shumĂ« pajisje virtuale. Nga ana tjetĂ«r, secila prej tyre pĂ«rmban njĂ« ose mĂ« shumĂ« pajisje reale (device). Pajisjet virtuale janĂ« blloqe autonome. NjĂ« kompjuter fizik mund tĂ« ketĂ« dy ose mĂ« shumĂ« grupe tĂ« ndara, por secili Ă«shtĂ« plotĂ«sisht i pavarur nga tĂ« tjerĂ«t. Grupe nuk mund tĂ« ndajnĂ« pajisje virtuale.
Tezja e ZFS ndodhet nĂ« nivelin e pajisjeve virtuale, dhe jo nĂ« nivelin e pishinave. NĂ« nivelin e pishinave nuk ka asnjĂ« lloj teje â nĂ«se humbet ndonjĂ« pajisje vdev ose njĂ« vdev i veçantĂ«, atĂ«herĂ« humbet gjithashtu dhe gjithĂ« pishina.
Pishinat moderne tĂ« ruajtjes mund tĂ« pĂ«rballojnĂ« humbjen e caches ose regjistrit tĂ« pajisjes virtuale â megjithatĂ«, ata mund tĂ« humbasin njĂ« sasi tĂ« vogĂ«l tĂ« tĂ« dhĂ«nave tĂ« papastruara nĂ«se humbin regjistrin e vdev gjatĂ« ndĂ«rprerjes sĂ« energjisĂ« ose dĂ«shtimit tĂ« sistemit.
Ka një keqkuptim të zakonshëm se "bandat e të dhënave" (stripes) në ZFS shkruhen përmes të gjithë pishinës. Kjo është e pavërtetë. Zpool nuk është aspak një RAID0 argëllues, është më shumë një argëllues me një mekanizëm kompleks të ndarjes së ndryshueshme.
Pjesët shpërndahen kryesisht mes pajisjeve virtuale të disponueshme në bazë të hapësirës së lirë të disponueshme, kështu që teorikisht të gjitha ato do të mbushen njëherësh. Në versionet e mëvonshme të ZFS, merret parasysh përdorimi aktual (shfrytëzimi) i vdev - nëse një pajisje virtuale është shumë më e ngarkuar se tjetra (p.sh., për shkak të ngarkesës së leximit), do ta anashkalojnë për përpunim të shkrimit përkohësisht, pavarësisht ngaCoefficienti më i lartë i hapësirës së lirë.
Mekanizmi i vlerësimit të shfrytëzimit, i integruar në metodat moderne të shpërndarjes së shkrimit të ZFS, mund të zvogëlojë vonesat dhe të rrisë kapacitetin gjatë periudhave të ngarkesës jashtëzakonisht të lartë - por kjo nuk është kart-blan për kombinimin e padëshiruar të HDD-ve të ngadalta dhe SSD-ve të shpejta në një grup. Një grup i tillë disavantazhi do të funksionojë prapë me shpejtësinë e pajisjes më të ngadaljtë, siç do të ishte si të ishte tërësisht i përbërë nga ato pajisje.
vdev
Ădo pool ruajtjeje pĂ«rbĂ«het nga njĂ« ose mĂ« shumĂ« pajisje virtuale (virtual device, vdev). Nga ana tjetĂ«r, çdo vdev pĂ«rfshin njĂ« ose mĂ« shumĂ« pajisje reale. Shumica e pajisjeve virtuale pĂ«rdoren pĂ«r ruajtje tĂ« thjeshtĂ« tĂ« tĂ« dhĂ«nave, por ekzistojnĂ« disa klasa ndihmĂ«se vdev, duke pĂ«rfshirĂ« CACHE, LOG dhe SPECIAL. Ădo nga kĂ«to tipe vdev mund tĂ« ketĂ« njĂ« nga pesĂ« topologjitĂ«: pajisje tĂ« vetme (single-device), RAIDz1, RAIDz2, RAIDz3 ose pasqyrĂ« (mirror).
RAIDz1, RAIDz2 dhe RAIDz3 janë variante të veçanta të asaj që 'oldies' do ta quanin RAID me dy (diagonale) paritet. 1, 2 dhe 3 i referohen numrit të bllokove të paritetit të caktuar për çdo bandë të dhënash. Në vend të diskëve të veçantë për sigurimin e paritetit, pajisjet virtuale RAIDz shpërndajnë në mënyrë gjysmë të barabartë këtë paritet nëpër disqe. Një grup RAIDz mund të humbasë aq disqe sa ka bllokë pariteti; nëse humbet një tjetër, do të degradojë dhe do të marrë me vete pool-in e ruajtjes.
NĂ« pajisjet virtuale tĂ« pasqyruara (mirror vdev), çdo bllok ruhet nĂ« çdo pajisje nĂ« vdev. MegjithĂ«se pasqyra mĂ« tĂ« zakonshme janĂ« ato me dy pajisje (two-wide), nĂ« njĂ« pasqyrĂ« mund tĂ« ketĂ« çdo numĂ«r tĂ« rastĂ«sishĂ«m pajisjesh â nĂ« instalime tĂ« mĂ«dha, pĂ«r tĂ« rritur performancĂ«n e leximit dhe qĂ«ndrueshmĂ«rinĂ«, shpesh pĂ«rdoren ato me tre pajisje. NjĂ« pasqyrĂ« vdev mund tĂ« pĂ«rballojĂ« çdo dĂ«shtim, pĂ«rsa kohĂ« funksionon tĂ« paktĂ«n njĂ« pajisje nĂ« vdev.
vdev-tĂ« e vetme, nĂ« thelb, janĂ« tĂ« rrezikshme. NjĂ« pajisje virtuale e tillĂ« nuk do tĂ« pĂ«rballojĂ« asnjĂ« dĂ«shtim â dhe nĂ«se pĂ«rdoret si hapĂ«sirĂ« ruajtjeje ose vdev i veçantĂ«, dĂ«shtimi i saj do tĂ« çojĂ« nĂ« shkatĂ«rrimin e tĂ« gjithĂ« grupit. Kini shumĂ«, shumĂ« kujdes kĂ«tu.
Pajisjet virtuale CACHE, LOG dhe SPECIAL mund tĂ« krijohen sipas ndonjĂ« nga topologjitĂ« e mĂ«sipĂ«rme â por mbani mend se humbja e njĂ« pajisjeje SPECIAL do tĂ« thotĂ« humbje tĂ« grupit, prandaj rekomandohet me ngulm njĂ« topologji e tepĂ«rt.
pajisje
Probablemente, kjo Ă«shtĂ« termi mĂ« i thjeshtĂ« pĂ«r t'u kuptuar nĂ« ZFS â Ă«shtĂ« dosja e hapur qĂ« Ă«shtĂ« literalisht njĂ« njĂ«sit tĂ« dhĂ«nash tĂ« aksessit tĂ« rastĂ«sishĂ«m. Mbani mend se pajisjet virtuale pĂ«rbĂ«hen nga pajisje tĂ« veçanta, dhe njĂ« pishinĂ« Ă«shtĂ« bĂ«rĂ« nga pajisje virtuale.
Disqet â magnetikĂ« ose tĂ« ngurta â janĂ« njĂ«sitĂ« mĂ« tĂ« zakonshme qĂ« pĂ«rdoren si bllok pĂ«r vdev. MegjithatĂ«, pĂ«r çdo pajisje me njĂ« pĂ«rshkrim nĂ« /dev do tĂ« bĂ«jĂ« - kĂ«shtu qĂ« gjithashtu mund tĂ« pĂ«rdoren tĂ«rĂ« grupe RAID pĂ«r pajisje tĂ« veçanta.
Një skedar i thjeshtë raw është një nga pajisjet më të rëndësishme alternative blloku nga të cilat mund të ndërtohet një vdev. Pishinat testuese nga  janë një mënyrë shumë e dobishme për të kontrolluar komandat e pishinës dhe për të parë sa hapësirë është e disponueshme në pishinë ose pajisjen virtuale të kësaj topologjie.
Mund tĂ« krijoni njĂ« pishinĂ« testuese nga skedarĂ« tĂ« hollĂ« pĂ«r vetĂ«m disa sekonda â por mos harroni tĂ« fshini pastaj tĂ« gjithĂ« pishinĂ«n dhe komponentĂ«t e saj.
TĂ« supozojmĂ« se dĂ«shironi tĂ« vendosni njĂ« server me tetĂ« disqe dhe planifikoni tĂ« pĂ«rdorni disqe prej 10 TB (~9300 GiB) â por nuk jeni tĂ« sigurt se cila topologji Ă«shtĂ« mĂ« e pĂ«rshtatshme pĂ«r nevojat tuaja. NĂ« shembullin e mĂ«sipĂ«rm, ndĂ«rtuam njĂ« grup prova nga skedarĂ« tĂ« shpĂ«rndarĂ« pĂ«r disa sekonda â dhe tani e dimĂ« se RAIDz2 vdev me tetĂ« disqe prej 10 TB ofron 50 TiB kapacitet tĂ« dobishĂ«m.
Një klasë tjetër e veçantë e pajisjeve është SPARE (rezervë). Pajisjet me ndërrim të nxehtë, në dallim nga pajisjet normale, i përkasin të gjithë grupit dhe jo një pajisjeje virtuale. Nëse ndonjë vdev në grup dështon dhe pajisja rezervë është e lidhur me grupin dhe e disponueshme, ajo do të bashkohet automatikisht me vdev-in e dëmtuar.
Pasi të lidhet 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, ky proces quhet rikonstruksion (rebuilding), ndërsa në ZFS është "rikthimi i tepërsiisë" (resilvering).
ĂshtĂ« e rĂ«ndĂ«sishme tĂ« theksohet se pajisjet rezervĂ« nuk zĂ«vendĂ«sojnĂ« pĂ«rfundimisht pajisjet e prishura. Ato janĂ« njĂ« zĂ«vendĂ«sim pĂ«rkohĂ«sor pĂ«r tĂ« reduktuar kohĂ«n e degradimit tĂ« vdev. Pasi administratorit t'i zĂ«vendĂ«sojĂ« pajisjen e prishur tĂ« vdev, ndodhi rikthimi i tepĂ«rsisĂ« nĂ« kĂ«tĂ« pajisje tĂ« pĂ«rhershme, dhe SPARE shkĂ«putet nga vdev dhe kthehet nĂ« punĂ« si rezervĂ« pĂ«r tĂ« gjithĂ« pool-in.
Grupet e të dhënave, blloket dhe sektorët
Grupi i ardhshĂ«m i elementeve ndihmon pĂ«r tĂ« kuptuar mĂ« mirĂ« nĂ« udhĂ«timin tonĂ« pĂ«r ZFS, ndĂ«rlidhet mĂ« shumĂ« me mĂ«nyrĂ«n se si organizohen dhe ruhen vetĂ« tĂ« dhĂ«nat. Ne kĂ«tu e anashkalojmĂ« disa nivele â si pĂ«r shembull metaslab â pĂ«r tĂ« mos e mbingarkuar detajin, 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Ă« pool-it. Pastaj ne vendosim njĂ« kuotĂ« â dhe ndryshojmĂ« pikĂ«n e montimit. Magjia!
Zvol është kryesisht thjesht një grup të dhënash, i hequr nga shtresa e tij e sistemit të skedarëve, e cila këtu zëvendësohet me një sistem faturimi të zakonshëm si ext4.
Grupi i të dhënave ZFS është në përputhje të ngjashme me sistemin standard të skedarëve të montuar. Si çdo sistem skedarësh të zakonshëm, në radhë të parë duket si "thjesht një dosje tjetër". Por ashtu si çdo sistem tjetër i montuar i skedarëve, çdo grup të dhënash ZFS ka grupin e tij të veçorive elementare.
Së pari, grupit të të dhënave mund t'i caktohet një kuotë. Nëse caktoni 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 e keni vĂ«nĂ« re praninĂ« â dhe mungesĂ«n â e shenjave / nĂ« fillim tĂ« çdo rreshti? Ădo grup tĂ« dhĂ«nash ka vendin e tij nĂ« hierarkinĂ« ZFS, ashtu si dhe nĂ« hierarkinĂ« e montimit tĂ« sistemit. NĂ« hierarkinĂ« ZFS nuk ka shenjĂ« tĂ« parĂ« â filloni me emrin e puloit 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 child nĂ« grupin e parentit parent nĂ« njĂ« pool me emrin krijues pool.
NĂ« mĂ«nyrĂ« standarde, pika e montimit tĂ« grupit tĂ« dhĂ«nash do tĂ« jetĂ« e barabartĂ« me emrin e tij nĂ« hierarkinĂ« ZFS, me njĂ« slash nĂ« fillim â pool me emrin pool do tĂ« montojĂ« si /pool, grupi i tĂ« dhĂ«nave parent do tĂ« montohet nĂ« /pool/parent, dhe grupi i fĂ«mijĂ«s child do tĂ« montohet nĂ« /pool/parent/child. MegjithatĂ«, pika e montimit tĂ« sistemit pĂ«r grupin e tĂ« dhĂ«nave mund tĂ« ndryshohet.
Nëse ne tregojmë zfs set mountpoint=/lol pool/parent/child, atëherë grupi i të dhënave pool/parent/child do të montojë në sistem si /lol.
PĂ«rveç grupeve tĂ« tĂ« dhĂ«nave, ne duhet tĂ« pĂ«rmendim volumat (zvols). NjĂ« volum Ă«shtĂ« afĂ«rsisht ekuivalent me njĂ« grup tĂ« dhĂ«nash, pĂ«rveç se nuk ka njĂ« sistem skedarĂ«sh â Ă«shtĂ« thjesht njĂ« pajisje blloku. PĂ«r shembull, mund 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Ă« backend kur eksportoni njĂ« pajisje iSCSI.
Blloqe
NjĂ« skedar pĂ«rfaqĂ«sohet nga njĂ« ose mĂ« shumĂ« blloqe. Ădo bllok ruhet nĂ« njĂ« pajisje virtuale. MadhĂ«sia e bllokut zakonisht Ă«shtĂ« e barabartĂ« me parametrin recordsize, por mund tĂ« zvogĂ«lohet deri nĂ« 2^ashift, nĂ«se pĂ«rmban meta tĂ« dhĂ«na ose njĂ« skedar tĂ« vogĂ«l.
Ne vërtet, vërtet nuk po shaka në lidhje me dëmin e madh në performancë, nëse vendosni një ashift shumë të vogël.
Në grupin ZFS të gjitha të dhënat, përfshirë metadatën, ruhen në blloqe. Madhësia maksimale e bllokut për çdo 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 çdo blloku që tashmë është shkruar në grupin e dhënash - vepron vetëm për blloqet e reja gjatë shkruarjes së tyre.
Nëse nuk përcaktohet ndryshe, madhësia aktuale e shënimit është caktuar si 128 KiB. Ky është një lloj kompromisi të vështirë, ku performanca nuk do të jetë e përsosur, por as e keqe në shumicën e rasteve. Madhësia e shënimit mund të vendoset në çdo vlerë nga 4K në 1M (me cilësime shtesë recordsize mund të vendoset edhe më shumë, por kjo rrallë është një ide e mirë).
Ădo bllok i referohet tĂ« dhĂ«nave tĂ« vetĂ«m njĂ« skedari - nuk mund tĂ« vendosni dy skedarĂ« tĂ« ndryshĂ«m nĂ« njĂ« bllok. Ădo skedar pĂ«rbĂ«het nga njĂ« ose mĂ« shumĂ« blloqe, nĂ« varĂ«si tĂ« madhĂ«sisĂ«. 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Ă« skedari 2 KiB do tĂ« zĂ« vetĂ«m njĂ« sektor 4 KiB nĂ« disk.
NĂ«se skedari Ă«shtĂ« mjaft i madh dhe kĂ«rkon disa blloqe, tĂ« gjitha regjistrimet me kĂ«tĂ« skedar do tĂ« kenĂ« madhĂ«si recordsize â pĂ«rfshirĂ« regjistrimin e fundit, pjesa kryesore e tĂ« cilit mund tĂ« jetĂ« .
VĂ«llimet zvol nuk kanĂ« pronĂ«si recordsize â nĂ« vend tĂ« kĂ«saj, ato kanĂ« njĂ« pronĂ«si ekuivalente volblocksize.
Sektorë
NjĂ«si mĂ« e vogĂ«l, blloku themelor Ă«shtĂ« sektori. Kjo Ă«shtĂ« njĂ«sia mĂ« e vogĂ«l fizike qĂ« mund tĂ« shkruhet ose lexohet nga pajisja themelore. GjatĂ« disa dekadave, sektoret prej 512 byte kanĂ« qenĂ« tĂ« zakonshĂ«m nĂ« shumicĂ«n e diskĂ«ve. KohĂ«t e fundit, shumica e diskĂ«ve janĂ« konfiguruar me sektore 4 KiB, ndĂ«rsa disa â veçanĂ«risht SSD â kanĂ« sektore 8 KiB ose edhe mĂ« shumĂ«.
NĂ« sistemin ZFS, ka njĂ« pronĂ«si qĂ« lejon vendosjen manuale tĂ« madhĂ«sisĂ« sĂ« sektorit. Kjo pronĂ«si ashift. ĂshtĂ« pak e ngatĂ«rruar qĂ« ashift Ă«shtĂ« njĂ« fuqi e dytes. PĂ«r shembull, ashift=9 nĂ« atĂ« rast do tĂ« thotĂ« madhĂ«sia e sektorit 2^9, ose 512 byte.
ZFS kërkon informacion të detajuar nga sistemi operativ për çdo pajisje bllokuese kur ajo shtohet në një vdev të ri, dhe teorikisht vendos automatikisht ashiftin siç është e duhur në bazë të këtij informacioni. Fatkeqësisht, shumë disqe gënjejnë për madhësinë e tyre të sektorit për të ruajtur pajtueshmërinë me Windows XP (i cili nuk ishte në gjendje të kuptonte diskët me madhësi të ndryshme sektori).
Kjo do të thotë se administratori i ZFS rekomandohet me ngulm të di madhësinë e vërtetë të sektorëve të pajisjeve të tij dhe të vendosë manualisht ashift. Nëse vendoset një ashift shumë i vogël, do të rritet astronomikisht numri i operacioneve të leximit/shkrimit. Kështu, shkrimi i «sektorëve» 512-bytes në një sektor të vërtetë 4 KiB do të thotë nevojën për të shkruar «sektorin» e parë, pastaj të lexosh sektorin 4 KiB, ta ndryshosh atë me «sektorin» e dytë 512-bytes, ta shkruash atë përsëri në sektorin e ri 4 KiB dhe kështu me radhë për çdo shkrim.
Në botën reale, një dënim i tillë godet disqet e ngurta Samsung EVO, për të cilat duhet të mbajë ashift=13, por këta SSD gënjejnë për madhësinë e tyre të sektorit, dhe për këtë arsye caktimi është bërë në parazgjedhje ashift=9. Nëse një administrator i sistemit me përvojë nuk e ndryshon këtë parametër, atëherë ky SSD funksionon më ngadalë se një HDD të zakonshëm.
Për krahasim, për një madhësi të tepërt ashift nuk ka praktikisht asnjë gjobë. Nuk ka ulje të vërtetë të performancës, dhe rritja e hapësirës së pavendosur është për të gjithë praktisht minimale (ose e barabartë me zero nëse kompresimi është aktiv). Prandaj, rekomandojmë me ngulm që edhe disqe që vërtet përdorin sektora prej 512 bytes të vendosin ashift=12 ose madje ashift=13, për t'u siguruar në të ardhmen.
Karakteristika ashift vendoset për çdo pajisje virtuale vdev, dhe jo për puhun, siç mendon gabimisht shumë njerëz - dhe nuk ndryshohet pas vendosjes. Nëse gabimisht e ke shtrembëruar ashift kur shton një vdev në pu, atëherë e ke ndotur përhershëm këtë pu me një pajisje me performancë të ulët dhe, siç ndodh zakonisht, nuk ka alternativë tjetër përveçse të shkatërrosh puun dhe të fillosh nga e para. Edhe heqja e vdev-it nuk do të shpëtojë nga konfigurimi i shtrembëruar ashift!
Mekanizmi i kopjimit gjatë shkrimit
Nëse një sistem dosjesh të zakonshëm ka nevojë të riparaqesë të dhënat - ai ndryshon çdo bllok aty ku ndodhet
Sistemi i skedarëve me kopjim gjatë shkrimit regjistron një version të ri të bllokut dhe më pas çliron versionin e vjetër.
Në një formë abstrakte, nëse injorojmë vendosjen fizike reale të bllokëve, «kometa e të dhënave» përkthehet në «bregun e të dhënave», i cili lëviz nga majtas në djathtas në hartën e hapësirës së disponueshme.
Tani mund tĂ« kuptojmĂ« mirĂ« se si funksionojnĂ« snapshot-et e kopjimit gjatĂ« shkrimit â çdo bllok mund t'i pĂ«rkasĂ« disa snapshot-eve dhe do tĂ« ruhet derisa tĂ« shkatĂ«rrohen tĂ« gjitha snapshot-et e lidhura.
Mekanizmi i kopjimit gjatĂ« shkrimit (Copy on Write, CoW) Ă«shtĂ« baza themelore e asaj qĂ« e bĂ«n ZFS njĂ« sistem kaq tĂ« shkĂ«lqyer. Koncepti themelor Ă«shtĂ« i thjeshtĂ« â nĂ«se i kĂ«rkoni njĂ« sistemi tradicional skedari tĂ« ndryshojĂ« njĂ« skedar, do tĂ« bĂ«jĂ« pikĂ«risht atĂ« qĂ« i kĂ«rkoni. NĂ«se i kĂ«rkoni njĂ« sistemi skedari me kopjim gjatĂ« shkrimit tĂ« bĂ«jĂ« tĂ« njĂ«jtĂ«n gjĂ«, ai do tĂ« thotĂ« «mirë» â por do t'ju gĂ«njejĂ«.
Sistemi i skedarëve me kopjim gjatë shkrimit shkruan një version të ri të bllokut të ndryshuar dhe më pas përditëson metadatë e skedarit për të prishur lidhjen me bllokun e vjetër dhe për ta lidhur me bllokun e ri që sapo shkruaja.
ShkĂ«putja e bllokut tĂ« vjetĂ«r dhe lidhja e atij tĂ« ri bĂ«het nĂ« njĂ« operacion, prandaj nuk mund tĂ« ndĂ«rpritet â nĂ«se ndalon energjinĂ« pasi kjo tĂ« ndodhi, do tĂ« kesh njĂ« version tĂ« ri tĂ« skedarit, dhe nĂ«se ndalon energjinĂ« mĂ« herĂ«t, ke versionin e vjetĂ«r. NĂ« çdo rast, nĂ« sistemin e skedarĂ«ve nuk do tĂ« ketĂ« konflikte.
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 ndjeshme ndaj boshllĂ«kut nĂ« shkrim () â njĂ« fenomen ku shiritii Ă«shtĂ« regjistruar vetĂ«m pjesĂ«risht para dĂ«shtimit tĂ« sistemit, duke dĂ«mtuar masivin pas riballafimit. KĂ«tu shiriti shkruhet nĂ« mĂ«nyrĂ« atomike, vdev gjithmonĂ« Ă«shtĂ« i qĂ«ndrueshĂ«m, dhe .
ZIL: regjistri i qëllimeve të ZFS
Sistemi ZFS trajton shkruaj më një mënyrë të veçantë - ai i ruan ato përkohësisht, por menjëherë në ZIL, përpara se më vonë t'i regjistrojë ato përfundimisht, së bashku me shkrimet asinkrone.
Zakonisht, të dhënat e regjistruara në ZIL kurrë nuk lexohen përsëri. Por kjo është e mundur pas një dështimi të sistemit.
SLOG, ose pajisja e dytë LOG, është thjesht një vdev special - dhe, idealisht, shumë e shpejtë - ku ZIL mund të ruhet ndaras nga ruajtja kryesore.
Pas një dështimi, të gjitha të dhënat e papastruara në ZIL riprodhohen - në këtë rast ZIL ndodhet në SLOG, prandaj ato riprodhohen pikërisht nga atje.
Ekzistojnë dy kategori kryesore të operacioneve të shkrimit - sinkrone (sync) dhe asinkrone (async). Për shumicën e ngarkesave të punës, shumica dërrmuese e operacioneve të shkrimit janë asinkrone - sistemi skedar i lejon të aggregojë ato dhe t'i lëshojë në paketë, duke reduktuar fragmentimin dhe duke rritur ndjeshëm kapacitetin.
Shkrimet sinkrone janĂ« njĂ« çështje krejtĂ«sisht tjetĂ«r. Kur aplikacioni kĂ«rkon njĂ« shkrim sinkron, ai i thotĂ« sistemit skedar: 'Ti duhet ta ruash kĂ«tĂ« nĂ« kujtesĂ«n e qĂ«ndrueshme. nĂ« kĂ«tĂ« moment, dhe deri atĂ«herĂ« nuk mund tĂ« bĂ«j asgjĂ« tjetĂ«r». Prandaj, regjistrimet sinkron do tĂ« duhet tĂ« regjistrohen menjĂ«herĂ« nĂ« disk â dhe nĂ«se kjo rrit fragmentimin ose zvogĂ«lon kapacitetin, ashtu tĂ« jetĂ«.
ZFS i trajton regjistrimet sinkron ndryshe nga sistemet e zakonshme tĂ« skedarĂ«ve â nĂ« vend qĂ« t'i dĂ«rgojĂ« ato menjĂ«herĂ« nĂ« memorie tĂ« zakonshme, ZFS i regjistron ato nĂ« njĂ« zonĂ« tĂ« veçantĂ« ruajtjeje tĂ« quajtur regjistri i qĂ«llimeve tĂ« ZFS â ZFS Intent Log, ose ZIL. Truku Ă«shtĂ« se kĂ«to regjistrime po ashtu qĂ«ndrojnĂ« nĂ« memorie, duke u agreguar sĂ« bashku me kĂ«rkesat normale asinkrone pĂ«r regjistrim, pĂ«r t'u ndĂ«rprerĂ« mĂ« vonĂ« nĂ« ruajtje si TXG (grupet e transaksioneve, Transaction Groups) krejtĂ«sisht normale.
NĂ« modalitetin e zakonshĂ«m tĂ« funksionimit, ZIL regjistrohet dhe kurrĂ« nuk lexohet mĂ«. Kur pas disa çastesh regjistrimet nga ZIL regjistrohen nĂ« ruajtjen kryesore nĂ« TXG tĂ« zakonshme nga memoria, ato shkĂ«puten nga ZIL. E vetmja herĂ« kur diçka lexohet nga ZIL â Ă«shtĂ« kur importohet njĂ« grup.
NĂ«se ndodh njĂ« dĂ«shtim ZFS - dĂ«shtim i sistemit operativ ose ndĂ«rprerje e energjisĂ« - kur nĂ« ZIL ka tĂ« dhĂ«na, kĂ«to tĂ« dhĂ«na do tĂ« lexohen gjatĂ« importimit tjetĂ«r tĂ« rezervuarit (p.sh., gjatĂ« ribashkimit tĂ« sistemit tĂ« papritur). Ădo gjĂ« qĂ« Ă«shtĂ« nĂ« ZIL do tĂ« lexohen, do tĂ« bashkohen nĂ« grupe TXG, do tĂ« regjistrohen nĂ« magazinĂ«n kryesore dhe pastaj do tĂ« shkĂ«puten nga ZIL nĂ« procesin e importit.
Një nga klasat ndihmëse vdev quhet LOG ose SLOG, pajisje sekondare LOG. Ai ka një detyrë të vetme - të sigurojë rezervuarin me një pajisje vdev të veçantë dhe, idealisht, shumë më të shpejtë, me një qëndrueshmëri shumë të lartë për shkrim për të ruajtur ZIL, në vend të ruajtjes së ZIL në magazinën kryesore vdev. Vetë ZIL sillet njësoj, pavarësisht nga vendndodhja e ruajtjes, por nëse vdev me LOG ka një performancë shumë të lartë shkrimi, atëherë shkrimet sinkrone do të ndodhin më shpejt.
Shtimi i një vdev me LOG në rezervuar nuk do nuk mundet të përmirësojë performancën e shkrimit asinkron - edhe nëse e detyroni të gjithë shkrimet në ZIL nëpërmjet zfs set sync=always, ato do të jenë të lidhura me ruajtjen kryesore në TXG në të njëjtën mënyrë dhe me të njëjtin ritëm, ashtu si pa regjistrin. Përmirësimi i vetëm i drejtpërdrejtë i performancës është vonesa e shkruarjes sinkrone (ndërsa një shpejtësi më e madhe e regjistrit përshpejton ekzekutimin e operacioneve. sync).
Megjithatë, në një mjedis që tashmë kërkon një numër të madh regjistrimesh sinkrone, vdev LOG mund të përshpejtojë në mënyrë indirekte regjistrimin asinkron dhe leximin pa cache. Shkarkimi i regjistrimeve ZIL në një vdev LOG të veçantë do të thotë më pak konkurrencë për IOPS në ruajtjen primare, e cila ndihmon në përmirësimin e performancës së të gjitha operacioneve të leximit dhe shkruarjes në njëfarë mënyre.
Snapshotet
Mekani i kopjimit gjatë shkruarjes gjithashtu është një bazë e nevojshme për snapshots atomike të ZFS dhe replikimin inkremental asinkron. Në një sistem aktiv skedari ka një pemë treguesish që shënon të gjitha regjistrimet me të dhënat aktuale - kur bëni një snapshot, thjesht bëni një kopje të kësaj peme treguesish.
Kur një regjistër në sistemin e skedarëve aktiv rishtypet, ZFS fillimisht shkruan një version të ri të bllokut në hapësirën e papërdorur. Pastaj, ai shkëput versionin e vjetër të bllokut nga sistemi aktual i skedarëve. Por nëse ndonjë snapshot i referohet bllokut të vjetër, ai mbetet i pandryshuar. Blloku i vjetër në të vërtetë nuk do të kthehet në hapësirë të lirë derisa të gjitha snapshot-et që i referohen këtij blloku të shkatërrohen!
Replikimi
Biblioteka ime Steam nĂ« vitin 2015 zinte 158 GiB dhe pĂ«rfshinte 126,927 skedare. Kjo Ă«shtĂ« mjaft afĂ«r situatĂ«s optimale pĂ«r rsync â replikimi ZFS nĂ« rrjet ishte "veçse" 750% mĂ« i shpejtĂ«.
NĂ« tĂ« njĂ«jtin rrjet, replikimi i njĂ« skedari 40-gigabajt tĂ« imazhit tĂ« makinerisĂ« virtuale Windows 7 â Ă«shtĂ« njĂ« histori krejt tjetĂ«r. Replikimi ZFS ndodh 289 herĂ« mĂ« shpejt se rsync â ose "veçse" 161 herĂ« mĂ« shpejt, nĂ«se jeni mjaft tĂ« pĂ«rgatitur pĂ«r tĂ« thirrur rsync me çelĂ«sin âinplace.
Kur imazhi i makines virtuale zgjerohet, problemet e rsync zgjerojnĂ« gjithashtu me tĂ«. MadhĂ«sia prej 1.9 TiB nuk Ă«shtĂ« aq e madhe pĂ«r imazhin modern tĂ« makines virtuale â por Ă«shtĂ« mjaft e madhe sa qĂ« riplikimi ZFS tĂ« jetĂ« 1148 herĂ« mĂ« i shpejtĂ« se rsync, edhe me argumentin rsync âinplace.
Sapo të kuptoni se si funksionojnë snapshot-et, do të jetë e lehtë të kapni kuptimin e riplikimit. Duke qenë se një snapshot është thjesht një pemë drejtuesish për regjistrimet, kjo do të thotë se nëse ne krijojmë zfs send një snapshot, ne dërgojmë gjithashtu këtë pemë dhe të gjitha regjistrimet e saj të lidhura. Kur e dërgojmë këtë zfs send në zfs receive në objektin e synimit, ai shkruan si përmbajtjen faktike të bllokut ashtu edhe pemën e drejtuesve që referojnë blloqet në setin e të dhënave të synimit.
Tani bëhet edhe më interesante në të dytin zfs send. Tani kemi dy sisteme, secila përmban poolname/datasetname@1, dhe ju nxirrni një snapshot të ri poolname/datasetname@2. Prandaj, në pulin origjinal keni datasetname@1 dhe datasetname@2, ndërsa në pulin e synimit keni vetëm snapshot-in e parë. datasetname@1.
Duke qenĂ« se midis burimit dhe qĂ«llimit kemi njĂ« snapshot tĂ« pĂ«rbashkĂ«t datasetname@1, ne mund tĂ« bĂ«jmĂ« inkrementale zfs send mbi tĂ«. Kur flasim me sistemin zfs send -i poolname/datasetname@1 poolname/datasetname@2, kra krahasohet dy pemĂ«t e treguesve. Ădo tregues, qĂ« ekziston vetĂ«m nĂ« @2, natyrisht, referon nĂ« blloqe tĂ« reja â prandaj na nevojitet pĂ«rmbajtja e kĂ«tyre bllokĂ«ve.
Në sistemin e largët, përpunimi i inkrementit dërgo është po aq i thjeshtë. Së pari regjistrojmë të gjitha shënimet e reja që përfshihen në rrjedhë dërgo, dhe pastaj shtojmë treguesit në këto blloqe. Voilà , e kemi @2 në sistemin e ri!
Replikimi asinkron inkremental i ZFS Ă«shtĂ« njĂ« pĂ«rmirĂ«sim i madh krahasuar me metodat mĂ« tĂ« hershme, jo tĂ« bazuara nĂ« snapshot, si rsync. NĂ« tĂ« dy rastet dĂ«rgohen vetĂ«m tĂ« dhĂ«nat e ndryshuara â por rsync duhet sĂ« pari tĂ« lexohen tĂ« lexojĂ« tĂ« dhĂ«nat nga disku nĂ« tĂ« dyja anĂ«t, pĂ«r tĂ« verifikuar shumĂ«n dhe pĂ«r ta krahasuar atĂ«. Ndryshe nga kjo, replikimi i ZFS nuk lexon asgjĂ« pĂ«rveç pemĂ«ve tĂ« treguesve â dhe çdo bllok qĂ« nuk pĂ«rfaqĂ«sohet nĂ« snapshotin e zakonshĂ«m.
Komprimimi i integruar
Mekanizmi i kopjimit gjatĂ« regjistrimit e thjeshton gjithashtu sistemin e kompresionit tĂ« integruar. NĂ« sistemet tradicionale tĂ« skedarĂ«ve, kompresimi Ă«shtĂ« problematik â si versioni i vjetĂ«r ashtu edhe versi i ri i tĂ« dhĂ«nave tĂ« ndryshuara ndodhen nĂ« tĂ« njĂ«jtin hapĂ«sirĂ«.
NĂ«se shqyrtojmĂ« njĂ« copĂ« tĂ« dhĂ«nash nĂ« mes tĂ« skedarit, i cili fillon jetĂ«n e tij si njĂ« megabajt i zerove nga 0x00000000 dhe kĂ«shtu me radhĂ« â Ă«shtĂ« shumĂ« e lehtĂ« ta kompresosh deri nĂ« njĂ« sektor nĂ« disk. Por çfarĂ« do tĂ« ndodhte nĂ«se do ta zĂ«vendĂ«sonim kĂ«tĂ« megabajt zerosh me njĂ« megabajt tĂ« dhĂ«nash qĂ« nuk mund tĂ« kompresohen, si JPEG ose zhurmĂ« pseudo-rastĂ«sore? Papritur, ky megabajt tĂ« dhĂ«nash do tĂ« kĂ«rkonte jo njĂ«, por 256 sektore prej 4 KiB, ndĂ«rsa nĂ« kĂ«tĂ« vend nĂ« disk Ă«shtĂ« rezervuar vetĂ«m njĂ« sektor.
ZFS nuk ka kĂ«tĂ« problem, pasi regjistrimet e ndryshuara gjithmonĂ« shkruhen nĂ« hapĂ«sirĂ«n e papĂ«rdorur â blloku origjinal merr vetĂ«m njĂ« sektor 4 KiB, ndĂ«rsa regjistrimi i ri do tĂ« marrĂ« 256, por kjo nuk Ă«shtĂ« problem â njĂ« copĂ« e ndryshuar nga «mes» i skedarit do tĂ« shkruhej nĂ« hapĂ«sirĂ«n e papĂ«rdorur pavarĂ«sisht nga ndryshimi i madhĂ«sisĂ« sĂ« tij, prandaj pĂ«r ZFS kjo Ă«shtĂ« njĂ« situatĂ« krejt e zakonshme.
Shtypja e integruar ZFS Ă«shtĂ« e fikur si parazgjedhje, dhe sistemi ofron algoritme tĂ« lidhura â tani midis atyre janĂ« LZ4, gzip (1-9), LZJB dhe ZLE.
- LZ4 â Ă«shtĂ« njĂ« algoritĂ«m rrjedhĂ«sor qĂ« ofron kompresim dhe dekompresim jashtĂ«zakonisht tĂ« shpejtĂ« dhe pĂ«rfitime nĂ« performancĂ« pĂ«r shumicĂ«n e rasteve tĂ« pĂ«rdorimit â edhe nĂ« CPU mjaft tĂ« ngadalta.
- GZIP â njĂ« algoritĂ«m i nderuar, i njohur dhe i dashur nga tĂ« gjithĂ« pĂ«rdoruesit e sistemeve Unix. Ai mund tĂ« realizohet me nivele kompresimi 1-9, me rritjen e gradĂ«s sĂ« kompresimit dhe pĂ«rdorimin e CPU-sĂ« ndĂ«rsa afrohet nĂ« nivelin 9. Algoritmi Ă«shtĂ« shumĂ« i pĂ«rshtatshĂ«m pĂ«r tĂ« gjitha pĂ«rdorimet tekstuale (ose variante tĂ« tjera jashtĂ«zakonisht tĂ« kompresueshme), por pĂ«rndryshe shpesh shkakton probleme me CPU-nĂ« â pĂ«rdoreni me kujdes, veçanĂ«risht nĂ« nivele mĂ« tĂ« larta.
- LZJB â algoritmi origjinal nĂ« ZFS. Ai Ă«shtĂ« i vjetruar dhe nuk duhet mĂ« tĂ« pĂ«rdoret, LZ4 e tejkalon atĂ« nĂ« tĂ« gjitha parametrat.
- ZLE â kodimi i nivelit zero, Zero Level Encoding. Ai nuk prek tĂ« dhĂ«nat normale, por kompreson sekuenca tĂ« mĂ«dha zeros. E dobishme pĂ«r grupe tĂ« dhĂ«nash krejtĂ«sisht tĂ« pakompresueshme (p.sh., JPEG, MP4 ose formate tĂ« tjera qĂ« janĂ« tashmĂ« tĂ« kompresuara), sepse injoron tĂ« dhĂ«nat e pakompresueshme, por kompreson hapĂ«sirĂ«n e pavendosur nĂ« regjistrat pĂ«rfundimtarĂ«.
Ne rekomandojmë kompresimin LZ4 për pothuajse të gjitha rastet e përdorimit; ndëshkimi për performancën kur hasni të dhëna të pakompresueshme është shumë i vogël, dhe rritje performanca për të dhëna tipike është e konsiderueshme. Kopjimi i imazhit të makinerisë virtuale për një instalim të ri të sistemit operativ Windows (sistemi i sapo-instaluar, pa të dhëna brenda) me compression=lz4 ka kaluar 27% më shpejt se me compression=none, në .
ARC â cache adaptiv i zĂ«vendĂ«simit
ZFS â Ă«shtĂ« sistemi i vetmĂ« modern i skedarĂ«ve tĂ« njohur qĂ« pĂ«rdor mekanizmin e tij pĂ«r ruajtjen e leximit, dhe nuk mbĂ«shtetet nĂ« cache-n e faqeve tĂ« sistemit operativ pĂ«r tĂ« ruajtur kopjet e blloqeve tĂ« lexuara sĂ« fundmi nĂ« memorje.
MegjithĂ«se ndihmĂ«sa e vet nuk Ă«shtĂ« pa problemet e saj â ZFS nuk mund tĂ« reagojĂ« aq shpejt ndaj kĂ«rkesave tĂ« reja pĂ«r ndarjen e memories sa bĂ«rthama, kĂ«shtu qĂ« njĂ« thirrje e re malloc() pĂ«r alokimin e memories mund tĂ« dĂ«shtojĂ« nĂ«se i duhet memoria e operativĂ«s, e zĂ«nĂ« aktualisht nga ARC. Por ka arsye tĂ« forta pĂ«r tĂ« pĂ«rdorur ndihmĂ«sin e vet, tĂ« paktĂ«n tani.
Të gjitha sistemet operative moderne të njohura, duke përfshirë MacOS, Windows, Linux dhe BSD, përdorin algoritmin LRU (Më së Fundi të Përdorur) për të implementuar keshin e faqeve. Ky është një algoritëm primitiv që ngre bllokun e keshit "lart në radhë" pas çdo leximi dhe e dëbon bllokun "poshtë në radhë" sipas nevojës për të shtuar humbjet e reja të keshit (blloket që duhej të ishin lexuar nga disku, jo nga kesh) lart.
Zakonisht, algoritmi punon mirĂ«, por nĂ« sisteme me grupe tĂ« mĂ«dha tĂ« tĂ« dhĂ«nave, LRU lehtĂ« çon nĂ« trashjen e tĂ« dhĂ«nave â dĂ«bimin e blloqeve qĂ« zakonisht nevojiten, pĂ«r tĂ« liruar vend pĂ«r blloqet qĂ« kurrĂ« mĂ« nuk do tĂ« lexohen nga kesh.
 â njĂ« algoritĂ«m shumĂ« mĂ« pak naive, i cili mund tĂ« konsiderohet si njĂ« cache "me pesha". Pas çdo leximi tĂ« bllokut tĂ« cache-it, ai bĂ«het pak "mĂ« i rĂ«ndĂ«" dhe bĂ«het mĂ« e vĂ«shtirĂ« tĂ« largohesh â dhe madje edhe pas largimit, blloku ndjeket pĂ«r njĂ« periudhĂ« tĂ« caktuar kohore. NjĂ« bllok, i cili Ă«shtĂ« larguar, por mĂ« pas duhet tĂ« lexohet pĂ«rsĂ«ri nĂ« cache, do tĂ« bĂ«het gjithashtu "mĂ« i rĂ«ndĂ«".
Rezultati pĂ«rfundimtar i gjithĂ« kĂ«saj Ă«shtĂ« njĂ« cache me njĂ« raport shumĂ« mĂ« tĂ« lartĂ« tĂ« goditjeve (hit ratio) â proporcioni midis goditjeve nĂ« cache (leximi i kryer nga cache) dhe humbjeve (leximi nga disku). Kjo Ă«shtĂ« njĂ« statistikĂ« jashtĂ«zakonisht e rĂ«ndĂ«sishme â jo vetĂ«m qĂ« vetĂ« goditjet nĂ« cache shĂ«rbehen shumĂ« mĂ« shpejt, por edhe humbjet nĂ« cache mund tĂ« shĂ«rbehen mĂ« shpejt, pasi sa mĂ« shumĂ« goditje nĂ« cache â aq mĂ« pak kĂ«rkesa paralelesh pĂ«r disk dhe aq mĂ« e ulĂ«t Ă«shtĂ« vonesa pĂ«r ato humbje tĂ« mbetura, tĂ« cilat duhet tĂ« shĂ«rbehen nga disku.
PĂ«rfundimi
Pas studimit të semantikës themelore të ZFS - si funksionon kopjimi në shkrim, si dhe marrëdhëniet midis rezervave të ruajtjes, pajisjeve virtuale, blloqeve, sektorëve dhe skedarëve, jemi gati të diskutojmë për performancën reale me numra realë.
Në pjesën e ardhshme do të shqyrtojmë performancën faktike të rezervave me vdev të pasqyruar dhe RAIDz, njëri në krahasim me tjetrin, si dhe në krahasim me topologjitë tradicionale RAID të kernelit Linux që kemi hetuar. .
Fillimisht ne do të donim të shqyrtonim vetëm bazat - vetë topologjitë e ZFS - por pas tillave do të jemi të gatshëm të flasim për konfigurimin dhe optimizimin më të avancuar të ZFS, duke përfshirë përdorimin e llojeve mbështetëse të vdev, siç janë L2ARC, SLOG dhe Special Allocation.
Burimi: habr.com
