ZFS

Der er forskellige versioner af ZFS-filsystemet og versioner af ZFS-puljen ( zpool ), og forskellig funktionalitet er tilgængelig afhængigt af versionen. Fra november 2012 er der 34 versioner af ZFS-puljen. Alle versioner af puljen er oprindeligt udgivet til Solaris .

Version 2 inkluderede understøttelse af replikerede metadata ( ditto blokke ) .  På grund af ZFS-diskformatets træstruktur kan uoprettelige fejl i puljens metadata resultere i, at puljen ikke kan åbnes. Denne funktion giver automatisk metadata-replikering (op til tre kopier af hver blok ) uanset underliggende redundans i hele poolen . For eksempel, i en pulje med et enkelt spejl, vil de mest kritiske metadata blive skrevet tre gange på hver side af spejlet, i alt seks kopier. Dette sikrer, at hvis data går tabt på grund af korruption, vil alle data i puljen kunne lokaliseres, og puljen vil være sund.  

Version 3 inkluderer understøttelse af hot spares og dobbelt paritet RAID-Z (raidz2); version 4 introducerede understøttelse til vedligeholdelse af ZFS-puljens historie ( zpool history); version 5 tilføjede understøttelse af on-the-fly-komprimering for ZFS-datasæt ved hjælp af gzip -metoden ; version 6 inkluderer understøttelse af bootfs- egenskaben (giver dig mulighed for at skifte rod-FS af det bootbare OS gennem en attribut, ud over bootloader-indstillingen).

Version 7 introducerede understøttelse af en "mållog" ( ZFS Intent Log , ZIL , lit. "intent log"), som giver applikationer mulighed for at vide, at de data, de har ændret, er i stabil lagring, når de vender tilbage fra et systemkald . Målloggen fører fortegnelser over disse systemkald, de afspilles igen, hvis der var et strømsvigt eller en kritisk fejl, hvor hovedpuljen ikke anerkendte deres udførelse. Når måljournalen er uden for hovedpuljen, allokerer den blokke, der kæder gennem puljen.

I version 8 er muligheden for at uddelegere administrative opgaver til administration af ZFS til almindelige brugere implementeret; før det havde kun administratorer mulighed for at administrere ZFS.

I version 9 er der udover de eksisterende kvote- og reservationsfunktioner tilføjet tildelingen af ​​kvoter og reserver, som ikke inkluderer forbrug af diskplads ved indlejrede datastrukturer, såsom kloner og kvoter ( zfs set refquota, zfs set refreservation). Reservationen etableres automatisk, når den oprettede ikke-sparse ( ikke-sparse ) ZFS-volumen matcher størrelsen af ​​partitionen. Også i version 9 er understøttelse af CIFS -serveren tilføjet.

Version 10 introducerede muligheden for at tilføje enheder til en pulje som cache-enheder for at give et ekstra lag af caching mellem hovedhukommelsen og disken. Brugen af ​​cache-enheder forbedrer ydeevnen betydeligt for tunge læsninger af uordentligt, for det meste statisk indhold. I version 12 dukkede understøttelse af snapshot-egenskaber op, i version 13 blev følgende snapshot-egenskaber tilgængelige: usedbysnapshots, usedbychildren, usedbyrefreservation, usedbydataset, i version 14 er egenskaberne og også tilgængelige passthrough-x, aclinheriti version 15 er egenskaberne userused, groupused, userquota, inkluderet groupquota.

Version 17 introducerede understøttelse af triple parity RAID-Z . Version 18 understøtter funktionen ZFS snapshot holds . Fra version 19 blev det muligt at fjerne en tilsluttet enhed til lagring af logfiler; tidligere kunne en sådan enhed ikke fjernes. Version 20 inkluderer zle- komprimeringsalgoritmen .

Version 21 introducerer deduplikering (større brug af zle). Fra version 30 understøttes filsystemkryptering , startende med version 32 understøttes en 1 MB blok, og i version 34 er oprettelsen af ​​netværksshares med nedarvning mellem filsystemer implementeret.

