{"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 alused: salvestuss\u00fcsteem ja tootlikkus","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"ZFS
\n
\nSel kevadel arutasime juba m\u00f5ningaid sissejuhatavaid teemasid, n\u00e4iteks kuidas kontrollida oma ketaste kiirus<\/a><\/noindex> ja mis on RAID<\/a><\/noindex>. Teises neist lubasime isegi j\u00e4tkata ZFS-s erinevate mitme ketta topoloogiate j\u00f5udluse uurimist. See on j\u00e4rgmise p\u00f5lvkonna failis\u00fcsteem, mida rakendatakse praegu laialdaselt, alates Apple<\/a><\/noindex> kuni Ubuntu<\/a><\/noindex>.
\n<\/a><\/noindex>
\nNoh, t\u00e4na on k\u00f5ige sobivam p\u00e4ev ZFS-iga tutvumiseks, uudishimulikkud lugejad. Lihtsalt teadke, et OpenZFS arendaja Matt Ahrens on tagasihoidlikult \u00f6elnud, et 'see on t\u00f5eliselt keeruline'.<\/p>\n

Kuid enne, kui j\u00f5uame numbrite juurde \u2013 ja need tulevad, luban \u2013 ZFS-i kaheksakettilise konfiguratsiooni k\u00f5ikide variantide osas, peame r\u00e4\u00e4kima sellest, kuidas<\/i> kuidas ZFS t\u00f5eliselt andmeid kettale salvestab.<\/p>\n

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

\n\"ZFS
\nSee diagrammi t\u00e4is bass koostab kolm abivahendit vdev’ist, \u00fche igast klassist, ja neli RAIDz2 jaoks.<\/i><\/p>\n

\"ZFS
\nTavaliselt pole p\u00f5hjust luua puu, mis koosneb sobimatutest t\u00fc\u00fcpidest ja suurustest vdev'idest \u2013 aga kui soovite, ei takista teid miski selle tegemiselt<\/i><\/p>\n

Kuna ZFS failis\u00fcsteemi t\u00f5eliselt m\u00f5istmiseks peate hoolikalt vaatama selle tegelikku struktuuri. Esiteks, ZFS \u00fchildab traditsioonilised mahtude ja failis\u00fcsteemi halduse tasemed. Teiseks kasutab ta kirjutamise ajal koopiate tegemise tehingumehhanismi. Need omadused t\u00e4hendab, et s\u00fcsteem on struktuuriliselt v\u00e4ga erinev tavalisest failis\u00fcsteemist ja RAID-massiividest. Esimene p\u00f5hiehituse elementide komplekt, mida m\u00f5ista: see on salvestuspuu (zpool), virtuaalne seade (vdev) ja tegelik seade (seade).<\/p>\n

zpool<\/h3>\n

\nSalvestuspuu zpool on ZFS-i k\u00f5ige \u00fclemine struktuur. Iga puu sisaldab \u00fchte v\u00f5i mitut virtuaalset seadet. See omakorda sisaldab \u00fchte v\u00f5i mitut tegelikku seadet (seade). Virtuaalsed puud on iseseisvad \u00fcksused. \u00dcks f\u00fc\u00fcsiline arvuti v\u00f5ib sisaldada kahte v\u00f5i enamat eraldi puud, kuid iga\u00fcks neist on teistest t\u00e4ielikult s\u00f5ltumatu. Puid ei saa \u00fchiselt kasutada virtuaalseid seadmeid.<\/p>\n

ZFS-i \u00fcleliigusus asub virtuaalsete seadmete tasemel, mitte puude tasemel. Puu tasemel ei ole absoluutselt mingit \u00fcleliigsust \u2013 kui m\u00f5ni vdev v\u00f5i eelnevalt m\u00e4\u00e4ratud vdev kaob, kaob koos sellega ka kogu puu.<\/p>\n

Kaasaegsed salvestuspaigid v\u00f5ivad taluda virtuaalse seadme vahem\u00e4lu v\u00f5i logi kaotust, kuigi nad v\u00f5ivad kaduda v\u00e4ikese hulga r\u00e4paste andmete, kui nad kaotavad vdev logi voolukatkestuse v\u00f5i s\u00fcsteemirikkega.<\/p>\n

On levinud v\u00e4\u00e4rarusaam, et ZFS andmepaarid (stripes) kirjutatakse kogu paiki. See ei ole t\u00f5si. Zpool ei ole lihtsalt l\u00f5bus RAID0, see on pigem l\u00f5bus. JBOD<\/a><\/noindex> keerulise muutliku jaotamismehhanismiga.<\/p>\n

Suur osa kirjutamist jagatakse kergesti saadavail virtuaalsetel seadmetel, l\u00e4htudes olemasolevast vaba ruumist, nii et teoreetiliselt t\u00e4idetakse need k\u00f5ik samaaegselt. Uuemates ZFS versioonides arvestatakse jooksva kasutuse (utiliseerimise) vdev'i - kui \u00fcks virtuaalne seade on palju rohkem koormatud kui teine (n\u00e4iteks lugemise koormuse t\u00f5ttu), siis selle kirjutamise ajutiselt m\u00f6\u00f6da minnakse, hoolimata k\u00f5rgeimast vabast ruumist.<\/p>\n

Kaasaegse ZFS kirjutamise jaotamismehhanismis sisseehitatud(utiliseerimise) seire v\u00f5ib v\u00e4hendada viivitust ja suurendada l\u00e4bilaskev\u00f5imet ebatavaliselt k\u00f5rgete koormuste ajal - kuid see ei ole karantsi<\/i> aeglaste HDD-de ja kiirete SSD-de tahtmatu segamise vastu \u00fches paigis. Selline eba\u00fchtlane paigaldus t\u00f6\u00f6tab siiski k\u00f5ige aeglasema seadme kiirusel, see t\u00e4hendab, et see toimib nagu oleks see t\u00e4ielikult koostatud sellistest seadmetest.<\/p>\n

vdev<\/h3>\n

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

RAIDz1, RAIDz2 ja RAIDz3 on erilised variandid sellest, mida vanad nimetavad kahekordseks (diagonaalseks) pariteediks. 1, 2 ja 3 viitavad sellele, kui palju pariteetplokke on eraldatud iga andmete ribale. Erinevalt eraldiseisvatest kettadest, mis tagavad pariteedi, jaotavad RAIDz virtuaalsed seadmed pariteedi kettale \u00fchtlaselt. RAIDz massiiv suudab kaotada nii palju kettasid, kui tal on pariteetplokke; kui ta kaotab veel \u00fche, lakkab ta olemast ja viib endaga kaasa salvestusalu.<\/p>\n

Peegeldavatel virtuaalsetel seadmetel (mirror vdev) hoitakse iga plokk iga seadme peal vdev-is. Kuigi k\u00f5ige levinumad on kaksikpeeglid (two-wide), v\u00f5ib peeglis olla mis tahes arvu seadmeid - suurtes seadistustes, et suurendada lugemise j\u00f5udlust ja talitlush\u00e4irete vastupidavust, kasutatakse sageli kolmikpeegleid. Vdev peegeldus suudab taluda mis tahes rikkeid, seni kuni v\u00e4hemalt \u00fcks seade vdev-is t\u00f6\u00f6tab.<\/p>\n

\u00dcksikud vdev-id on oma olemuselt ohtlikud. Selline virtuaalne seade ei talunda \u00fchtegi riket - ja kui seda kasutatakse salvestusala v\u00f5i spetsiaalse vdev-i jaoks, toob tema rike kaasa kogu ala h\u00e4vimise. Olge selle osas v\u00e4ga, v\u00e4ga ettevaatlik.<\/p>\n

Virtuaalsed seadmed CACHE, LOG ja SPECIAL v\u00f5ivad olla loodud mis tahes \u00fclaltoodud topoloogiate p\u00f5hjal - kuid pidage meeles, et virtuaalse seadme SPECIAL kaotamine t\u00e4hendab kogu ala kaotamist, seet\u00f5ttu on tungivalt soovitatav \u00fcleliigne topoloogia.<\/p>\n

seade<\/h3>\n

\nSee on t\u00f5en\u00e4oliselt k\u00f5ige lihtsam m\u00f5istetav termin ZFS-is - see on s\u00f5na-s\u00f5nalt juhusliku juurdep\u00e4\u00e4su blokiseade. Pidage meeles, et virtuaalsed seadmed koosnevad eraldi seadmetest ja ala on loodud virtuaalsetest seadmetest.<\/p>\n

Kettad - magnetilised v\u00f5i tahked - on k\u00f5ige levinumad blokiseadmestena, mida kasutatakse vdev-i ehitamiseks. Siiski sobib iga seade, millel on kirjeldus \/dev-is - seega v\u00f5ib eraldi seadmetena kasutada ka terveid riistvara RAID-massiive.<\/p>\n

Lihtne raw-fail on \u00fcks k\u00f5ige olulisemaid alternatiivseid blokiseadmeid, millest vdev-i saab ehitada. Testimisalad haruldased failid<\/a><\/noindex>\u00a0on v\u00e4ga mugav viis kontrolida ala k\u00e4ske ja n\u00e4ha, kui palju ruumi on saadaval antud topoloogia ala v\u00f5i virtuaalse seadme jaoks.<\/p>\n

\"ZFS
\nSaate luua testkasti h\u00f5redatest failidest vaid m\u00f5ne sekundiga \u2014 kuid \u00e4rge unustage seej\u00e4rel kustutada kogu kasti ja selle komponente.<\/i> <\/p>\n

Oletame, et soovite seadistada serveri kaheksa ketta peale ja plaanite kasutada 10 TB (~9300 GiB) kettaid \u2014 kuid te ei ole kindel, milline topoloogia vastab teie vajadustele k\u00f5ige paremini. \u00dclaltoodud n\u00e4ites loome testkasti h\u00f5redatest failidest m\u00f5ne sekundiga \u2014 ja n\u00fc\u00fcd teame, et kaheksa 10 TB kettaga RAIDz2 vdev tagab 50 TiB kasulikku mahtu.<\/p>\n

Teine eriline seadme klasse on SPARE (varu). Soojavarustusseadmed, erinevalt tavap\u00e4rastest seadmetest, kuuluvad kogu kasti, mitte \u00fchele virtuaalsele seadmele. Kui m\u00f5ni vdev kastis eba\u00f5nnestub ja varuseade on kasti \u00fchendatud ja saadaval, liitub see automaatselt kahjustatud vdev'iga.<\/p>\n

P\u00e4rast kahjustatud vdev'iga \u00fchendamist hakkab varuseade saama koopiaid v\u00f5i andmete rekonstrueerimist, mis peaksid puuduvatel seadmetel olema. Traditsioonilises RAID-is nimetatakse seda taastamiseks (rebuilding) ja ZFS-is on see \"\u00fclemineku taastamine\" (resilvering).<\/p>\n

Oluline on m\u00e4rkida, et varuseadmed ei asenda p\u00fcsivalt rikutud seadmeid. Need on vaid ajutised asendajad, et v\u00e4hendada aega, mille jooksul vdev degradeerub. P\u00e4rast seda, kui administraator on asendanud riknenud seadme vdev'is, toimub taastamine uuele seadmele ja varu seade eraldatakse vdev'ist ning naaseb varuseadmest t\u00f6\u00f6le kogu kasti jaoks.<\/p>\n

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

\nJ\u00e4rgmised alusloomaelemendid, mida meie ZFS-i teekonnal m\u00f5ista, ei seondu nii palju riistvaraga, kui selle kohapealse andmete korralduse ja salvestamisega. \u00dcksikute tasemete loomine, nagu metaslab, j\u00e4i meil selgelt m\u00f5istmise huvides vahele.<\/p>\n

Andmekogud (dataset)<\/h3>\n

\n\"ZFS
\nKui me esmakordselt loome andmekogu, kuvab see kogu saadaoleva kasti ruumi. Seej\u00e4rel seadistame kvoodi \u2014 ja muudame mount-punkti. Imeline!<\/i> <\/p>\n

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

ZFS andmegrupp on enam-v\u00e4hem sarnane tavalise monteeritud failis\u00fcsteemiga. Nagu tavaline failis\u00fcsteem, n\u00e4eb see esmapilgul v\u00e4lja nagu \"\u00fcks tavaline kaust\". Kuid nagu tavalistel monteeritud failis\u00fcsteemidel, on igal ZFS andmegrupil oma p\u00f5hivarade kogum.<\/p>\n

Esiteks v\u00f5ib andmegrupile m\u00e4\u00e4rata kvoodi. Kui seadistate zfs set quota=100G poolname\/datasetname<\/code>, siis ei saa te kirjutada monteeritud kausta \/poolname\/datasetname<\/code> rohkem kui 100 GiB.<\/p>\n

Kas m\u00e4rkate, et iga rea alguses on olemas ja puudub kaldkriips? Igal andmegrupil on oma koht nii ZFS hierarhias kui ka s\u00fcsteemi monteerimise hierarhias. ZFS hierarhias ei ole esimest kaldkriipsu \u2014 alustate ankrust ning seej\u00e4rel tee\u00fclesande andmegrupi juurde. N\u00e4iteks, pool\/vanem\/laps<\/code> andmegrupi kohta nimega laps<\/code> vanema andmegrupi all vanem<\/code> loovalt nimetatud ankrus pool<\/code>.<\/p>\n

Vaikimisi on andmegrupi monteerimispunkt ZFS hierarhias tema nimega ekvivalentne, alustades kaldkriipsust \u2014 ankur nimega pool<\/code> monteeritakse kui \/pool<\/code>, andmegrupp vanem<\/code> monteeritakse \/pool\/parent<\/code>, ja alamandmegrupp laps<\/code> monteeritakse \/pool\/parent\/child<\/code>. Siiski on v\u00f5imalik muuta andmegrupi s\u00fcsteemi monteerimispunkti.<\/p>\n

Kui me m\u00e4\u00e4rame zfs set mountpoint=\/lol pool\/vanem\/laps<\/code>, siis andmegrupp pool\/vanem\/laps<\/code> monteeritakse s\u00fcsteemi kui \/lol<\/code>.<\/p>\n

Lisaks andmegruppidele peame mainima ka mahtusid (zvols). Mahu struktuur on sarnane andmegrupile, v\u00e4lja arvatud see, et seal ei ole tegelikult failis\u00fcsteemi \u2014 see on lihtsalt plokiseade. N\u00e4iteks saate luua zvol<\/code> nimega mypool\/myzvol<\/code>, seej\u00e4rel vormindada selle ext4 failis\u00fcsteemiga ja siis monteerida see failis\u00fcsteem \u2014 n\u00fc\u00fcd on teil ext4 failis\u00fcsteem, kuid k\u00f5igi ZFS turvafunktsioonide toetusega! See v\u00f5ib tunduda m\u00f5ttetu \u00fchel arvutil, kuid omab palju rohkem t\u00e4hendust iSCSI seadme eksportimise taustana.<\/p>\n

Jaotusseadmed<\/h3>\n

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

\"ZFS
\nMe t\u00f5esti, t\u00f5eliselt<\/b> ei naljasta tohutu j\u00f5udluse kaotuse \u00fcle, kui seada ashift liiga madalaks.<\/i><\/p>\n

ZFS-i baselines salvestatakse k\u00f5ik andmed, sealhulgas metaandmed plokkidesse. Iga andmestiku maksimaalne ploki suurus m\u00e4\u00e4ratakse omaduses recordsize<\/code> (salvestusv\u00e4li). Salvestusv\u00e4lja saab muuta, kuid see ei muuda ega asenda \u00fchtegi plokki, mis on juba andmestikku kirjutatud - see kehtib ainult uute plokkide puhul nende kirjutamise ajal.<\/p>\n

Kui pole m\u00e4\u00e4ratud muud, on praegune salvestusv\u00e4li vaikesuurus 128 KiB. See on omamoodi keeruline kompromiss, kus j\u00f5udlus ei ole ideaalne, kuid pole ka kohutav enamikes olukordades. Salvestusv\u00e4li<\/code> saab seadistada v\u00e4\u00e4rtuseks vahemikus 4K kuni 1M (lisaseadetega recordsize<\/code> saab seadistada ka suuremaks, kuid see on harva hea m\u00f5te).<\/p>\n

Iga plokk viitab ainult \u00fche faili andmetele - sa ei saa kahe erineva faili andmeid \u00fchte plokki suruda. Iga fail koosneb \u00fchest v\u00f5i mitmest plokist, s\u00f5ltuvalt suurusest. Kui faili suurus on v\u00e4iksem kui salvestusv\u00e4li, salvestatakse see v\u00e4iksemas plokis - n\u00e4iteks 2 KiB faili plokk h\u00f5ivab ainult \u00fche 4 KiB sektori kettal.<\/p>\n

Zvoli mahutitel ei ole omadust recordsize<\/code>\u00a0- selle asemel on neil ekvivalentne omadus volblocksize<\/code>.<\/p>\n

Sektorid<\/h3>\n

\nViimane ja k\u00f5ige p\u00f5hjalikum ehitusplokk on sektor. See on v\u00e4ikseim f\u00fc\u00fcsiline \u00fcksus, mida saab aluseks olevast seadmega kirjutada v\u00f5i lugeda. Aastak\u00fcmneid on enamus ketastest kasutanud 512-baidiseid sektoreid. Viimasel ajal on enamus ketastest seadistatud 4 KiB sektoriteks, ja m\u00f5nedes - eriti SSD-de puhul - 8 KiB sektoriteks v\u00f5i isegi rohkem.<\/p>\n

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

ZFS k\u00fcsib operatsioonis\u00fcsteemilt iga plokiseadmest \u00fcksikasjalikku teavet, kui see lisatakse uude vdev'i, ja teoreetiliselt seadistab ashifti automaatselt selle teabe p\u00f5hjal. Kahjuks valetavad paljud kettad oma sektori suuruse kohta, et s\u00e4ilitada \u00fchilduvus Windows XP-ga (millel oli probleeme teiste sektori suurustega kettaste m\u00f5istmisega).<\/p>\n

See t\u00e4hendab, et ZFS-i administraator peab teadma oma seadmete tegelikku sektori suurust ja seadistama selle k\u00e4sitsi. ashift<\/code>. Kui ashift on seadistatud liiga v\u00e4ikseks, suureneb lugemis-\/kirjutamisoperatsioonide arv erakordsetes ulatustes. Nii tuleb 512-baidiseid \"sektoore\" kirjutada reaalsetesse 4 KiB-sektoritesse, mis t\u00e4hendab, et esmalt tuleb kirjutada esimene \"sektor\", siis lugeda 4 KiB sektor, muuta see teise 512-baidise \"sektoriga\", kirjutada see tagasi uude 4 KiB-sektorisse ja nii edasi iga kirje puhul.<\/p>\n

Tegelikus maailmas on selline trahv tuntav Samsung EVO tahkete ketaste puhul, mille jaoks peaks olema kehtiv ashift=13<\/code>, kuid need SSD-d valetavad oma sektori suuruse kohta, seega on see seadistatud ashift=9<\/code>. Kui kogenud s\u00fcsteemiadministraator seda parameetrit ei muuda, siis t\u00f6\u00f6tab see SSD aeglase<\/i> tavalise magnet HDD-ga.<\/p>\n

V\u00f5rdluseks, liiga suure suuruse korral ashift<\/code> pole praktiliselt mingit trahvi. Tegelikku j\u00f5udluse v\u00e4henemist ei ole ning kasutamata ruumi suurenemine on \u00e4\u00e4rmiselt v\u00e4ike (v\u00f5i null, kui tihendamine on sisse l\u00fclitatud). Seet\u00f5ttu soovitame tungivalt isegi neile kettastele, mis tegelikult kasutavad 512-baidiseid sektoore, seadistada ashift=12<\/code> v\u00f5i isegi ashift=13<\/code>, et kindlalt tulevikku vaadata.<\/p>\n

Omadus ashift<\/code> seadetakse iga virtuaalse seadme vdev jaoks, mitte pooli<\/i>, nagu paljud ekslikult arvavad - ja p\u00e4rast seadistamist ei muutu. Kui sa kogemata seaded \u00fcmber ajasid ashift<\/code> uue vdev'i lisamisel paiku, siis olete selle mahu madala j\u00f5udlusega seadmega p\u00f6\u00f6rdumatult saastanud ja tavaliselt pole muud lahendust, kui purustada maht ja alustada k\u00f5ik otsast. Isegi vdev'i eemaldamine ei p\u00e4\u00e4sta vale seadistuse eest. ashift<\/code>!<\/p>\n

Kopeerimise mehhanism kirjutamisel<\/h3>\n

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

\"ZFS
\nFailis\u00fcsteem, kus toimub kirjutamise k\u00e4igus kopeerimine, salvestab uue ploki versiooni ja seej\u00e4rel vabastab vana versiooni.<\/i><\/p>\n

\"ZFS
\n\u00dcldiselt, kui ignoreerida plokkide reaalsest f\u00fc\u00fcsilisest asukohast, lihtsustub meie \"andmete komeet\" \"andmeussiks\", mis liigub vasakult paremale saadaval oleva ruumi kaartidel.<\/i><\/p>\n

\"ZFS
\nN\u00fc\u00fcd saame h\u00e4sti aru, kuidas kirjutamise k\u00e4igus kopeerimise sn\u00e4ppshotid t\u00f6\u00f6tavad \u2014 iga plokk v\u00f5ib kuuluda mitmele sn\u00e4ppshotile ja j\u00e4\u00e4b alles seni, kuni k\u00f5ik seotud sn\u00e4ppshotid on h\u00e4vitatud.<\/i><\/p>\n

Kirjutamise k\u00e4igus kopeerimise mehhanism (Copy on Write, CoW) on ZFS-i unikaalse s\u00fcsteemi aluseks. P\u00f5hikontseptsioon on lihtne \u2014 kui palute traditsiooniliselt failis\u00fcsteemil faili muuta, teeb ta n\u00f5utud. Kui aga palute kirjutamise k\u00e4igus kopeerimise failis\u00fcsteemil sama teha, \u00fctleb ta \"okei\" \u2014 kuid petab teid.<\/p>\n

Selle asemel kirjutab kirjutamise k\u00e4igus kopeerimise failis\u00fcsteem uue versiooni muudetud plokist ja seej\u00e4rel uuendab faili metaandmeid, et katkestada side vana plokiga ja siduda sellega uus plokk, mille just salvestasite.<\/p>\n

Vana ploki eraldamine ja uue sidumine toimub \u00fches operatsioonis, seega ei saa seda katkestada \u2014 kui l\u00fclitate p\u00e4rast selle toimumist v\u00e4lja, on teil uus faili versioon, kuid kui l\u00fclitate varem v\u00e4lja, on teil vana versioon. Igatahes ei teki failis\u00fcsteemi konfliktide.<\/p>\n

Kirjutamise k\u00e4igus kopeerimine ZFS-is toimub mitte ainult failis\u00fcsteemi tasandil, vaid ka ketaste halduse tasemel. See t\u00e4hendab, et ZFS ei ole vastuv\u00f5tlik kirjutamise t\u00fchikule (RAID augule<\/a><\/noindex>) \u2014 n\u00e4htusele, kus riba on salvestatud ainult osaliselt enne s\u00fcsteemi t\u00f5rget, mis kahjustab massiivi p\u00e4rast taask\u00e4ivitamist. Siin kirjutatakse riba aatomaarseks, vdev on alati j\u00e4rjepidev, ja Bob on su onu.<\/a><\/noindex>.<\/p>\n

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

\n\"ZFS
\nZFS s\u00fcsteem k\u00e4sitleb s\u00fcnkroonseid kirjeid eriliselt \u2014 see salvestab need ajutiselt, kuid koheselt ZIL-i, enne kui salvestab need hiljem p\u00fcsivalt koos as\u00fcnkroonsete kirjetega.<\/i><\/p>\n

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

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

\"ZFS
\nP\u00e4rast viga taastatakse k\u00f5ik m\u00e4\u00e4rdunud andmed ZIL-is - antud juhul asub ZIL SLOG-is, seega taastatakse need just sealt.<\/i><\/p>\n

On olemas kaks peamist kirjutamistoimingu kategooriat - s\u00fcnkroonsed (sync) ja as\u00fcnkroonsed (async). Enamikus t\u00f6\u00f6koormustes on absoluutne enamik kirjutamistoimingutest as\u00fcnkroonsed - failis\u00fcsteem v\u00f5imaldab neid koondada ja edastada partiitena, v\u00e4hendades fragmenteerimist ja suurendades oluliselt l\u00e4bilaskev\u00f5imet.<\/p>\n

S\u00fcnkroonsed kirjutamised on t\u00e4iesti teistsugune asi. Kui rakendus k\u00fcsib s\u00fcnkroonset kirjutamist, \u00fctleb see failis\u00fcsteemile: \"Sa pead selle salvestama energiat mittekaotavasse m\u00e4llu, right now<\/i>, ja kuni selle ajani ei saa ma midagi muud teha.\" Seega peavad s\u00fcnkroonsed kirjutamised olema kohe ketta peale salvestatud - ja kui see suurendab fragmenteerimist v\u00f5i v\u00e4hendab l\u00e4bilaskev\u00f5imet, siis olgu nii.<\/p>\n

ZFS k\u00e4sitleb s\u00fcnkroonseid kirjutamisi teistmoodi kui tavalised failis\u00fcsteemid - selle asemel, et kohe neid tavalisse salvestusse laadida, salvestab ZFS need spetsiaalsesse salvestusala, mida nimetatakse ZFS-i kavatsuste logiks - ZFS Intent Log, v\u00f5i ZIL. Kiirus on selles, et need kirjutised samuti<\/i> j\u00e4\u00e4vad m\u00e4llu, kui need on koondatud koos tavaliste as\u00fcnkroonsete kirjutamisv\u00f5imetega, et hiljem neid salvestada nagu t\u00e4iesti normaalsed TXG (tehingugrupid, Transaction Groups).<\/p>\n

Normaalses t\u00f6\u00f6s on ZIL salvestatud ja ei loeta enam kunagi. Kui m\u00f5ne hetke p\u00e4rast ZIL-i kirjutised salvestatakse p\u00f5hiseadmesse tavalisetes TXG-des m\u00e4lust, eraldatakse need ZIL-ist. Ainus hetk, mil midagi ZIL-ist loetakse, on siis, kui importitakse aed.<\/p>\n

Kui ZFS-l on t\u00f5rge - operatsioonis\u00fcsteemi t\u00f5rge v\u00f5i toite l\u00f5ppemine - kui ZIL-is on andmeid, loetakse need andmed j\u00e4rgmise aeda importimise ajal (n\u00e4iteks avariiseadmest taask\u00e4ivitamisel). K\u00f5ik, mis on ZIL-is, loetakse, koondatakse TXG-deks, salvestatakse p\u00f5hiseadmesse ja seej\u00e4rel eraldatakse ZIL-ist importimise k\u00e4igus.<\/p>\n

\u00dcks vdev abiklassidest on LOG v\u00f5i SLOG, sekundaarne LOG seade. Selle ainus \u00fclesanne on tagada basseinile eraldi ja eelistatult palju kiirema, v\u00e4ga k\u00f5rge kirjutamisvastupidavusega vdev seade ZIL-i salvestamiseks, selle asemel, et salvestada ZIL p\u00f5hivdev-i peamisse salvestusse. Isegi ZIL k\u00e4itub s\u00f5ltumata salvestus kohast \u00fchtemoodi, kuid kui LOG-iga vdev-l on v\u00e4ga k\u00f5rge kirjutamiskiirus, siis s\u00fcnkroonsed kirjutamised toimuvad kiiremini.<\/p>\n

LOG-iga vdev lisamine basseini ei paranda ei suuda<\/b> as\u00fcnkroonsete kirjutamiste j\u00f5udlust - isegi kui sunnid k\u00f5iki kirjutamisi ZIL-i kaudu zfs set sync=always<\/code>, need on ikkagi seotud p\u00f5hiseadmest TXG-ga samamoodi ja samas tempos nagu ilma p\u00e4evikuta. Ainus otsene j\u00f5udluse parendamine on s\u00fcnkroonsest kirjutamisest tulenev viivitus (kuna p\u00e4eviku suurem kiirus kiirendab operatsioonide t\u00e4itmist. sync<\/code>).<\/p>\n

Kuid keskkonnas, mis juba n\u00f5uab suurt hulka s\u00fcnkroonseid kirjutamisi, v\u00f5ib vdev LOG kaudselt kiirendada as\u00fcnkroonset kirjutamist ja vahem\u00e4luta lugemist. ZIL-i kirjutiste laadimine eraldi vdev LOG-i t\u00e4hendab v\u00e4hem konkurentsi IOPS-i nimel p\u00f5hiseadmes, mis omakorda suurendab k\u00f5ikide lugemise ja kirjutamise operatsioonide j\u00f5udlust.<\/p>\n

Snapshoot'id<\/h3>\n

\nKirjutamise ajal kopeerimise mehhanism on samuti vajalik alus ZFS-i aatomiliste hetkeseisude ja inkrementaalse as\u00fcnkroonse replikatsiooni jaoks. Aktiivses failis\u00fcsteemis on punktiiride puu, mis m\u00e4rgib k\u00f5ik kirjutised praeguste andmete osas - kui teete hetkt\u00f5mmise, teete lihtsalt koopia sellest punktiiride puust.<\/p>\n

Kui aktiivses failis\u00fcsteemis kirjutatakse mingi kirjutis \u00fcle, salvestab ZFS esmalt uue versiooni plokist kasutamata ruumi. Seej\u00e4rel eemaldab vana ploki versiooni praegusest failis\u00fcsteemist. Kuid kui m\u00f5ni hetkt\u00f5mmis viitab vanale plokile, j\u00e4\u00e4b see siiski muutumatuks. Vana plokk ei taastata tegelikult vabaks ruumiks, kuni k\u00f5ik sellele plokile viitavad hetkt\u00f5mmised ei h\u00e4vitata!<\/p>\n

Replikatsioon<\/h3>\n

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

\"ZFS
\nSamas v\u00f5rgus on 40 GiB Windows 7 virtuaalmasina pildifaili replikatsioon hoopis erinev lugu. ZFS-i replikatsioon toimub 289 korda kiiremini kui rsync \u2014 v\u00f5i \"ainult\" 161 korda kiiremini, kui oskate rsync-i k\u00e4itada -inplace lippu.<\/i><\/p>\n

\"ZFS
\nKui virtuaalmasina pilt suurendab, siis rsync-i probleemid suurenevad koos sellega. 1,9 TiB suurus ei ole t\u00e4nap\u00e4evase virtuaalmasina puhul nii suur \u2014 kuid see on piisavalt suur, et ZFS-i replikatsioon oleks 1148 korda kiiremini kui rsync, isegi kui kasutada rsync-i -inplace argumenti.<\/i><\/p>\n

Kuna te m\u00f5istate, kuidas t\u00f6\u00f6deldakse snapshots'e, pole raske tabada replikatsiooni olemust. Kuna snapshot on lihtsalt viidete puu m\u00e4rgete, t\u00e4hendab see, et kui me teeme zfs send<\/code> snapshot'i, edastame me nii selle puu, kui k\u00f5ik seotud m\u00e4rkmed. Kui me edastame selle zfs send<\/code> ja zfs receive<\/code> sihtkohta, salvestab see nii tegeliku ploki sisu kui ka viidete puu, mis viitab plokkidele, sihtkohta andmete kogusse.<\/p>\n

Asjad muutuvad veelgi huvitavamaks teisel zfs send<\/code>. N\u00fc\u00fcd on meil kaks s\u00fcsteemi, millest igal on poolname\/datasetname@1<\/code>, ja v\u00f5tate uue snapshot'i poolname\/datasetname@2<\/code>. Seega on teie algses puulis datasetname@1<\/code> ja datasetname@2<\/code>, ja sihtpuulis on praegu alles esimene snapshot. datasetname@1<\/code>.<\/p>\n

Kuna allika ja sihtkoha vahel on meil \u00fchine snapshot datasetname@1<\/code>, saame teha inkrementaalse<\/i> zfs send<\/code> selle peal. Kui me r\u00e4\u00e4gime s\u00fcsteemile zfs send -i poolname\/datasetname@1 poolname\/datasetname@2<\/code>, siis v\u00f5rdleb see kahte viidete puud. K\u00f5ik viidatud, mis eksisteerivad ainult @2<\/code>, viitavad ilmselgelt uutele plokkidele - seega vajame nende plokkide sisu.<\/p>\n

Kaug-s\u00fcsteemis on inkrementaalne t\u00f6\u00f6tlemine sama lihtne. Esmalt salvestame k\u00f5ik uued m\u00e4rkmed, mis on voolus, ja seej\u00e4rel lisame viidatud need plokkidele. Voil\u00e0, meil on send<\/code> uues s\u00fcsteemis! send<\/code>As\u00fcnkroonne inkrementaalne ZFS replikatsioon on tohutu parandamine v\u00f5rreldes varasemate mitte-snapshot meetoditega, nagu rsync. M\u00f5lemal juhul edastatakse ainult muudetud andmed - kuid rsync peab esmalt @2<\/code> k\u00f5ik andmed m\u00f5lemalt poolt kettalt lugema, et kontrollida summeerimist ja v\u00f5rrelda seda. Selle vastu, ZFS replikatsioon ei loe midagi, v\u00e4lja arvatud viidete puud - ja k\u00f5ik plokid, mis ei ole esindatud \u00fchises snapshot'is.<\/p>\n

As\u00fcnkroonne inkrementaalne replikatsioon ZFS on tohutu t\u00e4iustus varasemate, snapshot'e mitte kasutavate meetodite, n\u00e4iteks rsync, suhtes. M\u00f5lemal juhul edastatakse ainult muutunud andmed - kuid rsync peab esmalt lugeda<\/i> k\u00f5ik andmed kettalt m\u00f5lemal poolel lugema, et kontrollida summat ja v\u00f5rrelda seda. Erinevalt sellest ei loe ZFS replikatsioon midagi muud kui viidete puid - ja k\u00f5ik plokid, mis ei ole esindatud \u00fchises snapshot'is.<\/p>\n

Sisseehitus<\/h3>\n

\nKirjutamise kopeerimismehanism lihtsustab samuti sisseehitatud kompressioonis\u00fcsteemi. Traditsioonilises failis\u00fcsteemis on kompressioon probleemne \u2014 nii vana kui ka uus muudetud versioon andmetest asuvad samas ruumis.<\/p>\n

Kui me vaatame andmefragmenti faili keskosas, mis alustab oma elu megabaidiga nullidest 0x00000000 ja edasi \u2014 on seda v\u00e4ga lihtne kokku suruda \u00fche sekundi suurusesse. Kuid mis juhtub, kui asendame selle megabaidi nullidega megabaidi mittekompressitavate andmetega, n\u00e4iteks JPEG v\u00f5i pseudo-juhusliku m\u00fcra? \u00dcht\u00e4kki vajab see megabaidi andmete jaoks mitte \u00fchte, vaid 256 sektori suurust 4 KiB, ja sellel kohal on kettal reserveeritud vaid \u00fcks sektor.<\/p>\n

ZFS-l pole sellist probleemi, kuna muudetud kirjad kirjutatakse alati kasutamata ruumi \u2014 algne plokk h\u00f5ivab vaid \u00fche 4 KiB sektori, kuid uus kirje v\u00f5tab 256, kuid see pole probleem \u2014 hiljuti muudetud fragment \"faili keskelt\" kirjutataks kasutamata ruumi, s\u00f5ltumata sellest, kas selle suurus muutus v\u00f5i mitte, seega on ZFS jaoks see t\u00e4iesti tavap\u00e4rane olukord.<\/p>\n

ZFS sisseehitatud kompressioon on vaikimisi keelatud ja s\u00fcsteem pakub \u00fchendatavaid algoritme \u2014 praegu on nende hulgas LZ4, gzip (1-9), LZJB ja ZLE.<\/p>\n

Kui fail on piisavalt suur ja vajab mitmeid plokke, on k\u00f5ik salvestused, mis sisaldavad seda faili, suurusega recordsize<\/code>\u00a0- sealhulgas viimane salvestus, mille peamine osa v\u00f5ib olla kasutamata ruum<\/a><\/noindex>.<\/p>\n