Når en ny versjon av OpenZFS slippes, lurer mange administratorer på om det er verdt å oppdatere nå eller vente på at støvet skal legge seg. OpenZFS 2.4 Spørsmålet er enda mer interessant, fordi Det kommer med dyptgripende endringer innen ytelse, nye administrasjonsverktøy og noe samfunnsdebatt om bruk av utgivelseskandidater i produksjonssystemer.
Generelle funksjoner i OpenZFS 2.4
OpenZFS 2.4 presenteres som en versjon av stabil og ganske ambisiøs karakter Prosjektet, som er designet for både Linux- og FreeBSD-miljøer, understreket allerede på tidspunktet for den endelige merkingen at målet var å fortsette å fremme modenheten til filsystemet og volumbehandleren, samtidig som kompatibilitet med nyere kjerner opprettholdes og datasikkerhet sikres.
Denne versjonen konsoliderer mange funksjoner som har vært under utvikling siden rama 2.3 og dens mellomliggende revisjoner: ytelsesforbedringer i krypteringslagnye administrasjonsverktøy som f.eks. zfs-omskrivingMer fleksible kvotemuligheter og interne endringer utformet for å redusere fragmentering, optimalisere deduplisering og forbedre komplekse aspekter som administrasjon av gjengblokker eller oppførsel med problematiske disker.
Samfunnet har også viet spesiell oppmerksomhet til integrasjon med moderne kjernerI Linux er støtte erklært fra 4.18 og opp til nyere LTS-grener (inkludert kjerne 6.18 på tidspunktet for den stabile utgivelsen av 2.4), mens i FreeBSD er versjoner fra 13.3 og utover dekket, inkludert 14.0 og nyere grener som forberedes, for eksempel 15.0.
Plattformstøtte og kjernekompatibilitet med OpenZFS 2.4
En av grunnpilarene i OpenZFS 2.4 er dens bred plattformkompatibilitetFor mange administratorer er dette viktig, fordi det lar dem oppgradere operativsystemversjoner uten å miste de forventede ZFS-funksjonene.
På Linux-siden indikerer OpenZFS 2.4 kompatibilitet med kjerner fra versjon 4.18 til serien 6.18 stabilDette dekker alt fra konservative bedriftsdistribusjoner til svært oppdaterte miljøer som holder seg oppdatert med den nyeste kjernen. Mellom dem ligger hele spekteret av vanlige utgivelser: LTS-versjoner brukt på servere, tilpassede kjerner og versjoner tatt i bruk av prosjekter som CentOS Stream eller lignende.
I FreeBSD støtter den nye versjonen fra FreeBSD 13.3 Fra nå av, inkludert 14.0 og senere versjoner som allerede er på trappene, som den kommende 15.0. Dette brede spekteret sikrer at både systemer som allerede er i produksjon og neste generasjons distribusjoner kan fortsette å bruke OpenZFS uten behov for merkelige oppdateringer eller tilpassede løsninger.
Bak denne kompatibiliteten ligger en kontinuerlig innsats som allerede var tydelig i serien. OpenZFS 2.3.xTidligere oppdateringer, som 2.3.4, utvidet kjernestøtte opp til 6.16 og konsoliderte oppdateringer som hadde begynt å dukke opp i tidligere RC-er. OpenZFS 2.4 tar opp der den slapp og går et skritt videre, og samkjører med nyere kjerner og forbedrer opplevelsen for de som oppdaterer basisstakken sin relativt ofte.
Kvoter og nye romhåndteringsmuligheter
Blant de mest praktiske nye funksjonene for administratoren er forbedringene i systemet med forhåndsbestemte kvoterOpenZFS 2.4 introduserer muligheten til å definere standardkvoter for brukere, grupper og prosjekter, slik at plassforbruket kan kontrolleres mer enhetlig uten å måtte konfigurere hvert tilfelle manuelt.
Denne funksjonen lar deg for eksempel sette en Grunnavgift for alle brukere som opprettes i et spesifikt datasett, eller for å sette prosjektgrenser som automatisk brukes når nye ressurser tildeles. Det er et veldig nyttig verktøy i flerbrukermiljøer, hosting, laboratorier og ethvert scenario der du vil forhindre at en forglemmelse fyller hele poolen.
Støtte for standardkvoter erstatter ikke eksisterende spesifikke kvoter, men utfyller dem heller. Administratoren kan definere en global politikk og deretter forbedre den med unntak for spesifikke brukere eller grupper som trenger mer (eller mindre) plass. Alt dette administreres med standard ZFS-verktøy, og opprettholder den samme egenskapsmodellen som allerede er kjent.
Direkte I/O, hurtigbufferløs I/O og feiljustert skriveatferd
Når det gjelder ytelse, bringer OpenZFS 2.4 en veldig interessant endring i administrasjonen av direkte inngang/utgangFrem til nå har bruk av direkte I/O i noen situasjoner kunnet komme i konflikt med skrivejustering og resultere i suboptimale kodebaner. Den nye versjonen introduserer en mekanisme slik at når direkte I/O ikke kan implementeres ideelt, brukes en alternativ modus. lett hurtigbufferløs IO spesielt utviklet for denne typen scenario.
Hva betyr dette i praksis? At tekster som ikke passer godt inn i de forventede samsvarene, slutter å være et patologisk tilfelle og i stedet håndteres med en optimalisert rute i ZFS. Overhead reduseres, noen flaskehalser unngås, og mer forutsigbar oppførsel oppnås, spesielt i miljøer der applikasjoner som bruker direkte I/O sameksisterer med andre som ikke gjør det.
Denne endringen er spesielt nyttig i krevende arbeidsmengder der målet er å presse ut ytelsen lagring uten å ofre integritetsgarantiene som tilbys av ZFS. Med en spesialdesignet reserveløsning er OpenZFS bedre egnet til virkeligheten til mange applikasjoner som ikke alltid overholder den ideelle driftsjusteringen.
Enhetlig allokeringsbegrensning og fragmenteringsreduksjon i OpenZFS 2.4
En annen stor endring som følger med OpenZFS 2.4 er introduksjonen av en ny algoritme for enhetlig allokeringsbegrensningBak dette navnet ligger en mekanisme som tar sikte på å redusere fragmenteringen av virtuelle enheter (vdevs) og forbedre hvordan skrivinger distribueres når systemet er under press.
Frem til nå kunne blokkallokering i situasjoner med høy belastning ende opp med å generere distribusjonsmønstre som over tid favoriserte fragmentering av vdevDen enhetlige algoritmen tar sikte på å harmonisere allokeringsraten, slik at poolen opprettholder en mer ordnet struktur og ytelsesstraff reduseres når plassen begynner å bli lav eller når blandingen av blokkstørrelser er svært variert.
Denne typen endringer er mindre merkbare enn en ny kommando, men de er svært verdifulle i langsiktige utrullinger, der et basseng vokser, balanseres på nytt, nye virtuelle utviklingsmiljøer (vdevs) legges til og vedlikeholdsoperasjoner utføres over flere år. Ved å forbedre allokeringskontrollen bidrar OpenZFS 2.4 til å opprettholde en mer stabil oppførsel over tidselv når systemet brukes intensivt.
Krypteringsforbedringer med AVX2 og AES-GCM
Når det gjelder sikkerhet og ytelse, inkluderer OpenZFS 2.4 en rekke optimaliseringer i bruken av AVX2 for AES-GCMEnklere sagt: krypteringsimplementeringen har blitt forbedret for bedre å dra nytte av mulighetene til moderne prosessorer som har disse avanserte vektorinstruksjonene.
Resultatet er raskere kryptering uten at det går på bekostning av kryptografiske garantier, noe som er spesielt merkbart i systemer som håndterer store mengder krypterte data eller i miljøer der mange samtidige operasjoner utføres på beskyttede datasett. redusere CPU-overhead knyttet til kryptering, kan flere forespørsler håndteres eller flere ressurser dedikeres til andre systemoppgaver.
I praksis kan administratorer fortsette å stole på funksjonene til ZFS innebygd kryptering for å beskytte sensitive data uten den betydelige ytelsespåvirkningen fra tidligere generasjoner. Kryptering blir ikke «gratis», men det blir mer håndterbart under arbeidsbelastninger der det tidligere var en klar flaskehals.
ZIL i spesielle videoutviklere og forbedringer i special_small_blocks
OpenZFS 2.4 bringer også nye funksjoner angående spesielle videoutviklere, de enhetene som er designet for å lagre bestemte typer data (som metadata, små blokker eller dedupliseringstabeller) på raskere medier, vanligvis SSD eller NVMe.
På den ene siden er det nå mulig å tillate ZIL (ZFS-intensjonslogg) Bruk dedikerte vdev-er når de er tilgjengelige. Dette gjør det enklere å konsentrere synkrone skrivinger på enheter med lav latens, noe som forbedrer responstiden til applikasjoner som er avhengige av synkroniseringsintensive operasjoner, for eksempel databaser eller meldingssystemer med sterk persistens.
På den annen side utvides eiendommens oppførsel special_small_blocks slik at ZVOL-skrifter De kan også lande i spesielle vdevs, ikke bare visse vanlige filblokker. Videre er begrensningen om at verdien må være en potens av to myknet opp, slik at administratoren kan velge finere størrelser skreddersydd til den faktiske arbeidsmengden i stedet for å være begrenset til rigide alternativer.
Kombinert tillater disse forbedringene utforming av lagringsarkitekturer der mest kritiske dataene (Metadata, små blokker, ZIL-er, dedupliseringstabeller osv.) lagres på raskere medier, mens mesteparten av dataene forblir på rimeligere disker. Alt dette kommer med mye større fleksibilitet i å definere hva som anses som «lite» og hva som ikke er det.
zfs rewrite og zfs rewrite -P: effektivt flytte data
2.3-serien hadde allerede en av de mest slående funksjonene i nyere tid: underkommandoen zfs-omskrivingOpenZFS 2.4 tar dette verktøyet et skritt videre ved å innlemme varianten zfs rewrite -Pnoe som gir nye muligheter ved flytting av data innenfor en pool.
Kommandoen zfs rewrite tillater «å skrive om«Innholdet i en fil eller et datasett kopieres uten å endre den logiske betydningen, men flyttes fysisk til andre områder med forskjellige interne egenskaper. Dette tillater modifikasjoner som komprimeringsalgoritme, sjekksumtype, om deduplisering brukes, antall kopier eller til og med den foretrukne enheten, uten å måtte kopiere dataene til brukerområdet og skrive dem om.»
Dette har flere klare fordeler: det reduserer I/O-trafikk sammenlignet med den klassiske «kopier og gi nytt navn»-metoden, minimerer påvirkningen på hurtigbufferen og unngår lange perioder der data flyttes gjennom eksterne verktøy. Videre, siden det ikke er noen logisk endring av innholdet, Tidspunktet endres ikke heller ikke andre egenskaper som er synlige fra brukerens synspunkt, noe som betyr at mange applikasjoner ikke engang er klar over operasjonen.
Alternativet zfs rewrite -P legger til muligheten for bevare det logiske fødselstidspunktet av blokkene når det er mulig, noe som bidrar til å minimere størrelsen på inkrementelle replikeringsflyter. Ved å holde denne informasjonen stabil, kan påfølgende sendings-/mottaksoperasjoner bedre identifisere hva som faktisk har endret seg og hva som ikke har det, noe som reduserer mengden data som må flyttes mellom systemer.
En annen viktig fordel er at omskrivingsprosessen er beskyttet med rekkeviddelåser normalt, slik at den kan kjøre parallelt med reelle arbeidsbelastninger uten å blokkere systemet unødig. I datasett med sync=always Fordelen er enda større, fordi ved å ikke ha noen logisk modifisering av data, blir det ikke tvunget frem ytterligere skriving i ZIL, noe som unngår en ekstra kostnad i synkrone operasjoner.
Nye administrasjonsalternativer i OpenZFS 2.4: -a|–all, range scrub og BRT prefetch
OpenZFS 2.4 forbedrer og utvider også arsenalet av administrasjonsverktøy med flere svært nyttige alternativer for daglig bruk. Et av disse er tillegget av alternativet -a|–alle i kommandoer som utfører vedlikeholdsoppgaver på bassenger, for eksempel skrubbing, trimning eller initialisering.
Dette alternativet gjør det mulig å starte en operasjon som påvirker alle importerte bassenger alt på en gang, i stedet for å måtte iterere gjennom hver enkelt manuelt. Dette forenkler ting betraktelig på servere som administrerer flere pooler, reduserer menneskelige feil og legger til rette for enklere automatisering.
I tillegg muligheten for å lansere en zpool scrub begrenset til spesifikke tidsintervaller gjennom alternativene -S -EDenne funksjonaliteten er høyt verdsatt når du bare vil gjennomgå et tidsvindu der det er mistanke om problemer, eller når du vil spre kostnadene for en scrub over flere delvise utførelser for ikke å påvirke den generelle ytelsen for mye.
En annen relevant ny funksjon er tillegget av zpool prefetch -t brt å forhåndslaste inn i minnet Blokreferansetabell (blokkkloningstabell)Dette gir bedre utnyttelse av blokkkloningsfunksjonaliteten som ble introdusert i tidligere versjoner, noe som reduserer ventetid ved tilgang til interne strukturer involvert i denne funksjonen.
Tillatelser, omdøpte verktøy og forbedringer av deduplikering og blokkkloning
Blant de små, men betydelige forbedringene som forbedrer opplevelsen, legger OpenZFS 2.4 til en ny tillatelse. send:kryptertDette er utviklet for å gi mer detaljert kontroll over hvem som kan sende krypterte data, og fungerer godt med team som har en ansvarsdeling mellom de som administrerer øyeblikksbilder, de som håndterer replikering og de som har tilgang til krypteringsnøkler.
Tradisjonelle forsyningsselskaper ble også omdøpt, som for eksempel arc_summary y arcstat, som deretter blir kjent zarcsummary y zarcstatDenne endringen bidrar til å unngå navnekonflikter og gjør det tydeligere at dette er verktøy tilknyttet ZFS, noe som er nyttig i systemer med flere komponenter som eksponerer lignende kommandoer.
Internt akkumuleres 2.4-serien Nye optimaliseringer og rettelser Dette gjelder både deduplisering og blokkkloning. Datastrukturer forbedres, kanttilfeller korrigeres, og det søkes etter bedre tilgangsmønstre for å gjøre påvirkningen på minne og CPU mer håndterbar. Disse endringene er ikke direkte synlige for brukeren, men de resulterer i mer stabil oppførsel og færre overraskelser under komplekse arbeidsbelastninger.
Gangblokker, ashift, langsomme barne-vdevs og spesielle topologier
OpenZFS 2.4 inneholder også en rekke forbedringer og rettelser i forhold til gjengblokkerDette er en intern systemfunksjon som er utformet for å håndtere blokker som ikke kan plasseres på vanlig måte. Selv om de fleste brukere ikke samhandler direkte med dem, kan enhver feil i denne delen av koden få alvorlige konsekvenser, så de mange rettelsene og optimaliseringene som er inkludert, er gode nyheter for systemets generelle robusthet.
Parallelt med håndteringen av ashiftParameteren som definerer minimum tildelingsenhet i henhold til den fysiske størrelsen på enhetens sektorer. Bedre skifthåndtering reduserer muligheten for å skrive mer data enn nødvendig til disker med store sektorer og bidrar til å opprettholde akseptable ytelsesnivåer gjennom hele poolens levetid.
En annen interessant ny funksjon er muligheten til å få barne-vdev-er til å oppføre seg på en unormalt treg De kan midlertidig «benkes». I stedet for å redusere ytelsen til hele systemet, kan de tas av kroken en stund, noe som er veldig nyttig når disker begynner å svikte, stasjoner opplever periodiske problemer, eller miljøer har inkonsekvent maskinvare.
Til slutt har de avslappede topologibegrensninger I spesielle og dedupliserte VDEV-er gir dette større fleksibilitet ved utforming av pooler med avanserte konfigurasjoner. Dette muliggjør bedre integrering av raske enheter for metadata, dedupliserte tabeller, ZIL-er og andre sensitive elementer uten å støte på altfor rigide begrensninger i layoutdefinisjonen.
OpenZFS 2.3.4: Vedlikehold, innledende omskriving av zfs og konsolidering
For å forstå spranget som 2.4 representerer fullt ut, er det verdt å ta en rask titt på OpenZFS 2.3.4, en vedlikeholdsversjon som dukket opp kort tid før og la noe av grunnlaget for det som senere har blitt konsolidert i den nye hovedgrenen.
Versjon 2.3.4 kom to måneder etter 2.3.3 med et veldig sterkt fokus på robusthet og kompatibilitetDen utvidet støtten for Linux-kjernen opp til versjon 6.16, med minimumsversjonen 4.18, og bekreftet kompatibilitet med FreeBSD fra versjon 13.3 og utover, inkludert den kommende 15.0. Med andre ord, den forberedte allerede grunnlaget for å sameksistere med moderne basissystemer uten å ofre stabilitet.
Denne spesifikke anmeldelsen så debuten til den første versjonen av kommandoen zfs rewritedesignet nettopp for flytte data uten å endre det logiske innholdet og uten å ty til mer tungvinte strategier som kopiering/endring av navn eller send/mottak med endring av datasett. Målet var å tilby et verktøy som er i stand til å balansere en pool på nytt etter å ha lagt til vdevs, redusere fragmentering av tilfeldig skrevne filer eller bruke nye lagringsegenskaper på eksisterende data.
Sammenlignet med tradisjonelle alternativer, zfs rewrite Det er raskere fordi det unngår at dataene overføres til brukerområdet. I datasett med sync=alwaysVidere forbedrer det ytelsen fordi, siden dataene ikke endres logisk, utløses ingen ytterligere skrivinger i ZIL. Alt dette uten å berøre noe. mtime eller andre metadata synlig for applikasjoner, noe som minimerer påvirkningen på programvaren som kjører oppå den.
Versjon 2.3.4 ga også diverse FreeBSD-spesifikke innstillingerDen inkluderte forbedringer i pakkeløsningen og en rekke mindre rettelser som finpusset noen deler av koden. Det var ikke en versjon som var ment å introdusere forstyrrende endringer, men snarere å finjustere stabiliteten før man hoppet til gren 2.4 med en større pakke med nye funksjoner.
OpenZFS 2.4 RC1, RC2, RC4: testing, tilbakemeldinger og diskusjon i fellesskapet
Før 2.4-serien ble erklært stabil, ga prosjektet ut flere løslate kandidater (RC1, RC2, RC4) med mål om å la avanserte brukere og utviklere teste dem og rapportere problemer. Disse utgivelseskandidatene inkluderte allerede så godt som alle funksjonene vi har diskutert: standardkvoter, hurtigbufferløs I/O som reserve, enhetlig allokeringsbegrensning, krypteringsforbedringer, ZIL i spesielle vdevs, special_small_blocks-utvidelser, nye tillatelser, verktøynavngiving og mye mer.
RC1- og RC2-notatene understreket viktigheten av fellesskapet Jeg skal teste byggene og send tilbakemelding via GitHub, inkludert kommandoer for å enkelt liste opp endringer i forhold til referansegrenen (med kombinasjoner av git cherry (sammenligning av zfs-2.3-utgivelsen med de forskjellige RC-ene). Budskapet var klart: målet var å teste koden i virkelige miljøer før den ble merket som "stabil".
Utseendet til en spesifikk RC (for eksempel, 2.4.0-RC4Inkluderingen av et .NET Framework (RF) i en versjon av FreeBSD merket som RELEASE, som for eksempel 15.0, vakte oppsikt. Noen brukere lurte på hvorfor man hadde besluttet å inkludere et. OpenZFS-utgivelseskandidat i en versjon som anses som stabil av operativsystemet i stedet for å ty til en tidligere, allerede etablert gren. Dette valget skapte en viss misnøye blant de som foretrekker at filsystemet som dataene deres hviler på utelukkende er basert på endelige versjoner.
Tvilen dreide seg om holdbarheten til denne avgjørelsen: hvis noen installerer FreeBSD 15.0 med OpenZFS 2.4.0-RC4 og deretter ikke følger -CURRENT-grenen, er det en bekymring for å bli "fastlåst" i flere måneder med en utgivelseskandidat inntil en mindre revisjon eller et nytt punkt i serien kommer. Det var også bekymring for at fremtidige utgivelser som 15.1 ville integrere en annen RC (for eksempel en hypotetisk 2.4.1-RC3) i stedet for en endelig versjon.
Bak denne debatten ligger det ulike måter å forstå hva «Release Candidate"I en så sensitiv kontekst som et filsystem. For noen er en Release Candidate (RC) praktisk talt en stabil versjon, som bare trenger mindre justeringer. For andre er det imidlertid kode som ikke bør brukes som grunnlag for et system merket som RELEASE, og som bør reserveres for de som følger utviklingsgrener nøye."
Uansett oppfylte RC-ene sitt oppdrag med å testplassDisse forbedringene muliggjorde deteksjon av feil, justeringer av detaljer og en mye tryggere ankomst til den "stabile 2.4"-utgivelsen. De som prioriterer sikkerhet fremfor alt annet, har fortsatt muligheten til å forbli på tidligere grener som 2.3.x inntil de anser 2.4 som tilstrekkelig moden i produksjon.
Alt OpenZFS 2.4 bringer er basert på robustheten som prosjektet har oppnådd med 2.3-serien og vedlikeholdsoppdateringene, og kombinerer forbedringer av kjernekompatibilitet, nye verktøy som zfs-omskrivingUtgivelsen inkluderer justeringer av deduplikasjon og blokkkloning, krypteringsoptimaliseringer, interne endringer i gangblokker og ashift, og en rekke nye administrasjonsalternativer. Selv om det har oppstått noe kontrovers angående bruken av utgivelseskandidater på visse operativsystemer, tilbyr den stabile versjonen 2.4 et betydelig sprang fremover for de som ønsker å få mer ut av ZFS på Linux og FreeBSD uten å ofre de etablerte integritets- og robusthetsgarantiene.