Version 37 tilføjede understøttelse af lz4- komprimeringsalgoritmen (mere effektiv og hurtigere end de eksisterende).

Transaktionsmodellen ved hjælp af copy-on-write

ZFS bruger en objekttransaktionsmodel baseret på kopi-på-skriv-mekanismen . Alle pointere til blokke i filsystemet indeholder en 256-bit kontrolsum i målblokken, som kontrolleres, når blokken læses. Enten Fletcher-summen eller den kryptografiske hash-funktion SHA-256 kan bruges som kontrolsum . [13] Andre kontrolsummer kan vælges for dataene. Datablokke, der indeholder aktive (i øjeblikket) data, overskrives aldrig sammen; tværtimod tildeles en ny blok, de ændrede data skrives til den, og derefter metadataene for alle blokke, der refererer til den, så alt omallokeres og skrives. For at reducere overhead, grupperer denne proces flere opdateringer i en transaktionsgruppe, og hvis det er nødvendigt, logger brugen på synkrone skrivninger.

ZFS-puljen vedligeholder en log over de sidste par dusin versioner af pooldataene (for de sidste par minutter, timer eller dage, afhængigt af intensiteten af ​​dataændringen), designet til at gendanne data, hvis en systemfejl har medført samle sig i en inoperabel, uhelbredelig tilstand. Med copy-on-write er alle disse versioner af dataene i loggen selvstændige, men deler fælles data.

Snapshots og kloner

Kopier-for-skriv-modellen i ZFS har en anden stærk fordel: når ZFS skriver nye data - i stedet for at frigøre blokke, der indeholder gamle data - kan den gemme dem ved at skabe snapshots af filsystemet. Snapshots i ZFS oprettes meget hurtigt (med undtagelse af sjældne tilfælde af en lang puljeblokering ved en tidskrævende operation med FS), da alle data i snapshottet allerede er gemt; de er også pladseffektive, da uændrede data deles (deltes) mellem filsystemet og dets snapshot.

Et skrivbart snapshot ("klon") kan også oprettes fra ethvert snapshot, hvilket resulterer i to eller flere uafhængige filsystemer eller volumener, der deler et kompleks af blokke for at reducere det overordnede fodaftryk og reducere klonoprettelsestiden. Så snart der er foretaget ændringer i en hvilken som helst klon af filsystemet, oprettes blokke af nye data til det, og de gamle data forbliver i alle andre kloner.

Når den er oprettet, er en klon knyttet til det øjebliksbillede, hvorfra den blev oprettet. Dette snapshot kan ikke ødelægges, så længe det er refereret af mindst 2 kloner (inklusive det originale lager). For at fjerne dette link skal lageret (filsystemet eller volumen) genskabes, men det gøres nemt ved hjælp af overførsel, og du kan undgå at optage ekstra plads i poolen, hvis du aktiverer deduplikering under overførslen og overfører lageret inden for samme pool.

Snapshots giver dig adgang til de data, der var i hvælvingen på det tidspunkt, hvor snapshottet blev taget som den samme skrivebeskyttede hvælving, uanset den originale hvælving, dens kloner og andre snapshots. De giver dig også mulighed for hurtigt og præcist at gendanne lagerdata til en snapshot-tilstand.

Snapshots og kloner kan oprettes rekursivt for et træ af filsystemer. Dette undgår behovet for selv at gentage kommandoer og administrere transaktioner, da rekursiv snapshot-oprettelse er atomisk.

Oprettelse af snapshots og kloner (såvel som nye filsystemer) kan være vanskeligt på grund af begrænsningerne ved ZFS. Snapshots og kloner kan ikke oprettes, hvis navnet på mindst én af dem overstiger grænsen (og det fulde navn på snapshottet er længere end originalens fulde navn med mindst 2 tegn), hvis der er en navnekonflikt (vigtigt for rekursiv snapshot-oprettelse), hvis nye kvoter overskrides, eller reserver ikke er gennemførlige (kvoter og reserver er nedarvet fra originalen).

