{"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\/da\/blog\/administrirovanie\/osnovy-zfs-sistema-hraneniya-i-proizvoditelnost","title":{"rendered":"Introduktion til ZFS: lager- og ydeevne","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Introduktion
\n
\nDenne for\u00e5r har vi allerede diskuteret nogle grundl\u00e6ggende emner, for eksempel, hvordan man tjekker hastigheden p\u00e5 dine diske<\/a><\/noindex> og hvad RAID er<\/a><\/noindex>. I det andet emne lovede vi endda at forts\u00e6tte med at unders\u00f8ge ydeevnen af forskellige multi-disk topologier i ZFS. Det er et n\u00e6ste generations filsystem, der i \u00f8jeblikket implementeres overalt: fra Apple<\/a><\/noindex> op til Ubuntu<\/a><\/noindex>.
\n<\/a><\/noindex>
\nN\u00e5, i dag er den perfekte dag til at l\u00e6re ZFS at kende, nysgerrige l\u00e6sere. Bare husk, at if\u00f8lge udvikleren af OpenZFS, Matt Arons, \"det er virkelig kompliceret\".<\/p>\n

Men inden vi n\u00e5r frem til tallene \u2014 og de vil komme, det lover jeg \u2014 for alle typer med otte disk konfigurationer i ZFS, skal vi tale om, hvordan<\/i> hvordan ZFS overhovedet gemmer data p\u00e5 disken.<\/p>\n

Zpool, vdev og device<\/h1>\n

\n\"Introduktion
\nDette diagram over den fulde pulje inkluderer tre hj\u00e6lpende vdev'er, \u00e9n fra hver klasse, og fire til RAIDz2.<\/i><\/p>\n

\"Introduktion
\nDer er normalt ingen grund til at oprette en pool af ikke-sammenlignelige typer og st\u00f8rrelser af vdev \u2014 men hvis du \u00f8nsker det, er der intet, der forhindrer dig i at g\u00f8re det<\/i><\/p>\n

For virkelig at forst\u00e5 ZFS-filsystemet skal man se n\u00e6rmere p\u00e5 dens faktiske struktur. For det f\u00f8rste kombinerer ZFS de traditionelle niveauer af volumenstyring og filsystemet. For det andet bruger det en transaktionel metode til skrivning. Disse egenskaber betyder, at systemet er strukturelt meget forskelligt fra almindelige filsystemer og RAID-arrays. Den f\u00f8rste s\u00e6tningss\u00e6t af grundl\u00e6ggende byggeklodser til forst\u00e5else: det er et lagringspul (zpool), et virtuelt device (vdev) og et reelt device (device).<\/p>\n

zpool<\/h3>\n

\nLagringspul zpool er den overordnede struktur i ZFS. Hver pul indeholder et eller flere virtuelle enheder. Hver af disse indeholder et eller flere reelle enheder (device). Virtuelle pul er selvst\u00e6ndige blokke. En fysisk computer kan indeholde to eller flere separate puuld, men hver er helt uafh\u00e6ngig af de andre. Puler kan ikke dele virtuelle enheder.<\/p>\n

ZFS's redundans er p\u00e5 niveau med de virtuelle enheder snarere end p\u00e5 niveau med pulerne. P\u00e5 niveauet for pulerne er der slet ingen redundans \u2014 hvis nogen vdev-enhed eller special vdev g\u00e5r tabt, g\u00e5r hele pulen tabt med den.<\/p>\n

Moderne lagringspuljer kan overleve tabet av cache eller logg fra det virtuelle enheten - selv om de kan miste en liten mengde skitne data hvis de mister vdev-loggen under str\u00f8mutkobling eller systemfeil.<\/p>\n

Det er en utbredt misforst\u00e5else at \u00abdata stripes\u00bb (stripe) i ZFS skrives over hele puljen. Det er ikke riktig. Zpool er slett ikke et morsomt RAID0, det er snarere morsomt JBOD<\/a><\/noindex> med en kompleks variabel distribusjonsmekanisme.<\/p>\n

For det meste blir registreringene fordelt mellom de tilgjengelige virtuelle enhetene i henhold til den frie plassen som er tilgjengelig, slik at de teoretisk sett vil bli fylt samtidig. I senere versjoner av ZFS tas det hensyn til den n\u00e5v\u00e6rende bruken (utnyttelsen) av vdev - hvis en virtuell enhet er betydelig mer belastet enn en annen (for eksempel p\u00e5 grunn av leseoperasjoner), vil den bli midlertidig hoppet over for skriving, til tross for at den har den h\u00f8yeste frie plassen.<\/p>\n

Utnyttelsesmekanismen innebygd i moderne ZFS-skrivfordelingsmetoder kan redusere latens og \u00f8ke gjennomstr\u00f8mningen i perioder med unormalt h\u00f8y belastning - men det er ikke blankosjekk<\/i> for ufrivillig blanding av langsomme HDD-er og raske SSD-er i \u00e9n pulje. En slik ujevn pulje vil fortsatt fungere med hastigheten til den tregeste enheten, alts\u00e5 som om den helt og holdent var laget av slike enheter.<\/p>\n

vdev<\/h3>\n

\nHver lagringspulje best\u00e5r av ett eller flere virtuelle enheter (virtual device, vdev). Hver vdev inkluderer igjen ett eller flere fysiske enheter. De fleste virtuelle enheter brukes til enkel datalagring, men det finnes flere hjelpekategorier av vdev, inkludert CACHE, LOG og SPECIAL. Hver av disse typene vdev kan ha en av fem topologier: enkelt enhet (single-device), RAIDz1, RAIDz2, RAIDz3 eller speil (mirror).<\/p>\n

RAIDz1, RAIDz2 og RAIDz3 er specielle varianter af det, som gamle folk ville kalde RAID med dobbelt (diagonal) paritet. 1, 2 og 3 henviser til, hvor mange paritetsblokke der er tildelt til hver dataramme. I stedet for separate diske til at sikre paritet fordeler RAIDz virtuelle enheder denne paritet j\u00e6vnt mellem diskene. Et RAIDz-array kan miste s\u00e5 mange diske, som det har paritetsblokke; hvis det mister en mere, vil det fejle og tage lagringspuljen med sig.<\/p>\n

I spejlede virtuelle enheder (mirror vdev) gemmes hver blok p\u00e5 hver enhed i vdev. Selvom to-dobbelte spejle (two-wide) er de mest almindelige, kan der v\u00e6re et vilk\u00e5rligt antal enheder i et spejl - i st\u00f8rre installationer bruges der ofte tre-dobbelte enheder for at forbedre l\u00e6seydelsen og fejlresistensen. Et spejl vdev kan overleve enhver fejl, s\u00e5 l\u00e6nge mindst \u00e9n enhed i vdev stadig fungerer.<\/p>\n

Enkeltst\u00e5ende vdev er i sin essens farlige. En s\u00e5dan virtuel enhed vil ikke overleve nogen fejl - og hvis den bruges som lager eller special vdev, vil dens fejl resultere i \u00f8del\u00e6ggelsen af hele puljen. V\u00e6r meget, meget forsigtig her.<\/p>\n

Virtuelle enheder CACHE, LOG og SPECIAL kan oprettes efter hvilken som helst af de ovenn\u00e6vnte topologier - men husk, at tabet af en virtuel enhed SPECIAL betyder tab af hele puljen, s\u00e5 det anbefales kraftigt at have en redundant topologi.<\/p>\n

enhed<\/h3>\n

\nDette er sandsynligvis det letteste at forst\u00e5 begreb i ZFS - det er bogstaveligt talt et bloklagringsapparat. Husk, at virtuelle enheder best\u00e5r af separate enheder, mens puljen er lavet af virtuelle enheder.<\/p>\n

Drev - magnetiske eller SSD - er de mest almindelige bloklagringsenheder, der bruges som byggesten til vdev. Dog kan ethvert apparat med en beskrivelse i \/dev bruges - s\u00e5 hele hardware RAID-arrays kan bruges som separate enheder.<\/p>\n

En simpel r\u00e5fil er en af de vigtigste alternative bloklagringsenheder, som et vdev kan bygges af. Testpuljer fra sparse filer<\/a><\/noindex>\u00a0er en meget bekvem m\u00e5de at teste pulje-kommandoer p\u00e5 og se, hvor meget plads der er tilg\u00e6ngelig i puljen eller det virtuelle enhed i den p\u00e5g\u00e6ldende topologi.<\/p>\n

\"Introduktion
\nDu kan oprette et test-pool med sparsomme filer p\u00e5 blot et par sekunder \u2014 men glem ikke at slette hele poolen og dens komponenter efterf\u00f8lgende.<\/i> <\/p>\n

Lad os sige, at du vil ops\u00e6tte en server med otte diske og planl\u00e6gger at bruge diske p\u00e5 10 TB (~9300 GiB) \u2014 men du er ikke sikker p\u00e5, hvilken topologi der bedst opfylder dine behov. I ovenst\u00e5ende eksempel opretter vi p\u00e5 f\u00e5 sekunder et test-pool med sparsomme filer \u2014 og vi ved nu, at et RAIDz2 vdev med otte diske p\u00e5 10 TB giver 50 TiB nyttig kapacitet.<\/p>\n

En anden s\u00e6rlig klasse af enheder er SPARE (reservedele). Hot-swappable enheder tilh\u00f8rer, i mods\u00e6tning til almindelige enheder, hele poolen, ikke et enkelt virtuelt device. Hvis et vdev i poolen svigter, og en reservedele er tilsluttet poolen og tilg\u00e6ngelig, vil den automatisk blive tilsluttet det ber\u00f8rte vdev.<\/p>\n

Efter at v\u00e6re blevet tilsluttet det ber\u00f8rte vdev, begynder reservedele-enheden at modtage kopier eller rekonstruktioner af data, der skulle v\u00e6re p\u00e5 den manglende enhed. I traditionel RAID kaldes dette genopbygning (rebuilding), mens det i ZFS kaldes 'genopretning af redundans' (resilvering).<\/p>\n

Det er vigtigt at bem\u00e6rke, at reservedele ikke permanent erstatter defekte enheder. Det er kun en midlertidig erstatning for at reducere den tid, hvor vdev er i degradering. N\u00e5r administratoren har udskiftet den defekte enhed i vdev, udf\u00f8res genopretning af redundans p\u00e5 denne permanente enhed, og SPARE l\u00f8snes fra vdev og returneres til at v\u00e6re en reserve for hele poolen.<\/p>\n

Datas\u00e6t, blokke og sektorer<\/h1>\n

\nDen n\u00e6ste gruppe byggesten, som vi skal forst\u00e5 i vores rejse gennem ZFS, handler ikke s\u00e5 meget om hardware, men om, hvordan dataene selv er organiseret og gemt. Vi springer her flere niveauer over \u2014 s\u00e5som metaslab \u2014 for ikke at overbelaste detaljerne, men for at bevare forst\u00e5elsen af den overordnede struktur.<\/p>\n

Datas\u00e6t (dataset)<\/h3>\n

\n\"Introduktion
\nN\u00e5r vi f\u00f8rst opretter et datas\u00e6t, viser det al tilg\u00e6ngelig plads i poolen. Derefter indstiller vi en kvote \u2014 og \u00e6ndrer monteringspunktet. Magi!<\/i> <\/p>\n

\"Introduktion
\nZvol er i det store og hele blot et datas\u00e6t, der mangler sit lag af filsystem, som vi her erstatter med et helt normalt filsystem som ext4.<\/i> <\/p>\n

ZFS-datasettet er omtrent det samme som et standard montert filsystem. Som et vanlig filsystem, ser det ved f\u00f8rste \u00f8yekast ut som \"bare en annen mappe\". Men akkurat som med vanlige monterte filsystemer, har hvert ZFS-datasett sitt eget sett med grunnleggende egenskaper.<\/p>\n

F\u00f8rst og fremst kan et datasett ha en tildelt kvote. Hvis du setter zfs set quota=100G poolname\/datasetname<\/code>, vil du ikke v\u00e6re i stand til \u00e5 skrive til den monterte mappen \/poolname\/datasetname<\/code> mer enn 100 GiB.<\/p>\n

La merke til tilstedev\u00e6relsen \u2013 og frav\u00e6ret \u2013 av skr\u00e5streker i begynnelsen av hver linje? Hvert datasett har sin egen plass b\u00e5de i ZFS-hierarkiet og i det systemiske monteringshierarkiet. I ZFS-hierarkiet er det ingen ledende skr\u00e5strek \u2013 du starter med navnet p\u00e5 bassenget, og deretter veien fra ett datasett til et annet. For eksempel, pool\/parent\/child<\/code> for et datasett med navnet child<\/code> under det overordnede datasettet parent<\/code> i bassenget med det kreative navnet pool<\/code>.<\/p>\n

Som standard vil monteringspunktet for datasettet v\u00e6re likt navnet i ZFS-hierarkiet, med en skr\u00e5strek i begynnelsen \u2013 bassenget med navnet pool<\/code> blir montert som \/pool<\/code>, datasettet parent<\/code> monteres i \/pool\/parent<\/code>, og det underordnede datasettet child<\/code> blir montert i \/pool\/parent\/child<\/code>. Imidlertid kan det systemiske monteringspunktet for datasettet endres.<\/p>\n

Hvis vi angir zfs set mountpoint=\/lol pool\/parent\/child<\/code>, vil datasettet pool\/parent\/child<\/code> bli montert i systemet som \/lol<\/code>.<\/p>\n

I tillegg til datasettene, m\u00e5 vi nevne volumene (zvols). Et volum er omtrent det samme som et datasett, bortsett fra at det faktisk ikke har et filsystem \u2013 det er bare et blokkeringsenhet. Du kan for eksempel lage zvol<\/code> med navnet mypool\/myzvol<\/code>, deretter formatere det med filsystemet ext4, og deretter montere dette filsystemet \u2013 n\u00e5 har du et ext4-filsystem, men med st\u00f8tte for alle ZFS-sikkerhetsfunksjonene! Dette kan virke meningsl\u00f8st p\u00e5 \u00e9n datamaskin, men gir mye mer mening som backend n\u00e5r du eksporterer iSCSI-enheter.<\/p>\n

Units<\/h3>\n

\n\"Introduktion
\nEn fil er representert av en eller flere blokker. Hver blokk lagres p\u00e5 ett virtuelt enhet. St\u00f8rrelsen p\u00e5 blokkene er vanligvis lik parameteren recordsize<\/b>, men kan reduseres til 2^ashift<\/b>, hvis det inneholder metadata eller en liten fil.<\/i><\/p>\n

\"Introduktion
\nVi mener virkelig, faktisk<\/b> at vi ikke sp\u00f8ker med det enorme ytelsestapet hvis vi setter en for liten ashift.<\/i><\/p>\n

I ZFS-pool gemmes alle data, inklusive metadata, i blokke. Den maksimale blokst\u00f8rrelse for hver dataset defineres i egenskaben recordsize<\/code> (optagelsesst\u00f8rrelse). Optagelsesst\u00f8rrelsen kan \u00e6ndres, men dette vil ikke \u00e6ndre st\u00f8rrelsen eller placeringen af eventuelle blokke, der allerede er skrevet til datas\u00e6ttet - det g\u00e6lder kun for nye blokke, efterh\u00e5nden som de skrives.<\/p>\n

Medmindre andet er angivet, er den aktuelle standard optagelsesst\u00f8rrelse 128 KiB. Dette er en slags kompliceret kompromis, hvor ydelsen vil v\u00e6re acceptabel, men ikke optimal i de fleste tilf\u00e6lde. Optagelsesst\u00f8rrelse<\/code> kan indstilles til enhver v\u00e6rdi fra 4K til 1M (med yderligere indstillinger recordsize<\/code> kan indstilles endnu st\u00f8rre, men det er sj\u00e6ldent en god id\u00e9).<\/p>\n

Enhver blok henviser kun til data fra \u00e9n fil - du kan ikke presse to forskellige filer ind i \u00e9n blok. Hver fil best\u00e5r af en eller flere blokke, afh\u00e6ngigt af st\u00f8rrelsen. Hvis filst\u00f8rrelsen er mindre end optagelsesst\u00f8rrelsen, vil den blive gemt i en mindre blok - for eksempel vil en blok med en fil p\u00e5 2 KiB kun optage \u00e9n 4 KiB sektor p\u00e5 disken.<\/p>\n

Zvol-m\u00e6ngder har ikke egenskaben recordsize<\/code>\u00a0\u2014 i stedet har de en tilsvarende egenskab volblocksize.<\/code>.<\/p>\n

Sektorer<\/h3>\n

\nDen sidste, mest grundl\u00e6ggende byggeklods er sektoren. Det er den mindste fysiske enhed, der kan skrives eller l\u00e6ses fra det underliggende device. I flere \u00e5rtier har de fleste diske brugt sektorer p\u00e5 512 byte. I de seneste \u00e5r har de fleste diske v\u00e6ret indstillet til 4 KiB-sektorer, og i nogle - is\u00e6r SSD'er - 8 KiB-sektorer eller endda st\u00f8rre.<\/p>\n

I ZFS-systemet er der en egenskab, der g\u00f8r det muligt at indstille sektorst\u00f8rrelsen manuelt. Denne egenskab ashift<\/code>. Det er lidt forvirrende, at ashift er en potens af to. For eksempel, ashift=9<\/code> betyder sektorst\u00f8rrelse 2^9 eller 512 byte.<\/p>\n

ZFS anmoder operativsystemet om detaljerede oplysninger om hver blok enhed, n\u00e5r det tilf\u00f8jes til en ny vdev, og teoretisk set indstiller det automatisk ashift korrekt baseret p\u00e5 disse oplysninger. Desv\u00e6rre lyver mange diske om deres sektorst\u00f8rrelse for at bevare kompatibiliteten med Windows XP (som ikke kunne forst\u00e5 diske med andre sektorst\u00f8rrelser).<\/p>\n

Dette betyder, at ZFS-administratorer st\u00e6rkt anbefales at kende den faktiske sektorst\u00f8rrelse af deres enheder og manuelt indstille ashift<\/code>. Hvis en for lille ashift er indstillet, stiger antallet af l\u00e6se-\/skriveoperationer astronomisk. S\u00e5ledes betyder skrivning af 512-bytes 'sektorer' til en faktisk sektor p\u00e5 4 KiB, at det er n\u00f8dvendigt f\u00f8rst at skrive den 'sektor', s\u00e5 l\u00e6se den 4 KiB sektor, \u00e6ndre den med den anden 512-bytes 'sektor', skrive den tilbage til en ny 4 KiB sektor og s\u00e5 videre for hver skrivning.<\/p>\n

I den virkelige verden rammer en s\u00e5dan straf SSD'er fra Samsung EVO, for hvilke der skal v\u00e6re ashift=13<\/code>, men disse SSD'er lyver om deres sektorst\u00f8rrelse, og derfor er standardindstillingen ashift=9<\/code>. Hvis en erfaren systemadministrator ikke \u00e6ndrer denne parameter, fungerer denne SSD langsommere<\/i> som en almindelig magnetisk HDD.<\/p>\n

Til sammenligning er der n\u00e6sten ingen straf for en for stor st\u00f8rrelse ashift<\/code> . Der er ingen reel neds\u00e6ttelse af ydeevnen, og stigningen i ubrugt plads er uendeligt lille (eller lig nul ved aktiveret kompression). Derfor anbefaler vi kraftigt, at selv de diske, der faktisk bruger 512-bytes sektorer, skal indstille ashift=12<\/code> eller endda ashift=13<\/code>, for at se mod fremtiden med tillid.<\/p>\n

Egenskab ashift<\/code> indstilles for hver virtuel enhed vdev, og ikke for puljen<\/i>, som mange fejlagtigt tror - og \u00e6ndres ikke efter installation. Hvis du ved en fejltagelse har \u00e6ndret ashift<\/code> da du tilf\u00f8jede en ny vdev til puljen, har du uopretteligt forurenet denne pulje med en enhed med lav ydeevne, og der er som regel ikke andet valg end at \u00f8del\u00e6gge puljen og starte forfra. Selv fjernelse af vdev redder ikke fra den forkert indstillede ashift<\/code>!<\/p>\n

Skrivningsmekanismen<\/h3>\n

\n\"Introduktion
\nHvis et almindeligt filsystem skal skrive data igen - \u00e6ndrer det hver blok, hvor den st\u00e5r<\/i><\/p>\n

\"Introduktion
\nFilssystemet med skriv-kopiering skriver en ny version af blokken og ul\u00e5ser derefter den gamle version.<\/i><\/p>\n

\"Introduktion
\nI abstrakt forstand, hvis man ser bort fra den faktiske fysiske placering af blokke, forenkles vores \u201edatakometa\u201c til et \u201edatorm\u201c som bev\u00e6ger sig fra venstre mod h\u00f8jre p\u00e5 kortet af det tilg\u00e6ngelige rum.<\/i><\/p>\n

\"Introduktion
\nNu kan vi f\u00e5 en god forst\u00e5else for, hvordan snapshot af skriv-kopiering fungerer \u2014 hver blok kan tilh\u00f8re flere snapshots og bevares, indtil alle tilknyttede snapshots fjernes.<\/i><\/p>\n

Skriv-kopieringsmekanisme (Copy on Write, CoW) er den grundl\u00e6ggende basis for, hvad der g\u00f8r ZFS til et s\u00e5 fantastisk system. Hovedkonceptet er enkelt \u2014 hvis du beder et traditionelt filsystem om at \u00e6ndre en fil, vil det g\u00f8re pr\u00e6cist det, du bad om. Hvis du beder et filsystem med skriv-kopiering om at g\u00f8re det samme, vil det sige \u201eokay\u201c \u2014 men lyve for dig.<\/p>\n

I stedet skriver filsystemet med skriv-kopiering en ny version af den \u00e6ndrede blok og opdaterer derefter filmetadataene for at bryde forbindelsen til den gamle blok og binde den til den nye blok, som du lige har skrevet.<\/p>\n

Frakoblingen af den gamle blok og bindingen af den nye udf\u00f8res i en enkelt operation, s\u00e5 den ikke kan afbrydes \u2014 hvis du slukker str\u00f8mmen, efter at det er sket, har du en ny filversion, og hvis du slukker str\u00f8mmen f\u00f8r, har du den gamle version. I begge tilf\u00e6lde vil der ikke opst\u00e5 konflikter i filsystemet.<\/p>\n

Skriv-kopiering i ZFS foreg\u00e5r ikke kun p\u00e5 filsystemniveau, men ogs\u00e5 p\u00e5 diskstyringsniveau. Det betyder, at ZFS ikke er modtagelig for skrivefejl (fejl i RAID<\/a><\/noindex>) \u2014 et f\u00e6nomen, hvor b\u00e5ndet kun er blevet delvist skrevet, f\u00f8r systemet fejler, hvilket resulterer i et beskadiget array efter genstart. Her skrives b\u00e5ndet atomisk, vdev er altid konsistent, og Bob er din onkel.<\/a><\/noindex>.<\/p>\n

ZIL: ZFS intentionslog.<\/h3>\n

\n\"Introduktion
\nZFS-systemet h\u00e5ndterer synkroniserede skrivninger p\u00e5 en s\u00e6rlig m\u00e5de \u2014 det gemmer dem midlertidigt, men straks i ZIL, f\u00f8r de senere skrives permanent sammen med asynkrone skrivninger.<\/i><\/p>\n

\"Introduktion
\nNormalt bliver data skrevet til ZIL aldrig l\u00e6st igen. Men det er muligt efter et systemfejl.<\/i><\/p>\n

\"Introduktion
\nSLOG, eller det sekund\u00e6re LOG-enhed, er blot et specielt - og helst meget hurtigt - vdev, hvor ZIL kan opbevares adskilt fra det prim\u00e6re lager.<\/i><\/p>\n

\"Introduktion
\nEfter et nedbrud genskabes alle de beskidte data i ZIL - i dette tilf\u00e6lde er ZIL placeret p\u00e5 SLOG, s\u00e5 de genskabes netop derfra.<\/i><\/p>\n

Der er to hovedkategorier af skriveoperationer - synkrone (sync) og asynkrone (async). For de fleste arbejdsbelastninger er langt st\u00f8rstedelen af skriveoperationerne asynkrone - filsystemet tillader at aggregere dem og udlevere i pakker, hvilket reducerer fragmentering og betydeligt \u00f8ger b\u00e5ndbredden.<\/p>\n

Synkrone skrivninger er noget helt andet. N\u00e5r en applikation anmoder om en synkron skrivning, siger den til filsystemet: 'Du skal gemme dette i non-volatile hukommelse, lige nu<\/i>, og indtil da kan jeg ikke g\u00f8re noget mere'. Derfor skal synkrone skrivninger straks bekr\u00e6ftes p\u00e5 disken - og hvis det \u00f8ger fragmenteringen eller neds\u00e6tter b\u00e5ndbredden, s\u00e5 v\u00e6r s\u00e5dan.<\/p>\n

ZFS h\u00e5ndterer synkrone skrivninger anderledes end almindelige filsystemer - i stedet for straks at indl\u00e6se dem i det almindelige lager, bevarer ZFS dem i et s\u00e6rligt opbevaringsomr\u00e5de kaldet ZFS Intent Log, eller ZIL. Hemmeligheden er, at disse poster ogs\u00e5<\/i> forbliver i hukommelsen, mens de er aggregeret sammen med almindelige asynkrone skriveanmodninger, for senere at blive udskrevet til lager som helt normale TXG (Transaction Groups).<\/p>\n

I normal drift skrives ZIL, og den l\u00e6ses aldrig igen. N\u00e5r skriveanmodninger fra ZIL efter et par \u00f8jeblikke bekr\u00e6ftes i det prim\u00e6re lager i almindelige TXG fra RAM, frakobles de fra ZIL. Det eneste tidspunkt, hvor noget l\u00e6ses fra ZIL, er ved import af puljen.<\/p>\n

Hvis der opst\u00e5r et ZFS-nedbrud - et systemfejl eller str\u00f8msvigt - n\u00e5r der er data i ZIL, vil disse data blive l\u00e6st under n\u00e6ste import af puljen (f.eks. ved genstart af det katastrofeafhj\u00e6lpende system). Alt, hvad der er i ZIL, vil blive l\u00e6st, samlet i TXG-grupper, gemt i det prim\u00e6re lager og derefter frakoblet fra ZIL under importprocessen.<\/p>\n

En af hj\u00e6lpeklasserne vdev kaldes LOG eller SLOG, det sekund\u00e6re LOG-enhed. Dens opgave er at give poolen en separat og, helst, meget hurtigere vdev-enhed med meget h\u00f8j skrivebestandighed til opbevaring af ZIL, i stedet for at opbevare ZIL p\u00e5 det prim\u00e6re vdev-lager. ZIL opf\u00f8rer sig ens uanset opbevaringsstedet, men hvis vdev med LOG har en meget h\u00f8j skriveydelse, vil synkrone skrivninger finde sted hurtigere.<\/p>\n

Tilf\u00f8jelse af vdev med LOG til poolen vil ikke kan ikke<\/b> forbedre ydeevnen for asynkrone skrivninger \u2013 selv hvis du tvinger alle skrivninger til ZIL med zfs set sync=always<\/code>, vil de stadig v\u00e6re bundet til det prim\u00e6re lager i TXG p\u00e5 samme m\u00e5de og i samme tempo som uden log. Den eneste direkte forbedring i ydeevnen er forsinkelsen af synkrone skrivninger (da h\u00f8jere loghastighed accelererer udf\u00f8relsen af operationer synk<\/code>).<\/p>\n

Men i et milj\u00f8, der allerede kr\u00e6ver mange synkrone skrivninger, kan vdev LOG indirekte accelerere asynkrone skrivninger og ikke-cachede l\u00e6sninger. Afsendelse af ZIL-skrivninger til en separat vdev LOG betyder mindre konkurrence om IOPS i det prim\u00e6re lager, hvilket forbedrer ydeevnen for alle l\u00e6se- og skriveoperationer i nogen grad.<\/p>\n

Snapshots<\/h3>\n

\nSkrive-ved-kopi mekanismen er ogs\u00e5 en n\u00f8dvendig grundpille for atomare snapshots af ZFS og inkrementel asynkron replikering. I et aktivt filsystem findes der et tr\u00e6 af pegepinde, der markerer alle poster med nuv\u00e6rende data \u2013 n\u00e5r du tager et snapshot, laver du blot en kopi af dette tr\u00e6 af pegepinde.<\/p>\n

N\u00e5r en post i det aktive filsystem overskrives, skriver ZFS f\u00f8rst den nye version af blokken til ikke-brugt plads. Derefter adskiller den den gamle version af blokken fra det nuv\u00e6rende filsystem. Men hvis et snapshot refererer til den gamle blok, forbliver den stadig u\u00e6ndret. Den gamle blok vil faktisk ikke blive genoprettet som ledig plads, indtil alle snapshots, der refererer til denne blok, er slettet!<\/p>\n

Replikering<\/h3>\n

\n\"Introduktion
\nMit Steam-bibliotek i 2015 fyldte 158 GiB og indeholdt 126.927 filer. Det er ret t\u00e6t p\u00e5 den optimale situation for rsync \u2013 ZFS-replikering over nettet var \"kun\" 750% hurtigere.<\/i><\/p>\n

\"Introduktion
\nI det samme netv\u00e6rk er replikationen af en 40-gigabyte Windows 7-maskinbillede en helt anden historie. ZFS-replikation finder sted 289 gange hurtigere end rsync \u2013 eller \"kun\" 161 gange hurtigere, hvis du er nok vidende til at kalde rsync med n\u00f8glen --inplace.<\/i><\/p>\n

\"Introduktion
\nN\u00e5r en maskinbillede skaleres, skaleres rsync-problemerne sammen med den. En st\u00f8rrelse p\u00e5 1,9 TiB er ikke s\u00e5 stor for et moderne maskinbillede \u2013 men det er stort nok til, at ZFS-replikation viser sig at v\u00e6re 1148 gange hurtigere end rsync, selv med rsync-argumentet --inplace.<\/i><\/p>\n

N\u00e5r du f\u00f8rst forst\u00e5r, hvordan snapshots fungerer, er det ikke sv\u00e6rt at fange essensen af replikation. Da et snapshot blot er et tr\u00e6 af pegepinde p\u00e5 poster, f\u00f8lger det, at hvis vi laver zfs send<\/code> et snapshot, s\u00e5 sender vi b\u00e5de dette tr\u00e6 og alle tilknyttede poster. N\u00e5r vi overf\u00f8rer dette zfs send<\/code> i zfs receive<\/code> til det m\u00e5lobjekt, skriver det b\u00e5de det faktiske indhold af blokken samt tr\u00e6et af pegepinde, der refererer til blokkene, i det m\u00e5lretter datas\u00e6t.<\/p>\n

Det bliver endnu mere interessant i det andet zfs send<\/code>. Nu har vi to systemer, hver med poolname\/datasetname@1<\/code>, og du tager et nyt snapshot poolname\/datasetname@2<\/code>. S\u00e5 i den oprindelige pulje har du datasetname@1<\/code> og datasetname@2<\/code>, mens den m\u00e5lrettede pulje indtil videre kun har det f\u00f8rste snapshot. datasetname@1<\/code>.<\/p>\n

Da vi har et f\u00e6lles snapshot mellem kilde og m\u00e5l datasetname@1<\/code>, kan vi lave en inkrementel<\/i> zfs send<\/code> over det. N\u00e5r vi siger til systemet zfs send -i poolname\/datasetname@1 poolname\/datasetname@2<\/code>, sammenligner det de to tr\u00e6er af pegepinde. Enhver pegepind, der kun eksisterer i @2<\/code>, refererer klart til nye blokke \u2013 derfor har vi brug for indholdet af disse blokke.<\/p>\n

I det fjerntliggende system er behandlingen af den inkrementelle send<\/code> lige s\u00e5 enkel. F\u00f8rst skriver vi alle nye poster inkluderet i str\u00f8mmen send<\/code>, og derefter tilf\u00f8jer vi pegepindene til disse blokke. Voila, vi har @2<\/code> i det nye system!<\/p>\n

Asynkron inkrementel replikation af ZFS er et k\u00e6mpe forbedring i forhold til tidligere metoder, der ikke er baseret p\u00e5 snapshots, s\u00e5som rsync. I begge tilf\u00e6lde overf\u00f8res kun de \u00e6ndrede data \u2013 men rsync skal f\u00f8rst l\u00e6se<\/i> l\u00e6se alle data fra begge sider for at kontrollere summen og sammenligne den. I mods\u00e6tning hertil l\u00e6ser ZFS-replikation ikke noget bortset fra tr\u00e6erne af pegepinde \u2013 og eventuelle blokke, der ikke er repr\u00e6senteret i det f\u00e6lles snapshot.<\/p>\n

Indbygget kompression<\/h3>\n

\nKopieringsmekanismen ved skrivning forenkler ogs\u00e5 systemet med indbygget kompression. I traditionelle filsystemer er kompression problematisk \u2014 b\u00e5de den gamle og den nye version af \u00e6ndrede data befinder sig i det samme rum.<\/p>\n

Hvis vi ser p\u00e5 et datastykke midt i en fil, der begynder sit liv som en megabyte af nuller fra 0x00000000 og fremad \u2014 s\u00e5 er det meget nemt at komprimere det til en enkelt sektor p\u00e5 disken. Men hvad sker der, hvis vi erstatter denne megabyte af nuller med en megabyte af ikke-komprimerbare data, s\u00e5som JPEG eller pseudorandom st\u00f8j? Pludselig vil denne megabyte data kr\u00e6ve ikke \u00e9n, men 256 sektorer p\u00e5 4 KiB, mens der kun er reserveret \u00e9n sektor p\u00e5 dette sted p\u00e5 disken.<\/p>\n

ZFS har ikke dette problem, da \u00e6ndrede poster altid skrives til ubrugt plads \u2014 den oprindelige blok optager kun \u00e9n sektor p\u00e5 4 KiB, og den nye post vil optage 256, men det er ikke et problem \u2014 det nyligt \u00e6ndrede stykke fra \"midten\" af filen ville blive skrevet i ubrugt plads uanset om dens st\u00f8rrelse \u00e6ndrede sig eller ej, s\u00e5 for ZFS er det en ganske almindelig situation.<\/p>\n

Indbygget kompression i ZFS er deaktiveret som standard, og systemet tilbyder tilsluttede algoritmer \u2014 lige nu inkluderer de LZ4, gzip (1-9), LZJB og ZLE.<\/p>\n

Hvis filen er stor nok og kr\u00e6ver flere blokke, vil alle optagelser med denne fil have st\u00f8rrelsen recordsize<\/code>\u00a0\u2014 inklusive den sidste optagelse, hvis hovedpart kan v\u00e6re ubrugeligt rum.<\/a><\/noindex>.<\/p>\n