Hierdie lente het ons reeds 'n paar inleidende onderwerpe bespreek, bv. и . In die tweede daarvan het ons selfs belowe om voort te gaan om die werkverrigting van verskeie multi-skyf-topologieë in ZFS te bestudeer. Dit is die volgende generasie lêerstelsel wat nou oral geïmplementeer word: van aan .
Wel, vandag is die beste dag om kennis te maak met ZFS, nuuskierige lesers. Weet net dat dit volgens die beskeie mening van OpenZFS-ontwikkelaar Matt Ahrens, "baie moeilik is."
Maar voordat ons by die nommers uitkom - en dit sal, ek belowe - vir alle opsies vir 'n agtskyf ZFS-konfigurasie, moet ons praat oor hoe Oor die algemeen stoor ZFS data op skyf.
Zpool, vdev en toestel
Hierdie volledige swembaddiagram bevat drie hulp-vdev's, een van elke klas, en vier vir RAIDz2
Daar is gewoonlik geen rede om 'n poel van nie-ooreenstemmende vdev-tipes en -groottes te skep nie - maar daar is niks wat jou keer om dit te doen as jy wil nie.
Om die ZFS-lêerstelsel regtig te verstaan, moet u die werklike struktuur daarvan fyn kyk. Eerstens verenig ZFS die tradisionele vlakke van volume- en lêerstelselbestuur. Tweedens gebruik dit 'n transaksionele kopieer-op-skryf-meganisme. Hierdie kenmerke beteken dat die stelsel struktureel baie verskil van konvensionele lêerstelsels en RAID-skikkings. Die eerste stel basiese boublokke om te verstaan is die stoorpoel (zpool), virtuele toestel (vdev) en regte toestel (toestel).
zpool
Die zpool stoor swembad is die boonste ZFS struktuur. Elke poel bevat een of meer virtuele toestelle. Op sy beurt bevat elkeen van hulle een of meer werklike toestelle (toestel). Virtuele swembaddens is selfstandige blokke. Een fisiese rekenaar kan twee of meer aparte poele bevat, maar elkeen is heeltemal onafhanklik van die ander. Poele kan nie virtuele toestelle deel nie.
Die oortolligheid van ZFS is op die virtuele toestelvlak, nie op die swembadvlak nie. Daar is absoluut geen oortolligheid op die swembadvlak nie - as enige aandrywing vdev of spesiale vdev verlore gaan, dan is die hele swembad daarmee saam verlore.
Moderne stoorpoele kan die verlies van 'n kas of virtuele toestellogboek oorleef - alhoewel hulle 'n klein hoeveelheid vuil data kan verloor as hulle die vdev-logboek tydens 'n kragonderbreking of stelselongeluk verloor.
Daar is 'n algemene wanopvatting dat ZFS "datastrepe" oor die hele poel geskryf word. Dit is nie waar nie. Zpool is glad nie snaaks RAID0 nie, dit is nogal snaaks met 'n komplekse veranderlike verspreidingsmeganisme.
Die inskrywings word meestal onder die beskikbare virtuele toestelle versprei volgens die beskikbare vrye spasie, so in teorie sal hulle almal op dieselfde tyd gevul word. In latere weergawes van ZFS word die huidige vdev-gebruik (benutting) in ag geneem - as een virtuele toestel aansienlik besiger is as 'n ander (byvoorbeeld, as gevolg van leeslading), sal dit tydelik oorgeslaan word vir skryf, ten spyte van die hoogste gratis ruimte verhouding.
Die gebruiksbespeuringsmeganisme wat in moderne ZFS skryftoewysingsmetodes ingebou is, kan latensie verminder en deurset verhoog gedurende periodes van buitengewoon hoë las - maar dit doen nie carte blanche op onwillekeurige vermenging van stadige HDD's en vinnige SSD's in een poel. So 'n ongelyke poel sal steeds werk teen die spoed van die stadigste toestel, dit wil sê asof dit geheel en al uit sulke toestelle saamgestel is.
vdev
Elke stoorpoel bestaan uit een of meer virtuele toestelle (virtuele toestel, vdev). Op sy beurt bevat elke vdev een of meer regte toestelle. Die meeste virtuele toestelle word gebruik vir eenvoudige databerging, maar daar is verskeie vdev-helperklasse, insluitend CACHE, LOG en SPECIAL. Elkeen van hierdie vdev-tipes kan een van vyf topologieë hê: enkeltoestel (enkeltoestel), RAIDz1, RAIDz2, RAIDz3 of spieël (spieël).
RAIDz1, RAIDz2 en RAIDz3 is spesiale variëteite van wat die outydse dubbele (diagonale) pariteit RAID sou noem. 1, 2 en 3 verwys na hoeveel pariteitsblokke vir elke datastrook toegeken word. In plaas van aparte skywe vir pariteit, versprei RAIDz virtuele toestelle hierdie pariteit semi-gelyk oor skywe. 'n RAIDz-skikking kan soveel skywe verloor as wat dit pariteitsblokke het; as dit nog een verloor, sal dit neerstort en die stoorpoel saamneem.
In spieël virtuele toestelle (spieël vdev), word elke blok op elke toestel in die vdev gestoor. Alhoewel tweewye spieëls die algemeenste is, kan enige arbitrêre aantal toestelle in 'n spieël wees - driedubbels word dikwels in groot installasies gebruik vir verbeterde leeswerkverrigting en fouttoleransie. 'n Vdev-spieël kan enige mislukking oorleef solank as wat ten minste een toestel in die vdev aanhou funksioneer.
Enkele vdevs is inherent gevaarlik. So 'n virtuele toestel sal nie 'n enkele mislukking oorleef nie - en as dit as berging of 'n spesiale vdev gebruik word, sal die mislukking daarvan lei tot die vernietiging van die hele swembad. Wees baie, baie versigtig hier.
CACHE, LOG, en SPESIALE VA's kan geskep word deur enige van die bogenoemde topologieë te gebruik - maar onthou dat die verlies van 'n SPESIALE VA die verlies van die swembad beteken, so 'n oortollige topologie word sterk aanbeveel.
toestel
Dit is waarskynlik die maklikste term om te verstaan in ZFS - dit is letterlik 'n blok ewekansige toegang toestel. Onthou dat virtuele toestelle uit individuele toestelle bestaan, terwyl 'n poel uit virtuele toestelle bestaan.
Skywe - hetsy magnetiese of vaste toestand - is die mees algemene blok toestelle wat gebruik word as die boustene van vdev. Enige toestel met 'n beskrywing in /dev sal egter doen, dus kan hele hardeware RAID-skikkings as aparte toestelle gebruik word.
'n Eenvoudige rou lêer is een van die belangrikste alternatiewe bloktoestelle waaruit 'n vdev gebou kan word. Toetspoele van is 'n baie handige manier om swembadopdragte na te gaan en te sien hoeveel spasie beskikbaar is in 'n swembad of virtuele toestel van 'n gegewe topologie.
Jy kan 'n toetspoel van yl lêers in net 'n paar sekondes skep - maar moenie vergeet om die hele swembad en sy komponente daarna uit te vee nie
Kom ons sê jy wil 'n bediener op agt skywe sit en beplan om 10 TB skywe (~9300 GiB) te gebruik - maar jy is nie seker watter topologie die beste by jou behoeftes pas nie. In die voorbeeld hierbo bou ons binne sekondes 'n toetspoel uit yl lêers - en nou weet ons dat 'n RAIDz2 vdev van agt 10 TB-skywe 50 TiB bruikbare kapasiteit bied.
Nog 'n spesiale klas toestelle is SPARE (spaar). Hot-swap toestelle, anders as gewone toestelle, behoort aan die hele swembad, en nie aan 'n enkele virtuele toestel nie. As 'n vdev in die swembad misluk en 'n spaartoestel is aan die swembad gekoppel en beskikbaar, dan sal dit outomaties by die geaffekteerde vdev aansluit.
Nadat dit aan die geaffekteerde vdev gekoppel is, begin die spaartoestel afskrifte of rekonstruksies van die data wat op die vermiste toestel moet wees, ontvang. In tradisionele RAID word dit herbou genoem, terwyl dit in ZFS resilvering genoem word.
Dit is belangrik om daarop te let dat spaartoestelle nie permanent mislukte toestelle vervang nie. Dit is slegs 'n tydelike vervanging om die hoeveelheid tyd wat vdev gedegradeer word te verminder. Nadat die administrateur die mislukte vdev vervang het, word oortolligheid na daardie permanente toestel herstel, en SPARE word van die vdev ontkoppel en teruggekeer om te werk as 'n spaarplek vir die hele swembad.
Datastelle, blokke en sektore
Die volgende stel boustene om te verstaan op ons ZFS-reis gaan minder oor die hardeware en meer oor hoe die data self georganiseer en gestoor word. Ons slaan 'n paar vlakke hier oor - soos metaslab - om nie die besonderhede deurmekaar te maak nie, terwyl ons 'n begrip van die algehele struktuur behou.
Datastel (datastel)
Wanneer ons die eerste keer 'n datastel skep, wys dit alle beskikbare swembadspasie. Dan stel ons die kwota - en verander die monteerpunt. Towerkuns!
Zvol is meestal net 'n datastel wat van sy lêerstelsellaag gestroop is, wat ons hier vervang met 'n heeltemal normale ext4-lêerstelsel.
'n ZFS-datastel is min of meer dieselfde as 'n standaard gemonteerde lêerstelsel. Soos 'n gewone lêerstelsel, lyk dit met die eerste oogopslag soos "net nog 'n gids". Maar net soos gewone monteerbare lêerstelsels, het elke ZFS-datastel sy eie stel basiese eienskappe.
Eerstens kan 'n datastel 'n toegewysde kwota hê. Indien gestel zfs set quota=100G poolname/datasetname, dan sal jy nie na die gemonteerde vouer kan skryf nie /poolname/datasetname meer as 100 GiB.
Let op die teenwoordigheid - en afwesigheid - van skuinsstreepies aan die begin van elke reël? Elke datastel het sy eie plek in beide die ZFS hiërargie en die stelsel berg hiërargie. Daar is geen leidende skuinsstreep in die ZFS-hiërargie nie - jy begin met die poelnaam en dan die pad van een datastel na die volgende. Byvoorbeeld, pool/parent/child vir 'n datastel met die naam child onder die ouerdatastel parent in 'n swembad met 'n kreatiewe naam pool.
By verstek sal die datastel se monteringspunt gelykstaande wees aan sy naam in die ZFS-hiërargie, met 'n leidende skuinsstreep - die poel genaamd pool gemonteer as /pool, datastel parent in gemonteer /pool/parent, en die kinderdatastel child in gemonteer /pool/parent/child. Die datastel se stelselmonteerpunt kan egter verander word.
As ons spesifiseer zfs set mountpoint=/lol pool/parent/child, dan die datastel pool/parent/child gemonteer op die stelsel as /lol.
Benewens datastelle, moet ons volumes (zvols) noem. 'n Volume is min of meer dieselfde as 'n datastel, behalwe dat dit nie eintlik 'n lêerstelsel het nie - dit is net 'n bloktoestel. Jy kan byvoorbeeld skep zvol Met naam mypool/myzvol, formateer dit dan met 'n ext4-lêerstelsel, en monteer dan daardie lêerstelsel - jy het nou 'n ext4-lêerstelsel, maar met al die sekuriteitskenmerke van ZFS! Dit lyk dalk dom op 'n enkele masjien, maar maak baie meer sin as 'n backend wanneer 'n iSCSI-toestel uitgevoer word.
Blokke
Die lêer word voorgestel deur een of meer blokke. Elke blok word op een virtuele toestel gestoor. Die blokgrootte is gewoonlik gelyk aan die parameter rekordgrootte, maar kan verminder word tot 2^skuifas dit metadata of 'n klein lêer bevat.
Ons regtig werklik maak nie grappies oor die groot prestasiestraf as jy te klein skuif stel nie
In 'n ZFS-poel word alle data, insluitend metadata, in blokke gestoor. Die maksimum blokgrootte vir elke datastel word in die eiendom gedefinieer recordsize (rekordgrootte). Die rekordgrootte kan verander word, maar dit sal nie die grootte of ligging van enige blokke wat reeds na die datastel geskryf is, verander nie - dit raak net nuwe blokke soos hulle geskryf word.
Tensy anders gespesifiseer, is die huidige verstekrekordgrootte 128 KiB. Dit is soort van 'n moeilike afweging waar prestasie nie perfek is nie, maar dit is ook nie vreeslik in die meeste gevalle nie. Recordsize kan op enige waarde van 4K tot 1M gestel word (met gevorderde instellings recordsize jy kan selfs meer installeer, maar dit is selde 'n goeie idee).
Enige blok verwys na die data van slegs een lêer - jy kan nie twee verskillende lêers in een blok prop nie. Elke lêer bestaan uit een of meer blokke, afhangende van die grootte. As die lêergrootte kleiner is as die rekordgrootte, sal dit in 'n kleiner blokgrootte gestoor word - byvoorbeeld, 'n blok met 'n 2 KiB-lêer sal slegs een 4 KiB-sektor op die skyf beset.
As die lêer groot genoeg is en verskeie blokke benodig, sal alle rekords met hierdie lêer groot wees recordsize - insluitend die laaste inskrywing, waarvan die hoofgedeelte mag wees .
zvols het nie 'n eiendom nie recordsize — in plaas daarvan het hulle 'n gelykwaardige eiendom volblocksize.
Sektore
Die laaste, mees basiese bousteen is die sektor. Dit is die kleinste fisiese eenheid wat na of gelees kan word vanaf die onderliggende toestel. Vir 'n paar dekades het die meeste skywe 512-grepe sektore gebruik. Onlangs is die meeste skywe vir 4 KiB-sektore gekonfigureer, en sommige - veral SSD's - het 8 KiB-sektore of selfs meer.
Die ZFS-stelsel het 'n eienskap waarmee u die sektorgrootte handmatig kan instel. Hierdie eiendom ashift. Ietwat verwarrend, ashift is 'n krag van twee. Byvoorbeeld, ashift=9 beteken 'n sektorgrootte van 2^9, of 512 grepe.
ZFS vra die bedryfstelsel vir gedetailleerde inligting oor elke bloktoestel wanneer dit by 'n nuwe vdev gevoeg word, en teoreties installeer ashift outomaties behoorlik op grond van daardie inligting. Ongelukkig lieg baie dryf oor hul sektorgrootte om versoenbaarheid met Windows XP te handhaaf (wat nie dryf met ander sektorgroottes kon verstaan nie).
Dit beteken dat 'n ZFS-administrateur sterk aangeraai word om die werklike sektorgrootte van hul toestelle te ken en handmatig in te stel ashift. As verskuiwing te laag gestel is, neem die aantal lees-/skryfbewerkings astronomies toe. Dus, om 512-grepe "sektore" in 'n regte 4 KiB-sektor te skryf, beteken om die eerste "sektor" te skryf, dan die 4 KiB-sektor te lees, dit met 'n tweede 512-grepe "sektor" te verander, dit terug te skryf na die nuwe 4 KiB sektor, ensovoorts vir elke inskrywing.
In die regte wêreld tref so 'n straf Samsung EVO SSD's, waarvoor ashift=13, maar hierdie SSD's lieg oor hul sektorgrootte, en daarom is die verstek gestel op ashift=9. As 'n ervare stelseladministrateur nie hierdie instelling verander nie, dan werk hierdie SSD stadiger konvensionele magnetiese HDD.
Ter vergelyking, vir te groot grootte ashift daar is feitlik geen straf nie. Daar is geen werklike prestasiestraf nie, en die toename in ongebruikte spasie is oneindig klein (of nul met kompressie geaktiveer). Daarom beveel ons sterk aan dat selfs die aandrywers wat wel 512-grepe-sektore gebruik, installeer ashift=12 of selfs ashift=13om die toekoms met selfvertroue tegemoet te gaan.
Eiendom ashift is ingestel vir elke vdev virtuele toestel, en nie vir die swembad nie, soos baie mense verkeerdelik dink - en verander nie na installasie nie. As jy per ongeluk slaan ashift wanneer jy 'n nuwe vdev by 'n swembad voeg, het jy daardie swembad onherstelbaar besoedel met 'n lae werkverrigting toestel en daar is gewoonlik geen ander keuse as om die swembad te vernietig en oor te begin nie. Selfs die verwydering van vdev sal jou nie red van 'n gebroke konfigurasie nie ashift!
Kopieer-op-skryf-meganisme
As 'n gewone lêerstelsel data moet oorskryf, verander dit elke blok waar dit is
'n Kopieer-op-skryf-lêerstelsel skryf 'n nuwe blokweergawe en ontsluit dan die ou weergawe
In die opsomming, as ons die werklike fisiese ligging van die blokke ignoreer, dan word ons "datakomeet" vereenvoudig tot 'n "datawurm" wat van links na regs oor die kaart van beskikbare ruimte beweeg
Nou kan ons 'n goeie idee kry van hoe kopieer-op-skryf-kiekies werk - elke blok kan aan veelvuldige kiekies behoort, en sal voortduur totdat alle verwante kiekies vernietig is
Die Copy on Write (CoW) meganisme is die fundamentele basis van wat ZFS so 'n wonderlike stelsel maak. Die basiese konsep is eenvoudig - as jy 'n tradisionele lêerstelsel vra om 'n lêer te verander, sal dit presies doen wat jy gevra het. As jy 'n kopieer-op-skryf-lêerstelsel vra om dieselfde te doen, sal dit "ok" sê, maar vir jou lieg.
In plaas daarvan, 'n kopieer-op-skryf-lêerstelsel skryf 'n nuwe weergawe van die gewysigde blok en werk dan die lêer se metadata op om die ou blok te ontkoppel en die nuwe blok wat jy sopas geskryf het, te assosieer.
Om die ou blok los te maak en die nuwe een te koppel word in een bewerking gedoen, dus kan dit nie onderbreek word nie - as jy afskakel nadat dit gebeur het, het jy 'n nuwe weergawe van die lêer, en as jy vroeg afskakel, het jy die ou weergawe . In elk geval sal daar geen konflikte in die lêerstelsel wees nie.
Kopieer-op-skryf in ZFS vind nie net op die lêerstelselvlak plaas nie, maar ook op die skyfbestuursvlak. Dit beteken dat ZFS nie deur wit spasie geraak word nie () - 'n verskynsel wanneer die strook tyd gehad het om slegs gedeeltelik op te neem voordat die stelsel neergestort het, met skikkingskade na 'n herlaai. Hier is die streep atomies geskryf, vdev is altyd opeenvolgend, en .
ZIL: ZFS-voornemelogboek
Die ZFS-stelsel hanteer sinchroniese skryfwerk op 'n spesiale manier - dit stoor dit tydelik maar onmiddellik in ZIL voordat dit later permanent saam met asynchrone skryfwerk geskryf word.
Tipies word data wat na 'n ZIL geskryf is, nooit weer gelees nie. Maar dit is moontlik na 'n stelselongeluk
SLOG, of sekondêre LOG-toestel, is net 'n spesiale - en verkieslik baie vinnige - vdev, waar die ZIL apart van die hoofberging gestoor kan word
Na 'n ongeluk word alle vuil data in ZIL oorgespeel - in hierdie geval is ZIL op SLOG, dus word dit van daar af weer gespeel
Daar is twee hoofkategorieë skryfbewerkings - sinchronies (sinchroniseer) en asinchronies (asinchronies). Vir die meeste werkladings is die oorgrote meerderheid skryfwerk asynchronies - die lêerstelsel laat dit toe om saam te voeg en in bondels uitgereik te word, wat fragmentasie verminder en deurset aansienlik verhoog.
Gesinchroniseerde opnames is 'n heeltemal ander saak. Wanneer 'n toepassing 'n sinchrone skryfwerk versoek, sê dit vir die lêerstelsel: "Jy moet dit aan nie-vlugtige geheue verbind noutot dan is daar niks anders wat ek kan doen nie.” Daarom moet sinchroniese skryfwerk onmiddellik na skyf toegewy word - en as dit fragmentasie verhoog of deurset verminder, dan is dit so.
ZFS hanteer sinchroniese skryfwerk anders as gewone lêerstelsels - in plaas daarvan om hulle dadelik tot gereelde berging te verbind, verbind ZFS hulle tot 'n spesiale bergingsarea genaamd die ZFS Intent Log, of ZIL. Die truuk is dat hierdie rekords ook bly in die geheue, word saam met normale asinchroniese skryfversoeke saamgevoeg, om later na die stoor gespoel te word as heeltemal normale TXG's (Transaksiegroepe).
In normale werking word die ZIL geskryf en nooit weer gelees nie. Wanneer, na 'n paar oomblikke, die rekords van die ZIL verbind is tot die hoofberging in gewone TXG's vanaf RAM, word hulle van die ZIL losgemaak. Die enigste keer wat iets uit die ZIL gelees word, is wanneer die swembad ingevoer word.
As ZFS misluk - 'n bedryfstelsel-ongeluk of 'n kragonderbreking - terwyl daar data in die ZIL is, sal daardie data tydens die volgende swembadinvoer gelees word (byvoorbeeld wanneer die noodstelsel herbegin word). Enigiets in die ZIL sal gelees word, in TXG's gegroepeer word, verbind word tot die hoofberging, en dan tydens die invoerproses van die ZIL losgemaak word.
Een van die vdev-helperklasse word LOG of SLOG genoem, die sekondêre toestel van LOG. Dit het een doel - om die swembad te voorsien van 'n aparte, en verkieslik baie vinniger, baie skryfbestande vdev om die ZIL te stoor, in plaas daarvan om die ZIL op die hoof vdev-winkel te stoor. Die ZIL self tree dieselfde op, ongeag waar dit gestoor word, maar as die LOG vdev baie hoë skryfwerkverrigting het, sal sinchroniese skryfwerk vinniger wees.
Om 'n vdev met LOG by die swembad te voeg, werk nie kan nie verbeter asinchroniese skryfwerkverrigting - selfs al dwing jy alle skryfwerk na ZIL met zfs set sync=always, sal hulle steeds gekoppel word aan die hoofberging in TXG op dieselfde manier en teen dieselfde tempo as sonder die log. Die enigste direkte prestasieverbetering is die latensie van sinchroniese skryfwerk (omdat vinniger log bedrywighede bespoedig). sync).
In 'n omgewing wat reeds baie sinchroniese skryfwerk vereis, kan vdev LOG egter indirek asinchroniese skryfwerk en nie-gekas leeswerk bespoedig. Die aflaai van ZIL-inskrywings na 'n aparte vdev LOG beteken minder twis vir IOPS op primêre berging, wat die werkverrigting van alle lees en skryf tot 'n mate verbeter.
Foto's
Die kopieer-op-skryf-meganisme is ook 'n noodsaaklike basis vir ZFS atoomfoto's en inkrementele asinchrone replikasie. Die aktiewe lêerstelsel het 'n wyserboom wat alle rekords met huidige data merk - wanneer jy 'n momentopname neem, maak jy eenvoudig 'n kopie van hierdie wyserboom.
Wanneer 'n rekord op die aktiewe lêerstelsel oorgeskryf word, skryf ZFS eers die nuwe blokweergawe na ongebruikte spasie. Dit maak dan die ou weergawe van die blok los van die huidige lêerstelsel. Maar as een of ander momentopname na die ou blok verwys, bly dit steeds onveranderd. Die ou blok sal nie eintlik as vrye spasie herstel word nie totdat alle foto's wat na hierdie blok verwys, vernietig is!
replikasie
My Steam-biblioteek in 2015 was 158 GiB en het 126 927 lêers ingesluit. Dit is redelik naby aan die optimale situasie vir rsync - ZFS-replikasie oor die netwerk was "net" 750% vinniger.
Op dieselfde netwerk is die replisering van 'n enkele 40 GB Windows 7 virtuele masjien beeldlêer 'n heeltemal ander storie. ZFS-replikasie is 289 keer vinniger as rsync - of "slegs" 161 keer vinniger as jy vaardig genoeg is om rsync met --inplace te bel.
Wanneer 'n VM-beeld geskaal word, gee rsync skaal daarmee uit. 1,9 TiB is nie so groot vir 'n moderne VM-beeld nie - maar dit is groot genoeg dat ZFS-replikasie 1148 keer vinniger as rsync is, selfs met rsync se --inplace-argument
Sodra jy verstaan hoe foto's werk, behoort dit maklik te wees om die essensie van replikasie te begryp. Aangesien 'n momentopname net 'n boom van wysers na rekords is, volg dit dat as ons dit doen zfs send momentopname, dan stuur ons beide hierdie boom en alle rekords wat daarmee geassosieer word. Wanneer ons dit stuur zfs send в zfs receive op die teiken skryf dit beide die werklike inhoud van die blok en die boom van wysers wat verwys na die blokke na die teikendatastel.
Dinge word selfs meer interessant op die tweede zfs send. Ons het nou twee stelsels wat elk bevat poolname/datasetname@1, en jy neem 'n nuwe momentopname poolname/datasetname@2. Daarom, in die oorspronklike swembad wat jy het datasetname@1 и datasetname@2, en in die teikenpoel tot dusver net die eerste kiekie datasetname@1.
Aangesien ons 'n algemene momentopname tussen die bron en die teiken het datasetname@1, ons kan dit doen inkrementeel zfs send oor dit. Wanneer ons sê vir die stelsel zfs send -i poolname/datasetname@1 poolname/datasetname@2, dit vergelyk twee wyserbome. Enige rigtingwysers wat net bestaan in @2, verwys natuurlik na nuwe blokke - dus het ons die inhoud van hierdie blokke nodig.
Op 'n afgeleë stelsel, verwerking van 'n inkrementele send net so eenvoudig. Eerstens skryf ons alle nuwe inskrywings wat in die stroom ingesluit is send, en voeg dan wysers by daardie blokke. Voila, ons het @2 in die nuwe stelsel!
ZFS asynchrone inkrementele replikasie is 'n groot verbetering teenoor vroeëre nie-kiekiegebaseerde metodes soos rsync. In beide gevalle word slegs veranderde data oorgedra - maar rsync moet eers lees vanaf die skyf al die data aan beide kante om die som na te gaan en dit te vergelyk. In teenstelling hiermee lees ZFS-replikasie niks anders as wyserbome nie - en enige blokke wat nie in die gedeelde momentopname teenwoordig is nie.
Ingeboude kompressie
Die kopieer-op-skryf-meganisme vereenvoudig ook die inlyn-kompressiestelsel. In 'n tradisionele lêerstelsel is kompressie problematies - beide die ou weergawe en die nuwe weergawe van die gewysigde data is in dieselfde spasie.
As ons 'n stukkie data in die middel van 'n lêer oorweeg wat die lewe begin as 'n megagreep nulle vanaf 0x00000000 ensovoorts, is dit baie maklik om dit saam te komprimeer na een sektor op skyf. Maar wat gebeur as ons daardie megagreep van nulle vervang met 'n megagreep onsamedrukbare data soos JPEG of pseudo-ewekansige geraas? Onverwags sal hierdie megagreep data nie een nie, maar 256 4 KiB-sektore benodig, en op hierdie plek op die skyf is slegs een sektor gereserveer.
ZFS het nie hierdie probleem nie, aangesien gewysigde rekords altyd na ongebruikte spasie geskryf word - die oorspronklike blok beslaan slegs een sektor van 4 KiB, en die nuwe rekord sal 256 beset, maar dit is nie 'n probleem nie - 'n onlangs gewysigde fragment van die " middel" van die lêer sal na ongebruikte spasie geskryf word, ongeag of die grootte daarvan verander het of nie, so vir ZFS is dit nogal 'n gereelde situasie.
Inheemse ZFS-kompressie is by verstek gedeaktiveer, en die stelsel bied inpropbare algoritmes—tans LZ4, gzip (1-9), LZJB en ZLE.
- LZ4 is 'n stroomalgoritme wat uiters vinnige kompressie- en dekompressie- en werkverrigtingvoordele vir die meeste gebruiksgevalle bied - selfs op redelik stadige SVE's.
- GZIP is 'n eerbiedwaardige algoritme wat alle Unix-gebruikers ken en liefhet. Dit kan met kompressievlakke 1-9 geïmplementeer word, met kompressieverhouding en SVE-gebruik wat toeneem namate dit vlak 9 nader. Die algoritme is goed geskik vir alle teks (of ander hoogs saamdrukbare) gebruiksgevalle, maar veroorsaak andersins dikwels SVE-kwessies − gebruik dit met sorg, veral op hoër vlakke.
- LZJB is die oorspronklike algoritme in ZFS. Dit is afgekeur en behoort nie meer gebruik te word nie, die LZ4 oortref dit in alle opsigte.
- SLEG - nulvlakkodering, nulvlakkodering. Dit raak glad nie aan normale data nie, maar druk groot reekse nulle saam. Nuttig vir heeltemal onsamedrukbare datastelle (soos JPEG, MP4 of ander reeds saamgeperste formate) aangesien dit onsamedrukbare data ignoreer, maar ongebruikte spasie in die resulterende rekords saampers.
Ons beveel LZ4-kompressie aan vir byna alle gebruiksgevalle; die prestasie boete wanneer onsamedrukbare data teëkom is baie klein, en groei prestasie vir tipiese data is beduidend. Kopieer 'n virtuele masjienbeeld vir 'n nuwe installasie van die Windows-bedryfstelsel (nuut geïnstalleerde bedryfstelsel, nog geen data binne nie) met compression=lz4 27% vinniger geslaag as met compression=noneIn .
ARC - aanpasbare vervangingkas
ZFS is die enigste moderne lêerstelsel waarvan ons weet wat sy eie leeskasmeganisme gebruik, eerder as om op die bedryfstelsel se bladsykas staat te maak om kopieë van onlangs geleesde blokke in RAM te stoor.
Alhoewel die inheemse kas nie sonder probleme is nie - kan ZFS nie so vinnig soos die kern reageer op nuwe geheuetoewysingsversoeke nie, dus die nuwe uitdaging malloc() op geheue toewysing kan misluk as dit die RAM benodig wat tans deur ARC beset word. Maar daar is goeie redes om jou eie kas te gebruik, ten minste vir nou.
Alle bekende moderne bedryfstelsels, insluitend MacOS, Windows, Linux en BSD, gebruik die LRU (Least Recently Used) algoritme om die bladsykas te implementeer. Dit is 'n primitiewe algoritme wat die kasblok "op die tou" stoot na elke lees, en die blokke "af in die tou" stoot soos nodig om nuwe kas mis by te voeg (blokke wat van skyf gelees moes gewees het, nie van die kas nie) op.
Die algoritme werk gewoonlik goed, maar op stelsels met groot werkende datastelle, lei LRU maklik tot slaan - die uitsetting van gereeld benodigde blokke om plek te maak vir blokke wat nooit weer uit die kas gelees sal word nie.
is 'n baie minder naïewe algoritme wat beskou kan word as 'n "geweegde" kas. Elke keer as 'n kasblok gelees word, word dit 'n bietjie "swaarder" en moeiliker om uit te sit - en selfs nadat 'n blok uitgesit is opgespoor binne 'n sekere tydperk. 'n Blokkie wat uitgesit is, maar dan in die kas teruggelees moet word, sal ook "swaarder" word.
Die eindresultaat van dit alles is 'n kas met 'n baie hoër trefverhouding, die verhouding tussen kastreffers (lees wat vanaf die kas uitgevoer word) en kasmis (lees vanaf skyf). Dit is 'n uiters belangrike statistiek - nie net word die kas-treffers self ordes van grootte vinniger bedien nie, kas-mis kan ook vinniger bedien word, aangesien hoe meer kas-treffers, hoe minder gelyktydige skyfversoeke en hoe laer is die latensie vir die oorblywende mis wat moet bedien word met skyf.
Gevolgtrekking
Nadat ons die basiese semantiek van ZFS geleer het - hoe kopieer-op-skryf werk, sowel as die verwantskappe tussen stoorpoele, virtuele toestelle, blokke, sektore en lêers - is ons gereed om werklike werkverrigting met reële getalle te bespreek.
In die volgende deel gaan ons kyk na die werklike werkverrigting van poele met weerspieëlde vdev's en RAIDz, teenoor mekaar, en ook teenoor die tradisionele Linux-kern RAID-topologieë wat ons verken het. .
Aanvanklik wou ons net die basiese beginsels dek - die ZFS-topologieë self - maar daarna so 'n kom ons maak gereed om te praat oor meer gevorderde opstelling en tuning van ZFS, insluitend die gebruik van hulp-vdev-tipes soos L2ARC, SLOG en Spesiale Allocation.
Bron: will.com