Baseret på snapshots implementeres inkrementelle lagerbackups. Ved at bruge snapshot-videresendelse kan du genskabe den samme sekvens af snapshots i enhver ZFS-pulje. Efter oprettelse af nye snapshots af originalen genskaber trinvis snapshot-overførsel de samme opdaterede data i kopien eller klonen, medmindre der er en opdateringskonflikt. Snapshots fortæller dig også, hvilke filer der er blevet ændret, oprettet, slettet og omdøbt mellem snapshots.

Dynamisk partitionering

Dynamisk partitionering af alle enheder ved maksimal gennemstrømning betyder, at yderligere enheder er inkluderet i zpoolen, bredere kanaler udvides automatisk til at omfatte brugen af ​​alle diske i puljen, dette afbalancerer skrivebelastningen.

Forskellige blokstørrelser

ZFS bruger en variabel blokstørrelse på op til 1 megabyte (fra poolversion 32 var den tidligere op til 128 kilobyte). I øjeblikket har administratoren lov til at indstille den maksimale blokstørrelse, der bruges, men noget arbejde vil mislykkes (eller mislykkes), hvis der bruges for store blokke. Automatiske ydeevneindstillinger svarer til privilegier.

Hvis komprimering er aktiveret, bruges variable blokstørrelser. Hvis en blok er blevet komprimeret, kan den smelte sammen til en mindre blok, hvilket betyder, at der bruges mindre diskplads, og gennemløbet (Input/Output) øges (på bekostning af øget CPU- og RAM-brug til komprimerings- og dekomprimeringsoperationer).

ZFS-puljen understøtter også forskellige enhedssektorstørrelser og vælger automatisk den største blokstørrelse fra de enheder, der blev angivet, da puljen blev oprettet (derefter kan poolblokkens størrelse ikke ændres). Størrelser på 512 bytes, 4 KiB (4K) understøttes stabilt. Store blokstørrelser understøttes også, men operativsystemet fungerer muligvis ikke stabilt.

End-to-end dataintegritetskontrol

End-to-end integritetskontrol refererer til at skrive en kontrolsum til disken for hver datablok, og kontrolsummen og dataene er specielt placeret så langt som muligt fra hinanden for at reducere sandsynligheden for deres ledskader. Hvis der er flere enheder i puljen, vil kontrolsummen blive skrevet på den anden for dataene på en af ​​dem. Kontrolsummer beregnes ikke kun for data, men også for metadata, og det viser sig, at puljen altid har en kontrolsum for hver informationsblok.

Når du læser en blok, beregnes dens kontrolsum, og resultatet sammenlignes med kontrolsummen, der er gemt på disken. I tilfælde af uoverensstemmelse opdages fejlen straks. Selvfølgelig, hvis ingen redundans var planlagt på forhånd i puljen (hverken RAID-Z eller på anden måde), så kan fejlen ikke rettes, men de beskadigede data vil ikke blive præsenteret som sande.

Pointen med End-to-End-dataintegritet er at forhindre uopdaget datakorruption på grund af drev- eller controllerhardware eller firmwarefejl. Selvom sandsynligheden for en sådan hændelse synes lav, viser nogle undersøgelser, at den er ret væsentlig for organisationer af enhver størrelse [14] .

Programmer, der læser eller skriver data, skal understøtte disse funktioner (muligheden for manglende læsning af en enkelt blok af en fil, muligheden for, at puljen går ind i en tilstand af at vente på lagergendannelse med I/O hængende på ubestemt tid).

Oprettelse af et letvægts filsystem

I ZFS er det nemmere at manipulere et filsystem i en pulje end mængden af ​​manipulation i traditionelle filsystemer; den tid og indsats, der kræves for at oprette eller ændre et ZFS-filsystem, svarer mere til mængden af ​​arbejde, der er involveret i en ny mappe end med partitionsmanipulation i andre teknologier.

Yderligere funktioner

