{"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\/et\/blog\/administrirovanie\/osnovy-zfs-sistema-hraneniya-i-proizvoditelnost","title":{"rendered":"ZFS p\u00f5hialused: salvestuss\u00fcsteem ja j\u00f5udlus","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"ZFS
\n
\nSel kevadel oleme juba arutanud mitmeid algteemasid, nagu n\u00e4iteks kuidas kontrollida oma k\u00f5vakettaste kiirus<\/a><\/noindex> ja mis on RAID<\/a><\/noindex>. Teises osas lubasime j\u00e4tkata arutelusid ZFS erinevate mitme ketta topoloogiate j\u00f5udluse \u00fcle. See on j\u00e4rgmise p\u00f5lvkonna failis\u00fcsteem, mida rakendatakse praegu igal pool: alates Apple<\/a><\/noindex> kuni Ubuntu<\/a><\/noindex>.
\n<\/a><\/noindex>
\nNoh, t\u00e4na on meeste ja naiste \u00f5ige p\u00e4ev ZFS-iga tutvumiseks, uudishimu tekitavad lugejad. Lihtsalt teadke, et OpenZFS arendaja Matt Ahrens'i tagasihoidlikul hinnangul \"see on t\u00f5eliselt keeruline\".<\/p>\n

Enne kui j\u00f5uame numbriteni - ja need tulevad, luban - k\u00f5ikide ZFS kaheksa ketta konfigureerimise v\u00f5imaluste osas, peame r\u00e4\u00e4kima sellest, kuidas<\/i> ZFS \u00fcldiselt andmeid kettal salvestab.<\/p>\n

Zpool, vdev ja seade<\/h1>\n

\n\"ZFS
\nSee diagramm igavik t\u00e4ielik bassein h\u00f5lmab kolme abivahendit vdev’ist, \u00fcks igast klassist, ja nelja RAIDz2 jaoks.<\/i><\/p>\n

\"ZFS
\nTavaliselt pole p\u00f5hjust luua kogumit erinevat t\u00fc\u00fcpi ja suurusega vdevidest - kuid kui soovite, ei takista teid see kindlasti.<\/i><\/p>\n

ZFS failis\u00fcsteemi t\u00f5eliseks m\u00f5istmiseks tuleb t\u00e4helepanelikult vaadata selle tegelikku struktuuri. Esiteks \u00fchendab ZFS traditsioonilise mahuhalduse ja failis\u00fcsteemide tasemed. Teiseks kasutab see kirjutamise ajal koopia loomise tehingu mehhanismi. Need omadused t\u00e4hendavad, et s\u00fcsteem on struktuuri poolest v\u00e4ga erinev tavalistest failis\u00fcsteemidest ja RAID-massiividest. Esimene m\u00f5istmise p\u00f5hielement on salvestuspank (zpool), virtuaalne seade (vdev) ja reaalne seade (device).<\/p>\n

zpool<\/h3>\n

\nSalvestuspank zpool on ZFS k\u00f5ige \u00fclemine struktuur. Iga pank sisaldab \u00fchte v\u00f5i mitut virtuaalset seadet. Omakorda sisaldab iga\u00fcks neist \u00fchte v\u00f5i mitut reaalset seadet (device). Virtuaalsed pangad on iseseisvad plokid. \u00dcks f\u00fc\u00fcsiline arvuti v\u00f5ib sisaldada kahte v\u00f5i enamat eraldi panka, kuid iga\u00fchel on t\u00e4ielik s\u00f5ltumatus teistest. Pangad ei saa jagada virtuaalseid seadmeid.<\/p>\n

ZFS-i \u00fclekandmine toimub virtuaalsete seadmete tasandil, mitte reservuaaride tasandil. Reservuaaride tasandil ei ole mingit \u00fclekands\u00fcsteemi - kui m\u00f5ni vdev v\u00f5i erivdev kaob, kaob koos sellega kogu reservuaar.<\/p>\n

Kaasaegsed salvestusreservuaarid suudavad taluda virtuaalse seadme vahem\u00e4lu v\u00f5i \u017eurnali kaotust - kuigi nad v\u00f5ivad kaotada v\u00e4ikese hulga rikutud andmeid, kui nad kaotavad vdevi \u017eurnali voolukatkestuse v\u00f5i s\u00fcsteemi rikke ajal.<\/p>\n

On levinud v\u00e4\u00e4rarusaam, et ZFS-i \"andmeriidud\" (stripe'id) salvestatakse kogu reservuaari ulatuses. See ei ole t\u00f5si. Zpool ei ole sugugi naljakas RAID0, vaid pigem naljakas JBOD<\/a><\/noindex> keerulise ja muutuva jaotamismechanismiga.<\/p>\n

Peamiselt jaotatakse salvestused saadavalolevate virtuaalsete seadmete vahel olemasoleva vaba ruumi alusel, nii et seeoretiseeritult t\u00e4idavad need k\u00f5ik korraga. Uuemates ZFS versioonides arvestatakse praegust kasutust (utiliseerimist) vdev'i puhul \u2014 kui \u00fcks virtuaalne seade on oluliselt koormatum kui teine (n\u00e4iteks lugemise koormuse t\u00f5ttu), j\u00e4etakse selle kirjutamiseks vahepeal k\u00f5rvale, hoolimata k\u00f5rgeimast vabade ruumide osakaalust.<\/p>\n

Utiliseerimise m\u00e4\u00e4ramise mehhanism, mis on integreeritud kaasaegsetesse ZFS salvestusmeetoditesse, v\u00f5ib v\u00e4hendada viivitust ja suurendada l\u00e4bilaskev\u00f5imet ebatavaliselt k\u00f5rgete koormuste perioodidel \u2014 kuid see ei blankett<\/i> kui juhuslik segu aeglastest HDD-dest ja kiiretest SSD-dest \u00fches soos. Selline eba\u00fchtlane soe t\u00f6\u00f6tab siiski aeglaseima seadme kiirusel, nagu oleks see t\u00e4ielikult koos sellistest seadmetest.<\/p>\n

vdev<\/h3>\n

\nIga salvestuspools koosneb \u00fchest v\u00f5i mitmest virtuaalsest seadmest (virtual device, vdev). Iga vdev omakorda sisaldab \u00fchte v\u00f5i mitut f\u00fc\u00fcsilist seadet. Enamik virtuaalseid seadmeid kasutatakse andmete lihtsaks salvestamiseks, kuid on olemas ka mitmeid abiklasse vdev, sealhulgas CACHE, LOG ja SPECIAL. Igal neist vdev-i t\u00fc\u00fcpide puhul v\u00f5ib olla \u00fcks viiest topoloogiast: \u00fches seadmest (single-device), RAIDz1, RAIDz2, RAIDz3 v\u00f5i peegel (mirror).<\/p>\n

RAIDz1, RAIDz2 ja RAIDz3 on erilised variandid, mida vanad inimesed nimetasid RAID kahekordseks (diagonaalseks) pariteediks. 1, 2 ja 3 viitavad sellele, kui palju pariteediblokeerimist on eraldatud iga andmevoo jaoks. Selle asemel, et kasutada eraldi kettaid pariteedi tagamiseks, jaotavad RAIDz virtuaalsed seadmed selle pariteedi \u00fchtlaselt diskide vahel. RAIDz-massiiv v\u00f5ib kaotada sama arvu kettaid, kui tal on pariteediblokeerimisi; kui see kaotab veel \u00fche, siis see lakkab t\u00f6\u00f6tamast ja viib kaasa salvestuspooli.<\/p>\n

Peegeldavad virtuaalsed seadmed (mirror vdev) salvestavad iga ploki igas seadmes vdev'is. Kuigi k\u00f5ige levinumad on topeltpeeglid (two-wide), v\u00f5ib peeglis olla meelevaldne arv seadmeid \u2014 suuremates seadmetes kasutatakse sageli kolmikuid lugemisv\u00f5imekuse ja t\u00f5rke taluvuse parandamiseks. Vdev peegel suudab \u00fcle elada mis tahes t\u00f5rke, kui vdev'is t\u00f6\u00f6tab v\u00e4hemalt \u00fcks seade.<\/p>\n

\u00dcksikud vdev'id on oma olemuselt ohtlikud. Selline virtuaalne seade ei talleta t\u00f5rget \u2014 ja kui seda kasutatakse salvestusena v\u00f5i spetsiaalse vdev'ina, toob selle t\u00f5rge kaasa kogu basseini h\u00e4vimise. Olge siin v\u00e4ga ettevaatlik.<\/p>\n

Virtuaalsed seadmed CACHE, LOG ja SPECIAL v\u00f5ivad olla loodud mis tahes eespool mainitud topoloogiate p\u00f5hjal \u2014 kuid pidage meeles, et virtuaalse seadme SPECIAL kaotus t\u00e4hendab basseini kadumist, seet\u00f5ttu on soovitatav \u00fcleliigne topoloogia.<\/p>\n

device<\/h3>\n

\nT\u00f5en\u00e4oliselt on see ZFS-i kontekstis k\u00f5ige arusaadavam termin \u2013 see viitab tegelikult juhusliku ligip\u00e4\u00e4su blokiseadmestikule. Pea meeles, et virtuaalsed seadmed koosnevad eraldi seadmetest ning bassein koosneb virtuaalsetest seadmetest.<\/p>\n

Kettad \u2013 kas magnetilised v\u00f5i SSD-d \u2013 on k\u00f5ige levinumad blokeeringuseadmestikud, mida kasutatakse vdev-i ehitusplokkidena. Kuid sobib iga seade, millel on kirjeldus \/dev-s \u2013 seega v\u00f5ivad eraldi seadmetena kasutada isegi terveid riistvaralisi RAID-massiive.<\/p>\n

Lihtne raw-fail on \u00fcks t\u00e4htsamaid alternatiivseid blokeeringuseadmestikke, mille baasil v\u00f5ib vdev-i luua. Testbasseinid, mis on t\u00fchjad failid<\/a><\/noindex>\u00a0\u2013 on v\u00e4ga mugav viis k\u00e4skude testimiseks ja j\u00e4lgimiseks, kui palju ruumi on basses v\u00f5i antud topoloogias virtuaalses seadmes saadaval.<\/p>\n

\"ZFS
\nSa saad luua testbasseini t\u00fchjadest failidest vaid m\u00f5ne sekundiga \u2013 aga \u00e4ra unusta seej\u00e4rel kogu basseini ja selle komponente kustutada.<\/i> <\/p>\n

Oletame, et soovite seadistada serverit kaheksa k\u00f5vakettaga ja kavatsete kasutada 10 TB (~9300 GiB) kettaid \u2014 kuid te ei ole kindel, milline topoloogia vastab k\u00f5ige paremini teie vajadustele. \u00dclaltoodud n\u00e4ites loome m\u00f5ne sekundi jooksul katsepilu hajutatud failideks \u2014 ja n\u00fc\u00fcd teame, et kaheksast 10 TB ketast koosnev RAIDz2 vdev pakub 50 TiB kasulikku mahutavust.<\/p>\n

Veel \u00fcks eriline seadmete klass on SPARE (varu). Kuumalt vahetatavad seadmed erinevad tavap\u00e4rastest seadmetest, kuna need kuuluvad kogu pilvele, mitte ainult \u00fchele virtuaalseadmele. Kui m\u00f5ni vdev pilves eba\u00f5nnestub ja reserveeritud seade on pilvega \u00fchendatud ja saadaval, liitub see automaatselt kahjustatud vdev-iga.<\/p>\n

P\u00e4rast kahjustatud vdev-iga \u00fchendamist hakkab reserveeritud seade saama koopiaid v\u00f5i \u00fcmber ehitusi andmetest, mis peaksid olema puuduvatel seadmetel. Traditsioonilises RAID-is nimetatakse seda taastamiseks (rebuilding), ZFS-is aga \u201e\u00fclej\u00e4\u00e4gi taastamiseks\u201c (resilvering).<\/p>\n

Oluline on m\u00e4rkida, et varuteenused ei asenda riknenud seadmeid igaveseks. Need on vaid ajutised asendused, et v\u00e4hendada vdev-degrdeerimise ajal kadumisaega. Kui administraator asendab riknenud seadme vdev-is, toimub \u00fcleliigsuse taastamine sellele p\u00fcsivale seadmele, SPARE \u00fchendus katkestatakse vdev-ist ja naaseb varuna kogu basseini jaoks.<\/p>\n

Andmekogud, blokk ja sektorid<\/h1>\n

\nJ\u00e4rgmine ehitusplokkide kogum, mida on vajalik meie ZFS-i teekonna jooksul m\u00f5ista, ei puuduta niiv\u00f5rd riistvara, vaid seda, kuidas andmed on organiseeritud ja salvestatud. Me j\u00e4tame siit vahele m\u00f5ned tasemed, nagu metaslab, et mitte detailidega \u00fcle koormata, s\u00e4ilitades samas \u00fcldise struktuuri m\u00f5istmise.<\/p>\n

Andmekogud (dataset)<\/h3>\n

\n\"ZFS
\nKui loome andmekogu esmakordselt, n\u00e4itab see kogu basseini saadaval olevat ruumi. Siis seadistame kvoodi ja muudame mount-punkti. V\u00f5lu!<\/i> <\/p>\n

\"ZFS
\nZvol on suuresti lihtsalt andmekogu, millel puudub oma failis\u00fcsteemi kiht, mida asendame siin t\u00e4iesti normaalse failis\u00fcsteemiga ext4.<\/i> <\/p>\n

ZFSi andmekogum sarnaneb standardse monteeritud failis\u00fcsteemiga. Nagu tavaline failis\u00fcsteem, n\u00e4ib see esmapilgul \"lihtsalt veel \u00fche kausta\". Kuid nagu tavalistel monteeritud failis\u00fcsteemidel, on igal ZFSi andmekogumil oma p\u00f5hiv\u00e4\u00e4rtuste kogum.<\/p>\n

Esiteks v\u00f5ib andmekogumile olla m\u00e4\u00e4ratud kvoot. Kui seadistada zfs set quota=100G poolname\/datasetname<\/code>, siis ei saa te monteeritud kausta \/poolname\/datasetname<\/code> kirjutada rohkem kui 100 GiB.<\/p>\n

Kas olete m\u00e4rganud, et iga rea alguses on olemas - ja puuduvad - kaldkriipsud? Igal andmekogumil on oma koht nii ZFSi hierarhias kui ka s\u00fcsteemi monteerimise hierarhias. ZFSi hierarhias ei ole algset kaldkriipsu - alustate puu nimest ja seej\u00e4rel tee j\u00e4rgmisest andmekogumist j\u00e4rgmisse. N\u00e4iteks, pool\/vanem\/laps<\/code> andmekogumi nimega laps<\/code> vanema andmekogumi vanem<\/code> loomingulise nimega pool<\/code>.<\/p>\n

Vaikimisi on andmekogumi monteerimispunkt v\u00f5rreldav selle nimega ZFSi hierarhias, algse kaldkriipsuga - puu nimega pool<\/code> monteeritakse kui \/pool<\/code>, andmekogum vanem<\/code> monteeritakse \/pool\/parent<\/code>, ja alandmikuna andmekogum laps<\/code> monteeritakse \/pool\/parent\/child<\/code>. Siiski saab s\u00fcsteemi andmestiku mount-punkti muuta.<\/p>\n

Kui m\u00e4\u00e4rame zfs set mountpoint=\/lol pool\/parent\/child<\/code>, siis andmestik pool\/vanem\/laps<\/code> mountitakse s\u00fcsteemi kui \/lol<\/code>.<\/p>\n

Lisaks andmestikele peame mainima ka mahtu (zvols). Maht on ligikaudu sarnane andmestikule, v\u00e4lja arvatud see, et tal ei ole tegelikult failis\u00fcsteemi \u2014 see on lihtsalt plokkseade. N\u00e4iteks v\u00f5ite luua zvol<\/code> nimega mypool\/myzvol<\/code>, seej\u00e4rel vormindada selle failis\u00fcsteemiga ext4 ja seej\u00e4rel mountida selle failis\u00fcsteemi \u2014 n\u00fc\u00fcd on teil ext4 failis\u00fcsteem, kuid ZFS-i terviklikkuse funktsioonidega! See v\u00f5ib tunduda rumal \u00fche arvuti puhul, kuid on palju m\u00f5istlikum iSCSI seadme eksportimise tagasiside osana.<\/p>\n

Plokid<\/h3>\n

\n\"ZFS
\nFail esindab \u00fchte v\u00f5i mitut plokki. Iga plokk salvestatakse \u00fchel virtuaalsel seadmel. Ploki suurus on tavaliselt seadistuse recordsize<\/b>, kuid v\u00f5ib olla v\u00e4hendatud 2^ashift<\/b>, kui see sisaldab metaandmeid v\u00f5i v\u00e4ikest faili.<\/i><\/p>\n

\"ZFS
\nMe t\u00f5esti, t\u00f5esti<\/b> ei nalja tohutu j\u00f5udluse kaotuse osas, kui seadistate liiga v\u00e4ikese ashift'i<\/i><\/p>\n

ZFS-i kontekstis salvestatakse k\u00f5ik andmed, sealhulgas metainformatsioon, plokkides. Iga andmehulgaga seotud ploki maksimaalne suurus m\u00e4\u00e4ratakse atributi kaudu recordsize<\/code> (sisalduse suurus). Andme\u00fcksuse suurus v\u00f5ib varieeruda, kuid see ei muuda juba salvestatud plokkide suurust ega asukohta \u2014 see kehtib ainult uute plokkide jaoks nende salvestamisel.<\/p>\n

Kui ei ole m\u00e4\u00e4ratud teisiti, on vaikimisi andmesalvestuse suurus 128 KiB. See on omamoodi keeruline kompromiss, kus j\u00f5udlus on enamasti k\u00fcllaltki hea, kuid mitte ideaalne. Sisalduse suurus<\/code> v\u00f5ib seada vahemikku 4K kuni 1M (t\u00e4iendavate seadistustega recordsize<\/code> v\u00f5ib seadistada isegi suuremaks, kuid see ei ole sageli hea idee).<\/p>\n

Iga plokk viitab ainult \u00fche faili andmetele \u2014 teist faili ei saa sama plokki mahutada. Iga fail koosneb \u00fchest v\u00f5i mitmest plokist, olenevalt suurusest. Kui faili suurus on v\u00e4iksem kui andmesalvestuse suurus, salvestatakse see v\u00e4iksemas plokis \u2014 n\u00e4iteks 2 KiB faili sisaldav plokk v\u00f5tab kettal \u00e4ra vaid \u00fche 4 KiB sektori.<\/p>\n

Zvol volumentidel ei ole omadust recordsize<\/code>\u00a0\u2014 selle asemel on neil v\u00f5rdne omadus volblocksize<\/code>.<\/p>\n

Sektsioonid<\/h3>\n

\nViimane ja k\u00f5ige elementaarsem ehitusplokk on sektsioon. See on v\u00e4ikseim f\u00fc\u00fcsiline \u00fchik, mida saab salvestada v\u00f5i lugeda algsest seadmest. Aastak\u00fcmnete jooksul on enamik diskidest kasutanud 512-baidiseid sektsioone. Viimasel ajal on enamik diskidest seadistatud 4 KiB sektsioonide peale, samas kui m\u00f5ned \u2014 eriti SSD-d \u2014 kasutavad sektsioone, mis on 8 KiB v\u00f5i isegi rohkem.<\/p>\n

ZFS s\u00fcsteemis on omadus, mis v\u00f5imaldab manuaalselt seadistada sektsiooni suuruse. See omadus ashift<\/code>. Veidi segane on see, et ashift on kahe astme. N\u00e4iteks, ashift=9<\/code> t\u00e4hendab sektsiooni suurust 2^9 ehk 512 bahti.<\/p>\n

ZFS k\u00fcsib operatsioonis\u00fcsteemilt igasugust teavet iga plokiseadmest, kui see lisatakse uut t\u00fc\u00fcpi vdev-ile, ning teoreetiliselt seab see automaatselt ashifti \u00f5igeks, tuginedes sellele teabele. Kahjuks valevad paljud kettad oma sektorite suuruses, et s\u00e4ilitada \u00fchilduvus Windows XP-ga (mis ei suutnud m\u00f5ista kettaid, millel on erinevad sektorite suurused).<\/p>\n

See t\u00e4hendab, et ZFS administraator peab kindlasti teadma oma seadmete tegelikku sektorite suurust ja seadma selle k\u00e4sitsi ashift<\/code>. Kui ashift on seatud liiga v\u00e4ikeseks, siis suureneb lugemise\/kirjutamise operatsioonide arv astronoomiliselt. N\u00e4iteks 512-aatomiliste \"sektorite\" kirjutamine tegelikku 4 KiB-sektorisse t\u00e4hendab, et tuleb kirjutada esimene \"sektor\", seej\u00e4rel lugeda 4 KiB sektorit, muuta seda teise 512-aatomilise \"sektoriga\", kirjutada see tagasi uude 4 KiB sektorisse ja nii edasi iga kirjutise jaoks.<\/p>\n

Tegelikus maailmas tabab selline trahv Samsung EVO tahkiskettaid, mille puhul peaks kehtima ashift=13<\/code>, kuid need SSD-d valetavad oma sektorite suuruse kohta, seet\u00f5ttu on see vaikimisi seatud ashift=9<\/code>. Kui kogenud s\u00fcsteemiadministraator seda parameetrit ei muuda, t\u00f6\u00f6tab see SSD aeglasemalt<\/i> tavalise magnetse HDD-ga.<\/p>\n

V\u00f5rdluseks, liiga suure suuruse eest ashift<\/code> praktiliselt ei tule mingeid karistusi. Tegelikku j\u00f5udluse langust ei esine ja kasutamata ruumi suurenemine on \u00e4\u00e4rmiselt v\u00e4ike (v\u00f5i null, kui on sisse l\u00fclitatud tihendamine). Seet\u00f5ttu soovitame tungivalt isegi neile ketastele, mis t\u00f5eliselt kasutavad 512-baidiseid sektoreid, seadistada ashift=12<\/code> v\u00f5i isegi ashift=13<\/code>, et kindlalt tulevikku vaadata.<\/p>\n

Omadus ashift<\/code> seatakse iga virtuaalse seadme vdev jaoks, mitte pala<\/i>, nagu paljud ekslikult arvavad \u2014 ja seda ei muudeta p\u00e4rast seadistamist. Kui te juhuslikult rikkusite ashift<\/code> uue vdev-i lisamisega pala, siis olete j\u00e4\u00e4davalt saastanud selle pala madala j\u00f5udlusega seadmega ja tavaliselt pole teisi v\u00f5imalusi, v\u00e4lja arvatud pale h\u00e4vitamine ja uuesti alustamine. Isegi vdev-i eemaldamine ei p\u00e4\u00e4sta vale seadistuse eest ashift<\/code>!<\/p>\n

Kirjutamise ajal kopeerimise mehhanism<\/h3>\n

\n\"ZFS
\nKui tavaline failis\u00fcsteem peab andmeid \u00fcle kirjutama \u2014 muudab see iga ploki seal, kus see asub<\/i><\/p>\n

\"ZFS
\nFailos\u00fcsteem kopeerimise kirjutamisel salvestab uue ploki versiooni ja seej\u00e4rel vabastab vana versiooni.<\/i><\/p>\n

\"ZFS
\nAbstraktselt \u00f6eldes, kui ignoreerida plokkide tegelikku f\u00fc\u00fcsilist asukohta, lihtsustub meie 'andmete komeet' 'andmete ussiks', mis liigub vasakult paremale saadaval oleva ruumi kaardil.<\/i><\/p>\n

\"ZFS
\nN\u00fc\u00fcd saame h\u00e4sti aru, kuidas kopeerimise kirjutamise sn\u00e4pp\u0161otid t\u00f6\u00f6tavad \u2014 iga plokk v\u00f5ib kuuluda mitmesse sn\u00e4pp\u0161otti ning p\u00fcsib, kuni k\u00f5ik seotud sn\u00e4pp\u0161otid on h\u00e4vitatud.<\/i><\/p>\n

Kopeerimise kirjutamise mehhanism (Copy on Write, CoW) on fundamentaalne alus, mis teeb ZFSi nii uskumatuks s\u00fcsteemiks. Peamine kontseptsioon on lihtne \u2014 kui palute traditsioonilisel failis\u00fcsteemil faili muuta, teeb ta just seda, mida palusite. Kui palute kopeerimise kirjutamise failis\u00fcsteemil sama teha, \u00fctleb ta 'hea k\u00fcll' \u2014 aga valetab teile.<\/p>\n

Selle asemel kirjutab failis\u00fcsteem kirjutamise kopeerimisega uue versiooni muudetud blokkist ning seej\u00e4rel uuendab faili metaandmed, et katkestada seos vana blokiga ja siduda see uue blotiga, mille just kirjutasite.<\/p>\n

Vana bloki lahti\u00fchendamine ja uue sidumine toimub \u00fche operatsiooni k\u00e4igus, mist\u00f5ttu ei saa seda katkestada \u2014 kui l\u00fclitate toite v\u00e4lja p\u00e4rast seda, kui see on toimunud, on teil uus failiversioon, ja kui l\u00fclitate toite v\u00e4lja enne seda, on teil vana versioon. Igatahes ei teki failis\u00fcsteemis konflikte.<\/p>\n

Kirjutamise kopeerimine ZFS-is toimub mitte ainult failis\u00fcsteemi tasandil, vaid ka ketaste haldamise tasandil. See t\u00e4hendab, et ZFS ei ole tundlik kirjutamispuuduste suhtes (RAID-i augu<\/a><\/noindex>) \u2014 fenomen, kus riba \u00f5nnestus osaliselt kirjutada enne s\u00fcsteemi t\u00f5rget, kahjustades massiivi p\u00e4rast taask\u00e4ivitamist. Siin kirjutatakse riba aatomaariselt, vdev on alati j\u00e4rjekindel, ja Bob on sinu onu<\/a><\/noindex>.<\/p>\n

ZIL: ZFS-i kavatsuste ajakiri<\/h3>\n

\n\"ZFS
\nZFS s\u00fcsteem t\u00f6\u00f6tleb s\u00fcnkroonne kirjutisi eriliselt \u2013 see salvestab need ajutiselt, kuid kohe ZIL-i, enne kui kirjutab need hiljem p\u00fcsivalt koos as\u00fcnkroonsete kirjutistega.<\/i><\/p>\n

\"ZFS
\nTavaliselt ei loeta ZIL-is salvestatud andmeid enam kunagi v\u00e4lja. Kuid see on v\u00f5imalik p\u00e4rast s\u00fcsteemi riket.<\/i><\/p>\n

\"ZFS
\nSLOG ehk sekundaarne LOG-seade on lihtsalt eriline \u2013 ja eelistatavalt v\u00e4ga kiire \u2013 vdev, kus ZIL-i saab salvestada eraldi peamisest salvestusruumist.<\/i><\/p>\n

\"ZFS
\nP\u00e4rast riket loetakse k\u00f5ik m\u00e4\u00e4rdunud andmed ZIL-ist taastatavaks \u2013 antud juhul asub ZIL SLOG-is, nii et need loetakse sealt.<\/i><\/p>\n

On olemas kaks peamist kirjutamise operatsiooni kategooriat \u2013 s\u00fcnkroonsed (sync) ja as\u00fcnkroonsed (async). Enamikus t\u00f6\u00f6koormustes on enamus kirjutamistegevusi as\u00fcnkroonsed \u2013 failis\u00fcsteem v\u00f5imaldab neid koguda ja v\u00e4lja anda pakettidena, v\u00e4hendades fragmenteerimist ja oluliselt suurendades l\u00e4bilaskev\u00f5imet.<\/p>\n

S\u00fcnkroonsed kirjutised on hoopis midagi muud. Kui rakendus n\u00f5uab s\u00fcnkrooni kirjutamist, \u00fctleb see failis\u00fcsteemile: \u201ePeate selle kohe salvestama energiakindlasse m\u00e4llu. just praegu<\/i>, ja kuni siis ei saa ma midagi muud teha.\u201d Seet\u00f5ttu peavad s\u00fcnkroonsed kirjed koheselt ketta peale salvestuma \u2013 ja kui see suurendab fragmenteerimist v\u00f5i v\u00e4hendab l\u00e4bilaskev\u00f5imet, siis nii peabki olema.<\/p>\n

ZFS k\u00e4sitleb s\u00fcnkroone kirjeid teisiti kui tavalised failis\u00fcsteemid \u2013 selle asemel, et need kohe tavalisse salvestusse laadida, salvestab ZFS need spetsiaalsesse salvestuspiirkonda, mida nimetatakse ZFS-i kavatsuste ajaks (ZFS Intent Log, v\u00f5i ZIL). Trikk on selles, et need kirjed ka<\/i> j\u00e4\u00e4vad m\u00e4llu, olles kogutud koos tavaliste as\u00fcnkroonsete kirjutamisotsega, et hiljem salvestada need salvestusse t\u00e4iesti normaalses TXG (tehingugrupid, Transaction Groups) vormis.<\/p>\n

Tavaliselt salvestatakse ZIL ja seda ei loeta enam kunagi. Kui p\u00e4rast m\u00f5nda hetke ZIL-st salvestatud kirjed kinnitatakse peamisse salvestusse tavap\u00e4rases TXG-s m\u00e4lust, eraldatakse need ZIL-ist. Ainsad korrad, kui ZIL-ist midagi loetakse, on siis, kui tehakse basseini import.<\/p>\n

Kui ZFS-i s\u00fcsteem v\u00f5i toitekatkestus p\u00f5hjustab vea, kui ZIL-is on andmeid, loetakse need andmed j\u00e4rgmise basseini impordi ajal (n\u00e4iteks p\u00e4rast avariilise s\u00fcsteemi taask\u00e4ivitamist). K\u00f5ik, mis on ZIL-is, loetakse, kogutakse TXG gruppidesse, salvestatakse p\u00f5hiahendisse ja seej\u00e4rel eemaldatakse ZIL-ist impordi k\u00e4igus.<\/p>\n

\u00dcks vdev-i abikliendi kategooriaid on LOG v\u00f5i SLOG, teisej\u00e4rguline LOG seade. Selle ainus \u00fclesanne on anda basseini eraldi ja, eelistatavalt, palju kiiream vdev, mille kirjutamisvastupidavus on v\u00e4ga k\u00f5rge, ZIL-i salvestamiseks, mitte peahoidlas vdev-s. Isegi kui ZIL k\u00e4itub s\u00f5ltumatult salvestuskohtadest, siis kui LOG-vdev-il on kirjutamise osas v\u00e4ga k\u00f5rge j\u00f5udlus, toimuvad s\u00fcnkroonsed kirjutised kiiremini.<\/p>\n

LOG vdev-i lisamine basseini ei saa<\/b> parandada as\u00fcnkroonsete kirjutiste sooritust \u2014 isegi kui sunnite k\u00f5ik kirjutised ZIL-i tegema zfs set sync=always<\/code>, nad siiski on nad endiselt seotud peamise salvestusega TXG samamoodi ja samas tempos nagu ilma p\u00e4evikuta. Ainus otsene j\u00f5udluse parendamine on s\u00fcnkroonselte kirjutuste viivitus (kuna p\u00e4eva suurem kiirus kiirendab toimingute t\u00e4itmist sync<\/code>).<\/p>\n

Kuid keskkonnas, kus on juba vaja suurt hulka s\u00fcnkroonseid kirjeid, v\u00f5ib vdev LOG kaudselt kiirendada as\u00fcnkroonset kirjutamist ja vahem\u00e4luta lugemist. ZIL-i kirjeid eraldi vdev LOG-i laadides on v\u00e4hem konkurentsi IOPS-i p\u00e4rast p\u00f5hilises salvestuses, mis t\u00f5stab teatud m\u00e4\u00e4ral k\u00f5igi lugemis- ja kirjutamistoimingute j\u00f5udlust.<\/p>\n

Snaipid<\/h3>\n

\nKirjutamisel kopeerimise mehhanism on samuti vajalik alus ZFS-i aatomiliste hetkepiltide ja inkrementaalse as\u00fcnkroonse replikatsiooni jaoks. Aktiivses failis\u00fcsteemis on olemas viidete puu, mis t\u00e4histab k\u00f5iki kirjeid koos praeguste andmetega \u2014 kui teete snaipi, teete lihtsalt koopia sellest viidete puust.<\/p>\n

Aktive failis\u00fcsteemi kirje uuendamisel kirjutab ZFS esmalt uue ploki versiooni kasutamata ruumi. Seej\u00e4rel eraldab see vana ploki versiooni praegusest failis\u00fcsteemist. Kuid kui m\u00f5ni snapshot viitab vanale plokile, j\u00e4\u00e4b see siiski muutumatuks. Vana plokk ei muutu tegelikult vabaks ruumiks, kuni k\u00f5ik snapshotid, mis viitavad sellele plokile, on kustutatud!<\/p>\n

Replikatsioon<\/h3>\n

\n\"ZFS
\nMinu Steam'i raamatukogu 2015. aastal oli 158 GiB ja sisaldas 126 927 faili. See on \u00fcsna l\u00e4hedal optimaalsele olukorrale rsync'i jaoks \u2014 ZFS replikatsioon v\u00f5rgu kaudu oli \"ainult\" 750% kiiremini.<\/i><\/p>\n

\"ZFS
\nSamal v\u00f5rgul on Windows 7 virtuaalse masina pildi \u00fche 40-gigabyte faili replikatsioon t\u00e4iesti erinev lugu. ZFS replikatsioon toimub 289 korda kiiremini kui rsync - v\u00f5i 'vaid' 161 korda kiiremini, kui olete piisavalt vilunud, et k\u00e4ivitada rsync —inplace.<\/i><\/p>\n

\"ZFS
\nKui virtuaalse masina pilt skaleerub, siis probleemid rsynciga skaleeruvad koos sellega. 1,9 TiB pole t\u00e4nap\u00e4eva virtuaalse masina pildi jaoks nii suur - kuid see on piisavalt suur, et ZFS replikatsioon osutub 1148 korda kiiremini kui rsync, isegi rsync —inplace argumendiga.<\/i><\/p>\n

Kui olete aru saanud, kuidas snapshots t\u00f6\u00f6tavad, on replikatsiooni olemuse m\u00f5istmine lihtne. Kuna snapshot on lihtsalt salvestuste teedepuu, tuleneb sellest, et kui teeme zfs send<\/code> snapshot'i, saatme selle puu ja k\u00f5ik sellega seotud salvestused. Kui edastame selle zfs send<\/code> \u00fches zfs receive<\/code> sihtobjekti, salvestab see nii tegeliku ploki sisu kui ka puu, mis osutab plokkidele, sihtkoha andmekogusse.<\/p>\n

Asjad muutuvad veelgi huvitavamaks teises zfs send<\/code>. N\u00fc\u00fcd on meil kaks s\u00fcsteemi, igal neist on poolname\/datasetname@1<\/code>, ja te teete uue snapshot'i poolname\/datasetname@2<\/code>. Seega on algses puus datasetname@1<\/code> ja datasetname@2<\/code>, samas kui sihtpuus on ainult esimene snapshot. datasetname@1<\/code>.<\/p>\n

Kuna meil on allika ja sihtkoha vahel \u00fchine snapshot datasetname@1<\/code>, saame luua inkrementaalse<\/i> zfs send<\/code> selle peale. Kui me r\u00e4\u00e4gime s\u00fcsteemist zfs send -i poolname\/datasetname@1 poolname\/datasetname@2<\/code>, see v\u00f5rreldakse kahte n\u00e4idiku puud. K\u00f5ik n\u00e4idikud, mis eksisteerivad ainult @2<\/code>, viitavad selgelt uutele plokkidele \u2014 seega vajame nende plokkide sisu.<\/p>\n

Kaugs\u00fcsteemis inkrementaalse t\u00f6\u00f6tlemine send<\/code> on samuti lihtne. Esiteks kirjutame k\u00f5ik uued kirjed, mis on voos send<\/code>, ja seej\u00e4rel lisame viidatud need plokid. Voil\u00e0, meil on @2<\/code> uus s\u00fcsteem!<\/p>\n

ZFS as\u00fcnkroonne inkrementaalne replikatsioon on suur edasiminek v\u00f5rreldes varasemate meetoditega, mis ei p\u00f5hine sn\u00e4p\u0161ottidel, n\u00e4iteks rsync. M\u00f5lemal juhul edastatakse ainult muudetud andmed \u2014 kuid rsync peab k\u00f5igepealt lugema<\/i> k\u00f5ik andmed m\u00f5lemast k\u00fcljest kettalt, et kontrollida kokkuv\u00f5tte ja v\u00f5rrelda seda. Erinevalt sellest ei loe ZFS replikatsioon midagi muud kui n\u00e4idiku puid \u2014 ja mis tahes plokke, mis ei ole esitatud \u00fcldises sn\u00e4p\u0161otis.<\/p>\n

Sisseehitatud pakkimine<\/h3>\n

\nKopeerimise mehhanism salvestamise ajal lihtsustab ka sisseehitatud t\u00f5hukeskkonna s\u00fcsteemi. Traditsioonilisest failis\u00fcsteemist on tihendamine probleemne \u2014 nii vana kui ka uus muudetud andmete versioon asub samas ruumis.<\/p>\n

Kui vaatame andmefraktsiooni faili keskel, mis alustab oma elu megabaidi nullidest alates 0x00000000 ja nii edasi \u2014 on seda v\u00e4ga lihtne tihendada \u00fche ketta sektorini. Kuid mis juhtub, kui asendame selle megabaidi nullid mittetihendatavate andmetega, nagu JPEG v\u00f5i pseudojuhuslik m\u00fcra? \u00dcht\u00e4kki n\u00f5uab see megabait andmeid mitte \u00fchte, vaid 256 sektorit, iga\u00fcks 4 KiB, samas kui sellel kohal kettal on reserveeritud ainult \u00fcks sektor.<\/p>\n

ZFS-il pole sellist probleemi, kuna muudetud kirjed kirjutatakse alati kasutamata ruumi \u2014 algne plokk v\u00f5tab ainult \u00fche 4 KiB sektori, samas kui uus kirje v\u00f5tab 256, kuid see pole probleem \u2014 hiljuti muudetud fraktsioon failist 'keskel' kirjutataks alati kasutamata ruumi s\u00f5ltumata selle suuruse muutumisest, seega on see ZFS-i jaoks t\u00e4iesti normaalne olukord.<\/p>\n

ZFS-i sisseehitatud tihendamine on vaikimisi v\u00e4lja l\u00fclitatud ning s\u00fcsteem pakub lahtiselt \u00fchendatavaid algoritme \u2014 nende seas on n\u00fc\u00fcd LZ4, gzip (1-9), LZJB ja ZLE.<\/p>\n

Kui fail on piisavalt suur ja vajab mitut plokki, siis k\u00f5ik selle failiga seotud kirjed on suurusega recordsize<\/code>\u00a0\u2014 sealhulgas viimane rekord, mille peamine osa v\u00f5ib olla kasutamata ruum<\/a><\/noindex>.<\/p>\n