To pomlad smo že obravnavali nekaj uvodnih tem, npr. и . V drugem od njih smo celo obljubili, da bomo nadaljevali s preučevanjem zmogljivosti različnih večdisknih topologij v ZFS. To je datotečni sistem naslednje generacije, ki se zdaj izvaja povsod: od za .
No, danes je najboljši dan, da se seznanite z ZFS, radovedni bralci. Vedite le, da je po skromnem mnenju razvijalca OpenZFS Matta Ahrensa "res težko."
Toda preden pridemo do številk – in obljubim, da bodo – za vse možnosti za konfiguracijo ZFS z osmimi diski, se moramo pogovoriti o kot Na splošno ZFS shranjuje podatke na disk.
Zpool, vdev in naprava
Ta celoten diagram bazena vključuje tri pomožne vdev-je, enega za vsak razred in štiri za RAIDz2
Običajno ni razloga za ustvarjanje skupine neujemajočih se vrst in velikosti vdev – vendar vam nič ne preprečuje, da bi to storili, če želite.
Da bi resnično razumeli datotečni sistem ZFS, si morate natančno ogledati njegovo dejansko strukturo. Prvič, ZFS združuje tradicionalne ravni upravljanja glasnosti in datotečnega sistema. Drugič, uporablja transakcijski mehanizem kopiranja ob pisanju. Te funkcije pomenijo, da se sistem strukturno zelo razlikuje od običajnih datotečnih sistemov in polj RAID. Prvi niz osnovnih gradnikov, ki jih je treba razumeti, so pomnilniško področje (zpool), navidezna naprava (vdev) in prava naprava (naprava).
zpool
Shranjevalno področje zpool je najvišja struktura ZFS. Vsak bazen vsebuje eno ali več virtualnih naprav. Vsaka od njih pa vsebuje eno ali več pravih naprav (naprav). Virtualni bazeni so samostojni bloki. En fizični računalnik lahko vsebuje dve ali več ločenih skupin, vendar je vsako popolnoma neodvisno od drugih. Bazeni ne morejo deliti virtualnih naprav.
Redundanca ZFS je na ravni navidezne naprave, ne na ravni bazena. Na ravni bazena ni absolutno nobene redundance – če se kateri koli vdev pogona ali poseben vdev izgubi, se izgubi celoten bazen skupaj z njim.
Sodobna pomnilniška področja lahko preživijo izgubo predpomnilnika ali dnevnika navidezne naprave – čeprav lahko izgubijo majhno količino umazanih podatkov, če izgubijo dnevnik vdev med izpadom električne energije ali zrušitvijo sistema.
Obstaja pogosta napačna predstava, da so "podatkovni trakovi" ZFS zapisani po celotnem bazenu. To ni res. Zpool sploh ni smešen RAID0, je precej smešen s kompleksnim spremenljivim mehanizmom porazdelitve.
Večinoma so zapisi porazdeljeni med razpoložljive virtualne naprave glede na razpoložljiv prosti prostor, tako da bodo teoretično vsi zapolnjeni hkrati. V novejših različicah ZFS se upošteva trenutna poraba (uporaba) vdev - če je ena navidezna naprava bistveno bolj obremenjena kot druga (na primer zaradi obremenitve branja), bo začasno preskočena za pisanje, kljub temu, da ima najvišjo prosto prostorsko razmerje.
Mehanizem za zaznavanje uporabe, ki je vgrajen v sodobne metode dodeljevanja pisanja ZFS, lahko zmanjša zakasnitev in poveča prepustnost v obdobjih neobičajno visoke obremenitve - vendar ni carte blanche o nenamernem mešanju počasnih trdih diskov in hitrih diskov SSD v enem bazenu. Tako neenakomeren bazen bo še vedno deloval s hitrostjo najpočasnejše naprave, to je, kot da bi bil v celoti sestavljen iz takih naprav.
vdev
Vsako pomnilniško področje je sestavljeno iz ene ali več virtualnih naprav (virtualna naprava, vdev). Po drugi strani pa vsak vdev vsebuje eno ali več resničnih naprav. Večina virtualnih naprav se uporablja za enostavno shranjevanje podatkov, vendar obstaja več pomožnih razredov vdev, vključno s CACHE, LOG in SPECIAL. Vsaka od teh vrst vdev ima lahko eno od petih topologij: ena naprava (ena naprava), RAIDz1, RAIDz2, RAIDz3 ali zrcalo (zrcalo).
RAIDz1, RAIDz2 in RAIDz3 so posebne različice tega, čemur bi starodobniki rekli dvojni (diagonalni) paritetni RAID. 1, 2 in 3 se nanašajo na to, koliko paritetnih blokov je dodeljenih vsakemu podatkovnemu traku. Namesto ločenih diskov za pariteto virtualne naprave RAIDz to pariteto pol enakomerno porazdelijo po diskih. Polje RAIDz lahko izgubi toliko diskov, kolikor ima paritetnih blokov; če izgubi še enega, se bo zrušil in s seboj odnesel prostor za shranjevanje.
V zrcaljenih virtualnih napravah (mirror vdev) je vsak blok shranjen na vsaki napravi v vdev. Čeprav so zrcala z dvema širinama najpogostejša, je lahko v zrcalu poljubno število naprav - trojne se pogosto uporabljajo v velikih namestitvah za izboljšano zmogljivost branja in odpornost na napake. Zrcalno ogledalo vdev lahko preživi vsako napako, dokler vsaj ena naprava v vdev še naprej deluje.
Posamezni vdevi so sami po sebi nevarni. Takšna virtualna naprava ne bo preživela niti ene okvare - in če se uporablja kot shramba ali poseben vdev, bo njena okvara povzročila uničenje celotnega bazena. Tukaj bodi zelo, zelo previden.
CACHE, LOG in SPECIAL VA je mogoče ustvariti s katero koli od zgornjih topologij – vendar ne pozabite, da izguba SPECIAL VA pomeni izgubo bazena, zato je zelo priporočljiva redundantna topologija.
naprava
To je verjetno najlažji izraz za razumevanje v ZFS - to je dobesedno blokovna naprava z naključnim dostopom. Ne pozabite, da so virtualne naprave sestavljene iz posameznih naprav, medtem ko je skupina sestavljena iz virtualnih naprav.
Diski - magnetni ali polprevodniški - so najpogostejše blokovne naprave, ki se uporabljajo kot gradniki vdev. Vendar pa bo zadostovala katera koli naprava z deskriptorjem v /dev, tako da se lahko celotni strojni nizi RAID uporabljajo kot ločene naprave.
Preprosta neobdelana datoteka je ena najpomembnejših alternativnih blokovnih naprav, iz katerih je mogoče zgraditi vdev. Testni bazeni od je zelo priročen način za preverjanje ukazov bazena in ogled, koliko prostora je na voljo v bazenu ali virtualni napravi dane topologije.
Testno skupino lahko ustvarite iz redkih datotek v samo nekaj sekundah – vendar ne pozabite pozneje izbrisati celotne zbirke in njenih komponent
Recimo, da želite postaviti strežnik na osem diskov in nameravate uporabiti 10 TB diskov (~9300 GiB) – vendar niste prepričani, katera topologija najbolj ustreza vašim potrebam. V zgornjem primeru smo iz redkih datotek v nekaj sekundah zgradili testno skupino - in zdaj vemo, da RAIDz2 vdev osmih diskov po 10 TB zagotavlja 50 TiB uporabne zmogljivosti.
Drug poseben razred naprav je SPARE (rezervni). Naprave z vročo zamenjavo za razliko od navadnih naprav pripadajo celotnemu bazenu in ne eni sami virtualni napravi. Če vdev v področju odpove in je rezervna naprava povezana z bazenom in je na voljo, se bo samodejno pridružila prizadetemu vdev.
Ko je nadomestna naprava povezana s prizadetim vdev, začne prejemati kopije ali rekonstrukcije podatkov, ki bi morali biti na manjkajoči napravi. V tradicionalnem RAID-u se to imenuje "rebuilding", v ZFS pa "resilvering".
Pomembno je vedeti, da rezervne naprave ne nadomestijo trajno okvarjenih naprav. To je le začasna zamenjava za skrajšanje časa razgradnje vdev. Ko skrbnik zamenja neuspeli vdev, se redundanca obnovi v to trajno napravo, SPARE pa se odklopi od vdev in spet deluje kot rezervni za celotno področje.
Podatkovni nizi, bloki in sektorji
Naslednji niz gradnikov, ki jih je treba razumeti na našem potovanju ZFS, se nanaša manj na strojno opremo in bolj na to, kako so sami podatki organizirani in shranjeni. Tukaj preskočimo nekaj plasti - kot je metaplošča -, da se izognemo neredu podrobnosti, hkrati pa ohranimo razumevanje celotne strukture.
Nabor podatkov
Ko prvič ustvarimo nabor podatkov, prikaže ves razpoložljiv prostor bazena. Nato nastavimo kvoto - in spremenimo točko priklopa. Čarovnija!
Zvol je večinoma samo nabor podatkov, ki je brez plasti datotečnega sistema, ki ga tukaj nadomeščamo s povsem običajnim datotečnim sistemom ext4.
Nabor podatkov ZFS je približno enak standardnemu nameščenemu datotečnemu sistemu. Tako kot običajni datotečni sistem je na prvi pogled videti kot "samo še ena mapa". Toda tako kot običajni datotečni sistemi, ki jih je mogoče namestiti, ima vsak nabor podatkov ZFS svoj nabor osnovnih lastnosti.
Prvič, naboru podatkov je lahko dodeljena kvota. Če je nastavljeno zfs set quota=100G poolname/datasetname, potem ne boste mogli pisati v nameščeno mapo /poolname/datasetname več kot 100 GiB.
Ste opazili prisotnost - in odsotnost - poševnic na začetku vsake vrstice? Vsak nabor podatkov ima svoje mesto tako v hierarhiji ZFS kot v hierarhiji namestitve sistema. V hierarhiji ZFS ni vodilne poševnice - začnete z imenom bazena in nato s potjo od enega nabora podatkov do drugega. na primer pool/parent/child za nabor podatkov z imenom child pod nadrejenim naborom podatkov parent v bazenu z ustvarjalnim imenom pool.
Privzeto bo točka vpetja nabora podatkov enakovredna njegovemu imenu v hierarhiji ZFS, z začetno poševnico - bazen z imenom pool nameščen kot /pool, niz podatkov parent nameščen v /pool/parentin podrejeni nabor podatkov child nameščen v /pool/parent/child. Vendar pa je sistemsko točko vpetja nabora podatkov mogoče spremeniti.
Če določimo zfs set mountpoint=/lol pool/parent/child, nato nabor podatkov pool/parent/child nameščen na sistem kot /lol.
Poleg podatkovnih nizov je treba omeniti količine (zvole). Nosilec je približno enak naboru podatkov, le da dejansko nima datotečnega sistema – je le blokovna naprava. Ustvarite lahko na primer zvol Z imenom mypool/myzvol, nato ga formatirajte z datotečnim sistemom ext4 in nato namestite ta datotečni sistem - zdaj imate datotečni sistem ext4, vendar z vsemi varnostnimi funkcijami ZFS! To se morda zdi neumno na enem računalniku, vendar je veliko bolj smiselno kot zaledje pri izvozu naprave iSCSI.
Bloki
Datoteka je predstavljena z enim ali več bloki. Vsak blok je shranjen na eni virtualni napravi. Velikost bloka je običajno enaka parametru rekordna velikost, vendar se lahko zmanjša na 2^premikače vsebuje metapodatke ali majhno datoteko.
Mi res res brez šale glede velikega zmanjšanja zmogljivosti, če nastavite premajhen premik
V bazenu ZFS so vsi podatki, vključno z metapodatki, shranjeni v blokih. Največja velikost bloka za vsak niz podatkov je določena v lastnosti recordsize (rekordna velikost). Velikost zapisa je mogoče spremeniti, vendar to ne bo spremenilo velikosti ali lokacije blokov, ki so že bili zapisani v nabor podatkov - vpliva samo na nove bloke, ko so zapisani.
Če ni določeno drugače, je trenutna privzeta velikost zapisa 128 KiB. To je nekakšen zapleten kompromis, kjer zmogljivost ni popolna, vendar v večini primerov tudi ni grozna. Recordsize lahko nastavite na poljubno vrednost od 4K do 1M (z naprednimi nastavitvami recordsize lahko namestite še več, vendar je to redko dobra ideja).
Vsak blok se nanaša na podatke samo ene datoteke - dveh različnih datotek ne morete stlačiti v en blok. Vsaka datoteka je sestavljena iz enega ali več blokov, odvisno od velikosti. Če je velikost datoteke manjša od velikosti zapisa, bo shranjena v manjši velikosti bloka - na primer, blok z datoteko 2 KiB bo zasedel le en sektor velikosti 4 KiB na disku.
Če je datoteka dovolj velika in zahteva več blokov, bodo vsi zapisi s to datoteko velikosti recordsize - vključno z zadnjim vnosom, katerega glavni del je lahko .
zvols nimajo lastnosti recordsize — namesto tega imajo enakovredno lastnost volblocksize.
Sektorji
Zadnji, najosnovnejši gradnik je sektor. Je najmanjša fizična enota, v katero je mogoče pisati ali brati z osnovne naprave. Več desetletij je večina diskov uporabljala 512-bajtne sektorje. V zadnjem času je večina diskov konfiguriranih za 4 KiB sektorje, nekateri - predvsem SSD - pa imajo 8 KiB sektorje ali celo več.
ZFS ima funkcijo, ki vam omogoča ročno nastavitev velikosti sektorja. Ta lastnost ashift. Nekoliko zmedeno je, da je ashift potenca dvojke. na primer ashift=9 pomeni velikost sektorja 2^9 ali 512 bajtov.
ZFS povpraša operacijski sistem za podrobne informacije o vsaki blok napravi, ko je dodana v nov vdev, in teoretično samodejno pravilno namesti ashift na podlagi teh informacij. Na žalost veliko pogonov laže o svoji velikosti sektorja, da bi ohranili združljivost z operacijskim sistemom Windows XP (ki ni mogel razumeti pogonov z drugimi velikostmi sektorja).
To pomeni, da skrbniku ZFS močno priporočamo, da pozna dejansko velikost sektorja svojih naprav in jo ročno nastavi ashift. Če je ashift nastavljen prenizko, se število operacij branja/pisanja astronomsko poveča. Torej pisanje 512-bajtnih "sektorjev" v pravi 4 KiB sektor pomeni, da je treba napisati prvi "sektor", nato prebrati 4 KiB sektor, ga spremeniti z drugim 512-bajtnim "sektorjem", ga zapisati nazaj v nov Sektor 4 KiB in tako naprej za vsak vnos.
V resničnem svetu taka kazen doleti Samsung EVO SSD, za kar ashift=13, vendar ti SSD-ji lažejo glede velikosti svojega sektorja, zato je privzeta vrednost nastavljena na ashift=9. Ta SSD deluje, razen če izkušen skrbnik sistema ne spremeni te nastavitve počasneje običajni magnetni trdi disk.
Za primerjavo, za preveliko velikost ashift kazni praktično ni. Pravega zmanjšanja zmogljivosti ni, povečanje neuporabljenega prostora pa je neskončno majhno (ali nič z omogočenim stiskanjem). Zato toplo priporočamo, da namestite tudi tiste pogone, ki uporabljajo 512-bajtne sektorje ashift=12 ali celo ashift=13samozavestno zreti v prihodnost.
Nepremičnina ashift je nastavljen za vsako virtualno napravo vdev in ne za bazen, kot mnogi zmotno mislijo - in se po namestitvi ne spremeni. Če slučajno zadenete ashift ko dodate nov vdev v bazen, ste to bazen nepopravljivo onesnažili z nizko zmogljivo napravo in običajno ni druge izbire, kot da uničite bazen in začnete znova. Tudi odstranitev vdev vas ne bo rešila pred pokvarjeno konfiguracijo ashift!
Mehanizem kopiranja ob pisanju
Če mora običajni datotečni sistem prepisati podatke, spremeni vsak blok, kjer je
Datotečni sistem kopiranja ob pisanju zapiše novo različico bloka in nato odklene staro različico
Abstraktno, če zanemarimo dejansko fizično razporeditev blokov, se naš »podatkovni komet« poenostavi na »podatkovnega črva«, ki se premika od leve proti desni po zemljevidu razpoložljivega prostora.
Zdaj lahko dobimo dobro predstavo o tem, kako delujejo posnetki kopiranja ob pisanju - vsak blok lahko pripada več posnetkom in bo ostal, dokler ne bodo uničeni vsi povezani posnetki
Mehanizem Copy on Write (CoW) je temeljna osnova, zaradi katere je ZFS tako neverjeten sistem. Osnovni koncept je preprost – če od tradicionalnega datotečnega sistema zahtevate, da spremeni datoteko, bo naredil točno to, kar ste zahtevali. Če zahtevate od datotečnega sistema kopiranja ob pisanju, da stori enako, bo rekel "v redu", vendar vam bo lagal.
Namesto tega datotečni sistem s kopiranjem ob pisanju zapiše novo različico spremenjenega bloka in nato posodobi metapodatke datoteke, da prekine povezavo s starim blokom in z njim poveže nov blok, ki ste ga pravkar napisali.
Odstranjevanje starega bloka in povezovanje novega se izvede v eni operaciji, zato ga ni mogoče prekiniti - če izklopite po tem, ko se to zgodi, imate novo različico datoteke, in če izklopite predčasno, imate staro različico . V vsakem primeru ne bo prišlo do konfliktov v datotečnem sistemu.
Kopiranje ob pisanju v ZFS se ne izvaja samo na ravni datotečnega sistema, ampak tudi na ravni upravljanja diska. To pomeni, da prazen prostor ne vpliva na ZFS () - pojav, ko je trak imel čas le za delno snemanje, preden se je sistem zrušil, s poškodbo polja po ponovnem zagonu. Tukaj je trak zapisan atomsko, vdev je vedno zaporedni in .
ZIL: Dnevnik namer ZFS
Sistem ZFS obravnava sinhrono pisanje na poseben način - začasno, a takoj ga shrani v ZIL, preden ga pozneje trajno zapiše skupaj z asinhronim pisanjem.
Običajno se podatki, zapisani v ZIL, nikoli več ne preberejo. Je pa možno po zrušitvi sistema
SLOG ali sekundarna naprava LOG je samo poseben - in po možnosti zelo hiter - vdev, kjer je mogoče ZIL shraniti ločeno od glavnega pomnilnika
Po sesutju se ponovno predvajajo vsi umazani podatki v ZIL-u - v tem primeru je ZIL na SLOGu, zato se predvaja od tam
Obstajata dve glavni kategoriji zapisovalnih operacij – sinhroni (sync) in asinhroni (async). Za večino delovnih obremenitev je velika večina zapisov asinhronih - datotečni sistem omogoča njihovo združevanje in izdajo v serijah, kar zmanjša razdrobljenost in močno poveča prepustnost.
Povsem druga zadeva so sinhronizirani posnetki. Ko aplikacija zahteva sinhrono pisanje, sporoči datotečnemu sistemu: "To morate vnesti v obstojni pomnilnik prav zdajdo takrat pa ne morem storiti ničesar drugega." Zato je treba sinhrono pisanje takoj predati na disk – in če to poveča razdrobljenost ali zmanjša prepustnost, naj bo tako.
ZFS obravnava sinhrono zapisovanje drugače kot običajni datotečni sistemi – namesto da bi jih takoj dodelil običajnemu pomnilniku, jih ZFS prenese v posebno območje shranjevanja, imenovano ZFS Intent Log ali ZIL. Trik je v tem, da ti zapisi Prav tako ostanejo v pomnilniku in se združujejo skupaj z običajnimi asinhronimi zahtevami za pisanje, da se pozneje splaknejo v shrambo kot povsem običajni TXG (transakcijske skupine).
Pri normalnem delovanju se ZIL zapiše in nikoli več ne prebere. Ko se po nekaj trenutkih zapisi iz ZIL-a prenesejo v glavni pomnilnik v navadnih TXG-jih iz RAM-a, se odklopijo od ZIL-a. Edino, ko se kaj prebere iz ZIL-a, je uvoz bazena.
Če ZFS odpove – zrušitev operacijskega sistema ali izpad električne energije – medtem ko so v ZIL podatki, bodo ti podatki prebrani med naslednjim uvozom v bazen (na primer ob ponovnem zagonu sistema za nujne primere). Karkoli v ZIL-u bo prebrano, združeno v TXG-je, predano glavnemu pomnilniku in nato med postopkom uvoza ločeno od ZIL-a.
Eden od pomožnih razredov vdev se imenuje LOG ali SLOG, sekundarna naprava LOG-a. Ima en namen - zagotoviti bazenu ločen in po možnosti veliko hitrejši, zelo odporen na pisanje vdev za shranjevanje ZIL-a, namesto shranjevanja ZIL-a v glavni shrambi vdev. Sam ZIL se obnaša enako ne glede na to, kje je shranjen, toda če ima LOG vdev zelo visoko zmogljivost zapisovanja, bo sinhrono pisanje hitrejše.
Dodajanje vdev z LOG v področje ne deluje ne morem izboljšajte zmogljivost asinhronega pisanja - tudi če prisilite vsa pisanja v ZIL z zfs set sync=always, bodo še vedno povezani z glavnim pomnilnikom v TXG na enak način in z enako hitrostjo kot brez dnevnika. Edina neposredna izboljšava zmogljivosti je zakasnitev sinhronega zapisovanja (ker hitrejši dnevnik pospeši operacije). sync).
Vendar pa lahko v okolju, ki že tako zahteva veliko sinhronega pisanja, vdev LOG posredno pospeši asinhrono pisanje in nepredpomnjeno branje. Prenos zapisov ZIL v ločen LOG vdev pomeni manjšo borbo za IOPS v primarnem pomnilniku, kar do neke mere izboljša zmogljivost vseh branj in zapisov.
Posnetki
Mehanizem kopiranja ob pisanju je tudi nujen temelj za atomske posnetke ZFS in inkrementalno asinhrono replikacijo. Aktivni datotečni sistem ima kazalno drevo, ki označuje vse zapise s trenutnimi podatki - ko posnamete posnetek, preprosto naredite kopijo tega kazalnega drevesa.
Ko je zapis v aktivnem datotečnem sistemu prepisan, ZFS najprej zapiše novo različico bloka v neuporabljen prostor. Nato loči staro različico bloka od trenutnega datotečnega sistema. Toda če se kakšen posnetek sklicuje na stari blok, še vedno ostane nespremenjen. Stari blok dejansko ne bo obnovljen kot prosti prostor, dokler ne bodo uničeni vsi posnetki, ki se nanašajo na ta blok!
Podvajanje
Moja knjižnica Steam leta 2015 je bila 158 GiB in je vključevala 126 datotek. To je precej blizu optimalne situacije za rsync - replikacija ZFS prek omrežja je bila "samo" 927 % hitrejša.
V istem omrežju je podvajanje ene same slikovne datoteke navideznega stroja Windows 40 s 7 GB prostora povsem druga zgodba. Replikacija ZFS je 289-krat hitrejša od rsync – ali "le" 161-krat hitrejša, če ste dovolj vešči, da pokličete rsync z --inplace.
Ko je slika VM pomanjšana, rsync z njo sproži pomanjšanje. 1,9 TiB ni tako velik za sodobno sliko VM - vendar je dovolj velik, da je replikacija ZFS 1148-krat hitrejša od rsync, tudi z argumentom --inplace rsync
Ko razumete, kako posnetki delujejo, bi moralo biti enostavno razumeti bistvo replikacije. Ker je posnetek le drevo kazalcev na zapise, sledi, da če to storimo zfs send posnetek, nato pošljemo to drevo in vse zapise, povezane z njim. Ko to pošljemo zfs send в zfs receive na cilj zapiše tako dejansko vsebino bloka kot drevo kazalcev, ki se nanašajo na bloke v ciljni niz podatkov.
V drugem primeru postanejo stvari še bolj zanimive zfs send. Zdaj imamo dva sistema, od katerih vsak vsebuje poolname/datasetname@1in posnamete nov posnetek poolname/datasetname@2. Zato v izvirnem bazenu imate datasetname@1 и datasetname@2, v ciljnem bazenu pa zaenkrat le prvi posnetek datasetname@1.
Ker imamo skupen posnetek med virom in ciljem datasetname@1, zmoremo inkrementalno zfs send čez to. Ko rečemo sistemu zfs send -i poolname/datasetname@1 poolname/datasetname@2, primerja dve kazalni drevesi. Vsi kazalci, ki obstajajo samo v @2, se očitno nanašajo na nove bloke - zato potrebujemo vsebino teh blokov.
V oddaljenem sistemu obdelava prirastnega send prav tako preprosto. Najprej napišemo vse nove vnose, vključene v tok send, nato pa tem blokom dodajte kazalce. Voila, imamo @2 v novem sistemu!
Asinhrono inkrementalno podvajanje ZFS je velik napredek v primerjavi s prejšnjimi metodami, ki ne temeljijo na posnetkih, kot je rsync. V obeh primerih se prenesejo le spremenjeni podatki - vendar mora rsync najprej prebrati z diska vse podatke na obeh straneh, da preverimo vsoto in jo primerjamo. Nasprotno pa replikacija ZFS ne bere nič drugega kot drevesa kazalcev - in vse bloke, ki niso prisotni v skupnem posnetku.
Vgrajena kompresija
Mehanizem kopiranja ob pisanju tudi poenostavi sistem inline stiskanja. V tradicionalnem datotečnem sistemu je stiskanje problematično – stara in nova različica spremenjenih podatkov sta v istem prostoru.
Če upoštevamo kos podatkov na sredini datoteke, ki se začne kot megabajt ničel od 0x00000000 in tako naprej, ga je zelo enostavno stisniti v en sektor na disku. Toda kaj se zgodi, če ta megabajt ničel zamenjamo z megabajtom nestisljivih podatkov, kot je JPEG ali psevdonaključni šum? Nepričakovano bo ta megabajt podatkov zahteval ne enega, ampak 256 sektorjev velikosti 4 KiB, na tem mestu na disku pa je rezerviran samo en sektor.
ZFS nima te težave, saj so spremenjeni zapisi vedno zapisani v neuporabljen prostor - originalni blok zaseda samo en sektor 4 KiB, novi zapis pa bo zasedel 256, vendar to ni problem - nedavno spremenjeni fragment iz " sredina" datoteke bi bila zapisana v neuporabljen prostor, ne glede na to, ali se je njena velikost spremenila ali ne, zato je za ZFS to običajna situacija.
Izvorno stiskanje ZFS je privzeto onemogočeno, sistem pa ponuja vtične algoritme – trenutno LZ4, gzip (1-9), LZJB in ZLE.
- LZ4 je pretočni algoritem, ki ponuja izredno hitro stiskanje in dekompresijo ter prednosti zmogljivosti za večino primerov uporabe – tudi na dokaj počasnih procesorjih.
- GZIP je častitljiv algoritem, ki ga poznajo in ljubijo vsi uporabniki Unixa. Izvaja se lahko s stopnjami stiskanja 1–9, z naraščajočim razmerjem stiskanja in porabo procesorja, ko se približujete stopnji 9. Algoritem je zelo primeren za vse primere uporabe besedila (ali drugih primerov, ki jih je mogoče zelo stisniti), sicer pa pogosto povzroči težave s procesorjem – uporabite ga previdno, zlasti pri višjih ravneh.
- LZJB je originalni algoritem v ZFS. Je zastarel in se ga ne bi smelo več uporabljati, LZ4 ga prekaša v vseh pogledih.
- SLABO — kodiranje ničelne ravni, Zero Level Encoding. Sploh se ne dotika običajnih podatkov, ampak stisne velika zaporedja ničel. Uporabno za popolnoma nestisljive nize podatkov (kot so JPEG, MP4 ali drugi že stisnjeni formati), saj ignorira nestisljive podatke, vendar stisne neuporabljen prostor v nastalih zapisih.
Priporočamo stiskanje LZ4 za skoraj vse primere uporabe; zmanjšanje zmogljivosti, ko naletimo na nestisljive podatke, je zelo majhno in rast zmogljivost za tipične podatke je pomembna. Kopiranje slike navideznega stroja za novo namestitev operacijskega sistema Windows (sveže nameščen OS, v njem še ni podatkov) z compression=lz4 opravil 27 % hitreje kot z compression=noneV .
ARC - prilagodljiv nadomestni predpomnilnik
ZFS je edini sodobni datotečni sistem, ki ga poznamo in uporablja lasten mehanizem za predpomnjenje branja, namesto da bi se zanašal na predpomnilnik strani operacijskega sistema za shranjevanje kopij nedavno prebranih blokov v RAM.
Čeprav izvorni predpomnilnik ni brez težav – ZFS se ne more odzvati na nove zahteve za dodelitev pomnilnika tako hitro kot jedro, zato je nov izziv malloc() pri dodelitvi pomnilnika morda ne uspe, če potrebuje RAM, ki ga trenutno zaseda ARC. Vendar obstajajo dobri razlogi za uporabo lastnega predpomnilnika, vsaj za zdaj.
Vsi znani sodobni operacijski sistemi, vključno z MacOS, Windows, Linux in BSD, uporabljajo algoritem LRU (najmanj nedavno uporabljen) za implementacijo predpomnilnika strani. To je primitivni algoritem, ki po vsakem branju potisne predpomnjeni blok "navzgor po čakalni vrsti" in po potrebi bloke potisne "navzdol po čakalni vrsti", da doda nove zgrešene predpomnilnike (bloke, ki bi morali biti prebrani z diska, ne iz predpomnilnika) gor.
Algoritem običajno deluje brezhibno, toda v sistemih z velikimi delujočimi nabori podatkov LRU zlahka pripelje do razbijanja – izloči pogosto potrebne bloke, da naredi prostor za bloke, ki jih nikoli več ne bo mogoče prebrati iz predpomnilnika.
je veliko manj naiven algoritem, ki si ga lahko predstavljamo kot "uteženi" predpomnilnik. Vsakič, ko je predpomnjeni blok prebran, postane nekoliko "težji" in težje ga je izriniti – in tudi po izrivitvi bloka sledil v določenem časovnem obdobju. Blok, ki je bil izgnan, a ga je treba nato prebrati nazaj v predpomnilnik, bo prav tako postal "težji".
Končni rezultat vsega tega je predpomnilnik z veliko višjim razmerjem zadetkov, razmerje med zadetki predpomnilnika (branje, izvedeno iz predpomnilnika) in zgrešenimi predpomnilniki (branje z diska). To je izredno pomembna statistika – ne samo, da so zadetki v predpomnilniku sami postreženi za velikostni red hitreje, tudi zgrešeni predpomnilniki so lahko hitreje postreženi, saj več ko je zadetkov v predpomnilniku, manj je sočasnih zahtev za disk in nižja je zakasnitev za tiste preostale zgrešene podatke, ki morajo postrežemo z diskom.
Zaključek
Zdaj, ko smo pokrili osnovno semantiko ZFS – kako deluje kopiranje ob pisanju, kot tudi razmerja med pomnilniškimi področji, virtualnimi napravami, bloki, sektorji in datotekami – smo pripravljeni razpravljati o zmogljivosti v resničnem svetu z realna števila.
V naslednjem delu si bomo ogledali dejansko zmogljivost bazenov z zrcaljenimi vdev in RAIDz v primerjavi med seboj in tudi v primerjavi s tradicionalnimi topologijami RAID jedra Linuxa, ki smo jih raziskali. .
Sprva smo želeli pokriti le osnove - same topologije ZFS - vendar kasneje takšen pripravimo se na pogovor o naprednejši nastavitvi in prilagajanju ZFS, vključno z uporabo pomožnih vrst vdev, kot so L2ARC, SLOG in posebna dodelitev.
Vir: www.habr.com