Yderligere funktioner omfatter en funktion til at indstille en specifik I/O-prioritet med en planlægningsperiode, understøttelse af flere uafhængige gevind med forebyggende automatisk detektering af længde og pitch, intelligent rengøring og korrektion [15] , indlæsning og deling af diske i en pool [16] , multipel afspilning af metadata [ 17 ] , understøttelse af copy-on-write-mekanismen , muligheden for at vælge et boot-filsystem i OS -indlæseren , installere det primære boot-filsystem, oprette flere rodfilsystemer, hvoraf et (med alle børn) vil blive brugt ved indlæsning af OS , evnen til at integrere software og OS -opdateringer med oprettelse af snapshots og kloner af filsystemer, hvor programmerne er gemt, og brugen af ​​disse snapshots til nemt at gendanne en tidligere version, og kloner at oprette et multiboot-system med mulighed for at starte forskellige konfigurationer eller OS -versioner ( Solaris opdateres som standard), en mulighed for begrænsning af filnavne til gyldig tekst i UTF-8 i den valgte normale form, en mulighed for at ufølsomme tilfælde af bogstaver i filnavne.

Cachehåndtering

ZFS introducerer også adaptiv cache-erstatning ( ARC ), en ny metode til at administrere cachen i stedet for de traditionelle Solaris-in-memory-cache-virtuelle sider.

Adaptiv endianness

Arrays og ZFS konfigureret på dem kan overføres mellem forskellige platforme, selvom de har en anden endianitet. ZFS-blokformatet giver mulighed for automatisk registrering og genbestilling af bytes på farten, når metadata læses.

Samtidig påvirker den forskellige byte-rækkefølge på forskellige systemer ikke applikationer på nogen måde, filerne for dem forbliver en simpel sekvens af bytes. Således er applikationer ansvarlige for det uafhængige (platform)format, der allerede findes i selve filerne.

Pool attributter

Pool-attributter er en måde at kontrollere funktioner og indstillinger for en pool. De har specielle typer og skrivebegrænsninger. De angiver, om puljen er skrivbar eller læsbar, om datadeduplikering er aktiveret, FS til indlæsning af OS som standard, en alternativ mount-rod, poolkarakteristika og mere.

Datalagersystemattributter

Repository-systemattributter er en måde at administrere arkivernes muligheder og indstillinger. De har specielle typer og skrivebegrænsninger. De specificerer indstillingerne for kryptering, komprimering, kontrolsummer, deduplikering, sikkerhedskopiering, cachelagring, størrelsen af ​​datalagerblokke for specifikke lager. De angiver også størrelsen af ​​volumener, FS-monteringspunkter, tilgængeligheden af ​​individuelle lager til skrivning, tilhørsforhold af lager til zoner, mandater, reserver, kvoter, indstillinger for automatisk oprettelse af netværksshares (NFS, SMB), adgangsrettigheder til dem og mere. Disse attributter specificerer hvælvingernes karakteristika. Disse attributter gør det nemmere at administrere FS-relaterede funktioner, der tidligere blev udført manuelt (f.eks. opsætning af montering af flere yderligere filsystemer, oprettelse af netværksshares).

Nogle af systemattributterne nedarves af underordnede arkiver; som følge heraf anvendes attributterne også med det samme på underordnede arkiver. Attributter til kontrolkompression, deduplikering, datakontrolsummer og lignende gælder kun for nyskrevne data. For at anvende dem på alle data skal dataene overskrives (dette gøres nemt ved at sende snapshots til den samme pulje med genskabelse af lagrene).

Datalager brugerdefinerede attributter

Hvert datalager (FS, volumen, snapshot osv.) kan tildeles brugerdefinerede attributter. Brugerattributter adskiller sig fra systemattributter i deres navne. For brugerdefinerede attributter kan du bruge et hvilket som helst navn (fra 1 til 2¹⁰ bytes), men det anbefales at bruge navne, der indeholder et kolon (for at undgå konflikter med systemattributter), dit domænenavn før dette kolon (for at undgå med andre brugere) , attributnavnet efter kolon. Tilpassede attributter arves af underordnede butikker.

På grund af den forgrenede udvikling af nye funktioner i forskellige operativsystemer, bruges flere af disse attributter som nye systemattributter.

Brugerdefinerede attributter bruges af brugere og selvstændige programmer (f.eks. tidsskyderen automatisk oprettelse og backup-program).

Filsystemattributter

For filer af enhver type kan værdien af ​​flere systemattributter angives. [18] Disse attributter giver dig mulighed for at kontrollere handlinger på filen. Udvidede filattributter har de samme systemattributter.

Ud over de attributter, der gemmer oprettelsesdatoer, sidste adgang, sidste ændring, sidste metadataændring, er der attributter [19] :

Udvidede attributter

Du kan oprette udvidede attributter for hver fil af enhver type. Den udvidede attribut er et navngivet array af bytes, ligesom en almindelig fil. Udvidede attributter, som almindelige filer, kan tildeles deres egne tilladelser og systemattributter. I modsætning til en almindelig fil kan udvidede attributter, hårde links, ikke oprettes for udvidede attributter. Udvidede filattributter har mulighed for at blive behandlet som normale filer i begrænset omfang. For at gøre dette oprettes en unavngiven mappe for hver fil (på tidspunktet for oprettelsen af ​​den første udvidede attribut), hvor almindelige filer svarende til de udvidede attributter for denne fil er tilgængelige. På Solaris kan denne mappe tilgås ved hjælp af værktøjet runat[21] .

Uddelegering af beføjelser til brugere

Administration af individuelle bokse kan delegeres til brugere. For at gøre dette har ZFS tildelt beføjelser, der kan delegeres (oprettelse af lager, snapshots, sletning, montering, sammenligning, videresendelse og mere). Tilladelser delegeres til de valgte bokse på samme måde som tildeling af attributter og udvides til underordnede bokse.

Dataopbevaring og backup

På grund af " kopier-på-skriv "-princippet er  dataene i ZFS altid i en konsistent tilstand, filen kan ikke gå tabt på tidspunktet for overskrivning [6] .

Ved brug af diskenheder med redundans (RAIDZ-volumener) sikres datasikkerheden i tilfælde af fysisk mediefejl [6] [22] , mens RAIDZ er effektiv til relativt langvarig lagring af store filer, især ved indstilling af blokstørrelsen svarende til filer, og med hyppig omskrivning og ved placering af filer i små størrelser, er der en øget belastning på processor- og diskundersystemet [6] .

Begrænsninger

• Solaris 10's implementering af ZFS mangler gennemsigtig kryptering, som fundet i Solaris 11 og NTFS , selvom der er en implementering af det som en del af OpenSolaris-projektet [23] .
• ZFS understøtter ikke tildeling af kvoter pr. bruger eller pr. gruppe. I stedet kan du hurtigt oprette FS til brugere, som hver vil have sin egen størrelse. Som sådan er der ingen praktisk kvoteløsning for filsystemer, der deles af forskellige brugere (f.eks. et udviklingsteam-projekt), hvor data kan deles pr. bruger, men dette kan implementeres oven på ZFS- stakken .
• Lagerudvidelse opnås normalt ved at tilføje en diskgruppe, såsom en vdev (stripe, RAID-Z , RAID-Z2 eller mirror ). De nye data vil dynamisk bruge alle tilgængelige vdev'er. En anden måde at øge diskplads på er skiftevis at erstatte fysiske diske med større, med forventning om, efter hver sådan operation, indtil ZFS helbreder sig selv . Behandlingstiden afhænger af mængden af ​​gemt information og ikke af størrelsen på disken . Hvis der oprettes et øjebliksbillede under behandlingen  , vil dette genstarte behandlingsprocessen. Det skal bemærkes, at udskiftning af diske uden tab af data kun er mulig i en af ​​pooldriftstilstandene, der tillader det.
• I øjeblikket er det ikke muligt at reducere antallet af vdev'er uden at reducere poolstørrelsen. ZFS-udviklingsteamet arbejder dog på dette problem. Fra udgivelsen af ​​Solaris 10 08/11 (opdatering 10) er dette stadig ikke implementeret.
• Det er heller ikke muligt at tilføje et nyt drev til et RAID-Z- eller RAID-Z2-array (vdevs). Denne funktion er svær at implementere. Du kan dog oprette en RAIDZ vdev og tilføje den til zpool .
• Du kan ikke blande vdev-typer i en zpool. For eksempel, hvis du har en strippet ZFS-pulje, der indeholder diske på et SAN , vil du ikke være i stand til at tilføje lokale diske som en spejlet vdev.
• En komplet rekonfiguration af datalagring kræver lagring af data på eksterne medier (uden for ZFS), ødelæggelse af puljer og oprettelse af nye puljer i henhold til nye regler. Men i de fleste tilfælde kan du slippe afsted med at overføre data fra den gamle pulje til den nye ved hjælp af ZFS, og bevare alle eller de ønskede data og attributter (uden at gemme uden for ZFS). Videresendelse hjælper ikke i tilfælde af aktivering eller deaktivering af kryptering, ændring af filnavnsbegrænsninger, deaktivering af obligatorisk adgangskontrol, ændring af diskblokstørrelse og andre sjældne operationer.
• ZFS er ikke i sagens natur et klynget , distribueret eller parallelt filsystem og giver ikke samtidig adgang til data fra forskellige værter. ZFS er et lokalt filsystem.
• I Solaris 11's implementering af ZFS kan du ikke ændre vdev-typen i zpool. For eksempel, hvis du har en ZFS-pulje, der indeholder diske (blokenheder), vil du ikke være i stand til at kopiere indholdet af diskene til almindelige filer og importere puljen fra disse filer, og omvendt - overføre puljen fra almindelige filer til diske.
• Sletning af en stor mængde data er en langsom blokeringsoperation (i poolversion 37 og tidligere), for eksempel kan sletning af et fragmenteret filsystem på 100 GiB tage mere end et minut og blokerer for at få en liste over filsystemer og et andet filsystem handlinger i samme pulje.
• Der er ingen måde at kontrollere genoprettelsen af ​​poolen efter gendannelse af adgangen til forskellige kopier af den spejlede pool. Systemet bestemmer selv, hvordan poolen desinficeres , selvom der er foretaget ændringer uafhængigt af forskellige kopier af poolen (dette er tilladt).
• En hårdt beskadiget pool kan ikke repareres og skal genskabes. Men i mange tilfælde kan brugerdata hentes fra den beskadigede pulje ved at importere dem til læsning.
• Nogle uhelbredelige poolkorruptioner i systemdata resulterer ikke i, at brugerdata bliver ødelagt eller blokerer poolændringer. Med disse skader fortsætter poolen udvendigt med at fungere normalt i lang tid og advarer ikke om behovet for at reparere det. Men hvis den ikke rettes, vil den i sidste ende miste brugerdata og ende i en uoprettelig eller endda ulæselig tilstand. Evnen til at opdage sådanne problemer og automatisk (hvis muligt) rette dem rettidigt er ikke indbygget i ZFS og kræver separat konfiguration.

Platforme

ZFS er en del af Solaris-operativsystemet og er tilgængelig til både SPARC- og x86 -platforme . Da ZFS-koden er open source (CDDL-licens), kan porte til andre operativsystemer og platforme produceres uden Oracle-involvering.

OpenSolaris

OpenSolaris 2008.05 bruger ZFS som standard filsystem.

Nexenta OS  er et operativsystem med et GNU - miljø bygget oven på OpenSolaris-kernen og dens runtime-miljø, ZFS-understøttelse var inkluderet i alpha1-versionen af ​​kernen. For nylig introducerede Nexenta Systems NexentaStor  , et ZFS-aktiveret netværkslagersystem, der giver NAS / SAN / iSCSI -funktioner og er baseret på Nexenta OS. NexentaStor inkluderer en grafisk grænseflade, der forenkler processen med at bruge ZFS. Den 2. december 2008 blev NexentaStor 1.1 udgivet. Det opdaterede OpenSolaris-kernen, forbedrede integrationen med CIFS/AD, tilføjede adskillige plugins og rettede nogle fejl. Der er to udgaver af NexentaStor: en kommerciel Enterprise Edition og en gratis Community Edition med en maksimal lagerkapacitet på 18TB. Fra august 2012 er den aktuelle softwareversion 3.1.3.

Linux