Kapag may inilabas na bagong bersyon ng OpenZFS, maraming administrador ang nagtataka kung sulit ba itong i-update ngayon o hintayin na lang na humupa ang problema. OpenZFS 2.4 Mas interesante pa ang tanong, dahil Ito ay may kasamang malalim na pagbabago sa pagganap, mga bagong kagamitan sa pamamahala, at ilang debate sa komunidad tungkol sa paggamit ng mga release candidate sa mga sistema ng produksyon.
Pangkalahatang mga tampok ng OpenZFS 2.4
Ang OpenZFS 2.4 ay iniharap bilang isang bersyon ng matatag at medyo ambisyosong karakter Dinisenyo para sa parehong Linux at FreeBSD na kapaligiran, ang proyekto, sa panahon ng huling paglalagay ng label nito, ay binigyang-diin na ang layunin ay patuloy na isulong ang kapanahunan ng file system at volume manager habang pinapanatili ang pagiging tugma sa mga kamakailang kernel at tinitiyak ang seguridad ng data.
Pinagsasama-sama ng bersyong ito ang maraming tampok na binuo simula noong drama 2.3 at ang mga intermediate revisions nito: mga pagpapabuti sa pagganap sa patong ng pag-encryptmga bagong kagamitan sa pamamahala tulad ng sumulat muli ng zfsMas nababaluktot na mga kakayahan sa quota, at mga panloob na pagbabago na idinisenyo upang mabawasan ang fragmentation, ma-optimize ang deduplication, at pinuhin ang mga kumplikadong aspeto tulad ng pamamahala ng gang block o pag-uugali sa mga problematikong disk.
Nagbigay din ng espesyal na atensyon ang komunidad sa integrasyon sa mga modernong kernelSa Linux, ang suporta ay idinedeklara mula 4.18 hanggang sa mga kamakailang sangay ng LTS (kabilang ang kernel 6.18 sa panahon ng matatag na paglabas ng 2.4), habang sa FreeBSD, ang mga bersyon mula 13.3 pataas ay sakop, kabilang ang 14.0 at mga mas bagong sangay na inihahanda tulad ng 15.0.
Suporta sa platform at pagiging tugma ng kernel sa OpenZFS 2.4
Isa sa mga haligi ng OpenZFS 2.4 ay ang malawak na pagiging tugma ng platapormaPara sa maraming administrador, ito ay mahalaga, dahil pinapayagan sila nitong i-upgrade ang mga bersyon ng operating system nang hindi nawawala ang inaasahang mga tampok ng ZFS.
Sa panig ng Linux, ang OpenZFS 2.4 ay nagpapahiwatig ng pagiging tugma sa mga kernel mula bersyon 4.18 hanggang sa serye. 6.18 stableSaklaw nito ang lahat mula sa mga konserbatibong distribusyon ng enterprise hanggang sa mga napapanahong kapaligiran na nananatiling napapanahon sa pinakabagong kernel. Sa pagitan nito ay naroon ang buong saklaw ng mga karaniwang release: mga bersyon ng LTS na ginagamit sa mga server, mga custom na kernel, at mga bersyong pinagtibay ng mga proyekto tulad ng CentOS Stream o katulad nito.
Sa FreeBSD, sinusuportahan ng bagong bersyon ang mula sa FreeBSD 13.3 Mula ngayon, kasama na ang 14.0 at mga mas bagong bersyon na paparating na, tulad ng paparating na 15.0. Tinitiyak ng malawak na hanay na ito na ang parehong mga sistemang nasa produksyon na at ang mga susunod na henerasyong pag-deploy ay maaaring patuloy na gumamit ng OpenZFS nang hindi nangangailangan ng mga kakaibang patch o pasadyang solusyon.
Sa likod ng pagkakatugmang ito ay nakasalalay ang patuloy na pagsisikap na kitang-kita na sa serye. OpenZFS 2.3.xAng mga nakaraang update, tulad ng 2.3.4, pinalawak na suporta sa kernel hanggang 6.16 at pinagsama-samang mga patch na nagsimulang lumitaw sa mga naunang RC. Ang OpenZFS 2.4 ay nagpapatuloy kung saan ito tumigil at sumusulong pa, na naaayon sa mga kamakailang kernel at nagpapabuti ng karanasan para sa mga madalas na nag-a-update ng kanilang base stack.
Mga quota at mga bagong kakayahan sa pamamahala ng espasyo
Kabilang sa mga pinaka-praktikal na bagong tampok para sa administrador ay ang mga pagpapabuti sa sistema ng mga paunang natukoy na quotaIpinakikilala ng OpenZFS 2.4 ang kakayahang magtakda ng mga default na quota para sa mga user, grupo, at proyekto, upang ang pagkonsumo ng espasyo ay makontrol nang mas pantay nang hindi kinakailangang manu-manong i-configure ang bawat kaso.
Ang tungkuling ito ay nagbibigay-daan, halimbawa, sa pagtatakda ng isang pangunahing bayad para sa lahat ng gumagamit na nilikha sa isang partikular na dataset, o upang magtakda ng mga limitasyon ng proyekto na awtomatikong inilalapat kapag ang mga bagong mapagkukunan ay inilaan. Ito ay isang napaka-kapaki-pakinabang na tool sa mga multi-user na kapaligiran, hosting, mga laboratoryo, at anumang senaryo kung saan nais mong maiwasan ang isang hindi pagkapansin na mapuno ang buong pool.
Ang suporta para sa mga default na quota ay hindi pinapalitan ang mga umiiral na partikular na quota, ngunit sa halip ay kinukumpleto ang mga ito. Maaaring tukuyin ng administrator ang isang pandaigdigang pulitika at pagkatapos ay pinuhin ito gamit ang mga eksepsiyon para sa mga partikular na user o grupo na nangangailangan ng mas marami (o mas kaunting) espasyo. Ang lahat ng ito ay pinamamahalaan gamit ang mga karaniwang tool ng ZFS, pinapanatili ang parehong modelo ng ari-arian na pamilyar na.
Direktang I/O, cacheless I/O, at hindi maayos na pag-uugali sa pagsulat
Sa usapin ng pagganap, ang OpenZFS 2.4 ay nagdudulot ng isang lubhang kawili-wiling pagbabago sa pamamahala ng direktang input/outputHanggang ngayon, ang paggamit ng direktang I/O sa ilang mga sitwasyon ay maaaring sumalungat sa write alignment at magresulta sa hindi pinakamainam na mga code path. Ang bagong bersyon ay nagpapakilala ng isang mekanismo upang, kapag ang direktang I/O ay hindi maipatupad nang mainam, isang alternatibong mode ang gamitin. magaan na walang cache na IO partikular na idinisenyo para sa ganitong uri ng senaryo.
Ano ang ibig sabihin nito sa pagsasagawa? Na ang mga sulating hindi akma sa inaasahang pagkakahanay ay hindi na isang patolohikong kaso at sa halip ay pinangangasiwaan gamit ang isang na-optimize na ruta sa loob ng ZFS. Nababawasan ang overhead, naiiwasan ang ilang bottleneck, at nakakamit ang mas mahuhulaang pag-uugali, lalo na sa mga kapaligiran kung saan ang mga aplikasyon na gumagamit ng direktang I/O ay magkakasamang nabubuhay kasama ng iba na hindi.
Ang pagbabagong ito ay lalong kapaki-pakinabang sa mga mabibigat na workload kung saan ang layunin ay pasiglahin ang pagganap imbakan nang hindi isinasakripisyo ang mga garantiya ng integridad na inaalok ng ZFS. Gamit ang isang partikular na idinisenyong fallback, ang OpenZFS ay mas angkop sa mga katotohanan ng maraming aplikasyon na hindi palaging sumusunod sa mainam na pagkakahanay ng mga operasyon.
Pinag-isang throttling ng alokasyon at pagbabawas ng fragmentation sa OpenZFS 2.4
Isa pang malaking pagbabago na kaakibat ng OpenZFS 2.4 ay ang pagpapakilala ng isang bagong algorithm para sa pinag-isang pag-aayos ng alokasyonSa likod ng pangalang ito ay nakasalalay ang isang mekanismo na naglalayong bawasan ang pagkakapira-piraso ng mga virtual device (vdev) at mapabuti kung paano ipinamamahagi ang mga write kapag ang sistema ay nasa ilalim ng pressure.
Hanggang ngayon, ang alokasyon ng bloke sa mga sitwasyong may mataas na karga ay maaaring magresulta sa pagbuo ng mga pattern ng distribusyon na, sa paglipas ng panahon, ay pumapabor sa pagkakapira-piraso ng vdevNilalayon ng pinag-isang algorithm na pagtugmain ang rate ng alokasyon, upang mapanatili ng pool ang isang mas maayos na istraktura at mabawasan ang mga parusa sa pagganap kapag nagsisimulang maubusan ng espasyo o kapag ang halo ng mga laki ng bloke ay iba-iba.
Ang mga ganitong uri ng pagbabago ay hindi gaanong kapansin-pansin kumpara sa isang bagong utos, ngunit napakahalaga ng mga ito sa mga pangmatagalang pag-deploy, kung saan lumalaki ang isang pool, binabalanse muli, idinaragdag ang mga bagong virtual development environment (vdev), at isinasagawa ang mga operasyon sa pagpapanatili sa loob ng maraming taon. Sa pamamagitan ng pagpapabuti ng kontrol sa alokasyon, nakakatulong ang OpenZFS 2.4 na mapanatili isang mas matatag na pag-uugali sa paglipas ng panahonkahit na ang sistema ay ginagamit nang masinsinan.
Mga pagpapabuti sa pag-encrypt gamit ang AVX2 at AES-GCM
Sa usapin ng seguridad at pagganap, ang OpenZFS 2.4 ay may kasamang serye ng mga pag-optimize sa paggamit ng AVX2 para sa AES-GCMSa mas simpleng salita: ang implementasyon ng pag-encrypt ay pino upang mas mahusay na masulit ang mga kakayahan ng mga modernong processor na mayroong mga advanced na vector instruction na ito.
Ang resulta ay mas mabilis na pag-encrypt nang hindi isinasakripisyo ang mga garantiyang kriptograpiko, na lalong kapansin-pansin sa mga sistemang humahawak ng malalaking volume ng naka-encrypt na data o sa mga kapaligiran kung saan maraming sabay-sabay na operasyon ang isinasagawa sa mga protektadong dataset. bawasan ang overhead ng CPU kaugnay ng pag-encrypt, mas maraming kahilingan ang maaaring pangasiwaan o mas maraming mapagkukunan ang maaaring ilaan sa iba pang mga gawain ng sistema.
Sa pagsasagawa, ang mga administrador ay maaaring patuloy na umasa sa mga tungkulin ng Pag-encrypt ng katutubong ZFS upang protektahan ang sensitibong datos nang walang malaking epekto sa pagganap ng mga nakaraang henerasyon. Ang pag-encrypt ay hindi nagiging "libre," ngunit nagiging mas madaling pamahalaan ito sa ilalim ng mga workload kung saan dati itong isang malinaw na bottleneck.
ZIL sa mga espesyal na vdev at mga pagpapabuti sa special_small_blocks
Nagdadala rin ang OpenZFS 2.4 ng mga bagong tampok patungkol sa mga espesyal na vdev, ang mga device na idinisenyo upang mag-imbak ng ilang partikular na uri ng data (tulad ng metadata, maliliit na bloke o mga talahanayan ng deduplication) sa mas mabilis na media, karaniwang SSD o NVMe.
Sa isang banda, posible na ngayong pahintulutan ang ZIL (Tala ng Layunin ng ZFS) Gumamit ng mga nakalaang vdev kung mayroon. Ginagawa nitong mas madali ang pagtutuon ng mga synchronous write sa mga low-latency device, na nagpapabuti sa oras ng pagtugon ng mga application na umaasa sa mga operasyong masinsinang mag-sync, tulad ng mga database o mga messaging system na may malakas na persistence.
Sa kabilang banda, ang kilos ng ari-arian ay lumalawak special_small_blocks kaya na Mga sulatin ng ZVOL Maaari rin silang mapunta sa mga espesyal na vdev, hindi lamang sa ilang regular na bloke ng file. Bukod pa rito, niluwagan ang paghihigpit na ang halaga ay dapat na power of two, kaya maaaring pumili ang administrator ng mas pinong mga sukat na iniayon sa kanilang aktwal na workload sa halip na limitado sa mga mahigpit na opsyon.
Kapag pinagsama, ang mga pagpapabuting ito ay nagbibigay-daan para sa disenyo ng mga arkitektura ng imbakan kung saan ang pinakamahalagang datos (Metadata, maliliit na bloke, ZIL, deduplication table, atbp.) ay nakaimbak sa mas mabilis na media, habang ang karamihan ng data ay nananatili sa mas murang mga disk. Ang lahat ng ito ay may kasamang mas malawak na kakayahang umangkop sa pagtukoy kung ano ang itinuturing na "maliit" at kung ano ang hindi.
zfs rewrite at zfs rewrite -P: mahusay na paglilipat ng data
Ang seryeng 2.3 ay nagdala na ng isa sa mga pinakakapansin-pansing tampok nitong mga nakaraang panahon: ang subcommand sumulat muli ng zfsMas pinalalawak pa ng OpenZFS 2.4 ang tool na ito sa pamamagitan ng pagsasama ng variant zfs rewrite -Pna nagdaragdag ng mga bagong posibilidad kapag inililipat ang data sa loob ng isang pool.
Ang utos zfs rewrite nagpapahintulot "upang muling isulat"Ang nilalaman ng isang file o dataset ay kinokopya nang hindi binabago ang lohikal na kahulugan nito, ngunit pisikal na inililipat sa ibang mga lugar na may iba't ibang panloob na katangian. Pinapayagan nito ang mga pagbabago tulad ng algorithm ng compression, uri ng checksum, kung ilalapat ang deduplication, ang bilang ng mga kopya, o kahit ang ginustong device, nang hindi kinakailangang kopyahin ang data sa espasyo ng user at isulat muli ito."
Ito ay may ilang malinaw na bentahe: binabawasan nito ang trapiko ng I/O kumpara sa klasikong pamamaraan ng "kopyahin at palitan ang pangalan", binabawasan ang epekto sa cache, at iniiwasan ang mahahabang panahon kung saan ang data ay inililipat sa pamamagitan ng mga panlabas na tool. Bukod pa rito, dahil walang lohikal na pagbabago sa nilalaman, Hindi nagbabago ang oras ni iba pang mga katangiang nakikita mula sa pananaw ng gumagamit, na nangangahulugang maraming aplikasyon ang hindi man lang alam ang operasyon nito.
Ang pagpipilian zfs rewrite -P nagdaragdag ng posibilidad ng panatilihin ang lohikal na oras ng kapanganakan ng mga bloke hangga't maaari, na nakakatulong na mabawasan ang laki ng mga unti-unting daloy ng replikasyon. Sa pamamagitan ng pagpapanatiling matatag ng impormasyong ito, mas matutukoy ng mga kasunod na operasyon ng pagpapadala/pagtanggap kung ano ang talagang nagbago at kung ano ang hindi, na binabawasan ang dami ng data na kailangang ilipat sa pagitan ng mga sistema.
Ang isa pang mahalagang bentahe ay ang proseso ng muling pagsulat ay protektado ng mga kandado ng saklaw normal, kaya maaari itong tumakbo nang sabay-sabay sa mga totoong workload nang hindi labis na hinaharangan ang sistema. Sa mga dataset na may sync=always Mas malaki pa ang benepisyo, dahil sa kawalan ng anumang lohikal na pagbabago sa datos, walang karagdagang pagsusulat ang napipilitan sa ZIL, na nakakaiwas sa karagdagang gastos sa mga sabaysabay na operasyon.
Mga bagong opsyon sa pamamahala sa OpenZFS 2.4: -a|–all, range scrub, at BRT prefetch
Pinupino at pinalalawak din ng OpenZFS 2.4 ang arsenal ng mga tool sa pamamahala gamit ang ilang kapaki-pakinabang na opsyon para sa pang-araw-araw na paggamit. Isa na rito ang pagdaragdag ng opsyon -a|–lahat sa mga utos na nagsasagawa ng mga gawain sa pagpapanatili sa mga pool, tulad ng scrub, trim, o initialization.
Ginagawang posible ng opsyong ito ang paglulunsad ng isang operasyon na nakakaapekto lahat ng imported na pool nang sabay-sabay, sa halip na manu-manong ulitin ang bawat isa. Lubos nitong pinapasimple ang mga bagay sa mga server na namamahala ng maraming pool, binabawasan ang pagkakamali ng tao at pinapadali ang automation.
Bukod pa rito, ang posibilidad ng paglulunsad ng isang zpool scrub limitado sa mga tiyak na saklaw ng oras sa pamamagitan ng mga opsyon -S -ELubos na pinahahalagahan ang functionality na ito kapag gusto mo lamang suriin ang isang yugto ng panahon kung saan pinaghihinalaan ang mga problema, o kapag gusto mong hatiin ang gastos ng isang scrub sa ilang bahagyang pagpapatupad upang hindi masyadong makaapekto sa pangkalahatang pagganap.
Isa pang mahalagang bagong tampok ay ang pagdaragdag ng zpool prefetch -t brt para mag-preload sa memorya ang Talahanayan ng Sanggunian ng Bloke (talahanayan ng pag-clone ng bloke)Nagbibigay-daan ito para sa mas mahusay na paggamit ng functionality ng block cloning na ipinakilala sa mga nakaraang bersyon, na binabawasan ang latency kapag ina-access ang mga panloob na istrukturang kasangkot sa feature na ito.
Mga pahintulot, mga tool na pinalitan ng pangalan, at mga pagpapabuti sa pag-de-dep at pag-clone ng block
Kabilang sa maliliit ngunit makabuluhang mga pagpapabuti na nagpapaganda sa karanasan, ang OpenZFS 2.4 ay nagdagdag ng isang bagong pahintulot ipadala:naka-encryptDinisenyo upang magbigay ng mas detalyadong kontrol sa kung sino ang maaaring magpadala ng naka-encrypt na data, mahusay itong gumagana sa mga pangkat na may paghihiwalay ng mga responsibilidad sa pagitan ng mga namamahala ng mga snapshot, mga humahawak ng replikasyon, at mga may access sa mga encryption key.
Pinalitan din ng pangalan ang mga tradisyunal na kagamitan, tulad ng arc_summary y arcstat, na kalaunan ay makikilala zarcsummary y zarcstatNakakatulong ang pagbabagong ito na maiwasan ang mga salungatan sa pangalan at nililinaw nito na ang mga ito ay mga tool na nauugnay sa ZFS, na kapaki-pakinabang sa mga system na may maraming bahagi na naglalantad ng magkakatulad na mga utos.
Sa loob, naiipon ang seryeng 2.4 Mga bagong pag-optimize at pag-aayos Ito ay naaangkop sa parehong deduplication at block cloning. Pinoproseso ang mga istruktura ng datos, itinatama ang mga edge case, at hinahangad ang mas mahusay na mga pattern ng pag-access upang gawing mas madaling pamahalaan ang epekto sa memorya at CPU. Ang mga pagbabagong ito ay hindi direktang nakikita ng gumagamit, ngunit nagreresulta ito sa mas matatag na pag-uugali at mas kaunting mga sorpresa sa ilalim ng mga kumplikadong workload.
Mga pagharang sa gang, ashift, mabagal na child vdev, at mga espesyal na topolohiya
Isinasama rin ng OpenZFS 2.4 ang isang hanay ng mga pagpapabuti at pag-aayos sa mga bloke ng gangIto ay isang panloob na tampok ng sistema na idinisenyo upang pangasiwaan ang mga bloke na hindi maaaring ilagay sa karaniwang paraan. Bagama't karamihan sa mga gumagamit ay hindi direktang nakikipag-ugnayan sa mga ito, ang anumang pagkabigo sa bahaging ito ng code ay maaaring magkaroon ng malubhang kahihinatnan, kaya ang maraming pag-aayos at pag-optimize na kasama ay magandang balita para sa pangkalahatang katatagan ng sistema.
Kasabay nito, ang paghawak ng ashiftAng parameter na tumutukoy sa minimum allocation unit na nakahanay sa pisikal na laki ng mga sektor ng device. Ang mas mahusay na pamamahala ng shift ay nakakabawas sa posibilidad ng pagsusulat ng mas maraming data kaysa sa kinakailangan sa mga disk na may malalaking sektor at nakakatulong na mapanatili ang katanggap-tanggap na mga antas ng pagganap sa buong lifespan ng pool.
Isa pang kawili-wiling bagong tampok ay ang kakayahang gawing maayos ang paggana ng mga batang vdev. abnormal na mabagal Maaari silang pansamantalang "ilagay sa bangko." Sa halip na pabagalin ang pagganap ng buong sistema, maaari silang alisin sa pagkakabit nang ilang sandali, na lubhang kapaki-pakinabang kapag ang mga disk ay nagsisimulang masira, ang mga drive ay nakakaranas ng mga paulit-ulit na problema, o ang mga kapaligiran ay may hindi pare-parehong hardware.
Sa wakas, mayroon na sila mga nakarelaks na limitasyon sa topolohiya Sa mga espesyal at deduplication na VDEV, nagbibigay-daan ito para sa mas malawak na kakayahang umangkop kapag nagdidisenyo ng mga pool na may mga advanced na configuration. Nagbibigay-daan ito sa mas mahusay na integrasyon ng mga mabibilis na device para sa metadata, mga deduplicated na table, ZIL, at iba pang sensitibong elemento nang hindi nakakaranas ng masyadong mahigpit na mga limitasyon sa kahulugan ng layout.
OpenZFS 2.3.4: Pagpapanatili, paunang pagsulat muli ng zfs at pagsasama-sama
Upang lubos na maunawaan ang hakbang na kinakatawan ng 2.4, mahalagang suriin natin ito nang mabilis. OpenZFS 2.3.4, isang bersyong pangmaintenance na lumabas ilang sandali bago nito at naglatag ng ilan sa mga pundasyon para sa kung ano ang kalaunan ay pinagsama-sama sa bagong pangunahing sangay.
Dumating ang Bersyon 2.3.4 dalawang buwan pagkatapos ng 2.3.3 na may matinding pokus sa katatagan at pagiging tugmaPinalawak nito ang suporta sa Linux kernel hanggang bersyon 6.16, pinanatili ang minimum sa 4.18, at kinumpirma ang pagiging tugma sa FreeBSD mula bersyon 13.3 pataas, kabilang ang paparating na 15.0. Sa madaling salita, inihahanda na nito ang pundasyon para sa pakikisama sa mga modernong base system nang hindi isinasakripisyo ang katatagan.
Ang partikular na pagsusuring ito ang nagpakilala sa unang bersyon ng utos zfs rewritedinisenyo nang eksakto para sa ilipat ang datos nang hindi binabago ang lohikal na nilalaman nito at nang hindi gumagamit ng mas masalimuot na mga estratehiya tulad ng pagkopya/pagpapalit ng pangalan o pagpapadala/pagtanggap gamit ang pagpapalit ng pangalan ng dataset. Ang layunin ay mag-alok ng isang tool na may kakayahang muling balansehin ang isang pool pagkatapos magdagdag ng mga vdev, pagbabawas ng pagkapira-piraso ng mga random na nakasulat na file, o paglalapat ng mga bagong katangian ng imbakan sa mga umiiral na data.
Kung ikukumpara sa mga tradisyonal na alternatibo, zfs rewrite Mas mabilis ito dahil naiiwasan nito ang paglalakbay ng datos papunta sa espasyo ng gumagamit. Sa mga dataset na may sync=alwaysBukod pa rito, pinapabuti nito ang performance dahil, dahil ang data ay hindi binabago nang lohikal, walang karagdagang pagsusulat ang nati-trigger sa ZIL. Lahat ng ito ay ginagawa nang walang anumang bagay na naaapektuhan. mtime o iba pang metadata nakikita ng mga application, na nagpapaliit sa epekto sa software na tumatakbo sa ibabaw nito.
Nagbigay din ang Bersyon 2.3.4 ng iba't ibang Mga setting na partikular sa FreeBSDKasama rito ang mga pagpapabuti sa packaging at isang hanay ng mga maliliit na pag-aayos na nagpakinis sa ilang bahagi ng code. Hindi ito isang bersyon na nilayong magpakilala ng mga nakakagambalang pagbabago, kundi upang pinuhin ang katatagan bago lumipat sa branch 2.4 na may mas malaking pakete ng mga bagong tampok.
OpenZFS 2.4 RC1, RC2, RC4: pagsubok, feedback, at talakayan sa komunidad
Bago idineklarang matatag ang seryeng 2.4, naglabas ang proyekto ng ilan bitawan ang mga kandidato (RC1, RC2, RC4) na may layuning pahintulutan ang mga advanced na user at developer na subukan ang mga ito at iulat ang mga problema. Kasama na sa mga kandidatong ito ng release ang halos lahat ng feature na ating tinalakay: mga default na quota, cacheless I/O bilang fallback, pinag-isang allocation throttling, mga pagpapabuti sa encryption, ZIL sa mga special vdev, mga extension ng special_small_blocks, mga bagong pahintulot, pagpapalit ng pangalan ng tool, at marami pang iba.
Binigyang-diin ng mga tala ng RC1 at RC2 ang kahalagahan ng komunidad Susubukan ko ang mga build at magpadala ng feedback sa pamamagitan ng GitHub, kabilang ang mga command para madaling ilista ang mga pagbabago kaugnay ng reference branch (na may mga kumbinasyon ng git cherry (paghahambing ng zfs-2.3-release sa iba't ibang RC). Malinaw ang mensahe: ang layunin ay subukan ang code sa mga totoong kapaligiran bago ito lagyan ng label na "stable".
Gayunpaman, ang paglitaw ng isang partikular na RC (halimbawa, 2.4.0-RC4Ang pagsasama ng isang .NET Framework (RF) sa isang bersyon ng FreeBSD na minarkahan bilang RELEASE, tulad ng 15.0, ay nagdulot ng matinding pagtataka sa ilan. Nagtaka ang ilang gumagamit kung bakit napagpasyahan na magsama ng isa. Kandidato sa paglabas ng OpenZFS sa isang bersyong itinuturing na stable ng operating system sa halip na bumaling sa isang nauna at naitatag nang sangay. Ang pagpiling ito ay nagdulot ng ilang kawalang-kasiyahan sa mga mas gustong ang file system kung saan nakabatay ang kanilang data ay nakabatay lamang sa mga pinal na bersyon.
Ang mga pagdududa ay umiikot sa tibay ng desisyong iyon: kung may mag-i-install ng FreeBSD 15.0 gamit ang OpenZFS 2.4.0-RC4 at pagkatapos ay hindi susundin ang branch na -CURRENT, may pangamba na "ma-stuck" nang ilang buwan sa isang release candidate hanggang sa dumating ang isang maliit na rebisyon o isang bagong punto sa serye. Mayroon ding pangamba na ang mga susunod na release tulad ng 15.1 ay magsasama ng isa pang RC (halimbawa, isang hipotetikal na 2.4.1-RC3) sa halip na isang pinal na bersyon.
Sa likod ng debateng ito, may iba't ibang paraan ng pag-unawa sa kung ano ang "bitawan ang kandidato"Sa kontekstong kasingsensitibo ng isang file system. Para sa ilang tao, ang isang Release Candidate (RC) ay halos isang matatag na bersyon, na nangangailangan lamang ng maliliit na pagbabago. Gayunpaman, para sa iba, ito ay isang code na hindi dapat gamitin bilang pundasyon ng isang sistemang minarkahan bilang RELEASE at dapat na nakalaan para sa mga malapit na sumusunod sa mga sangay ng pag-unlad."
Sa anumang kaso, natupad ng mga RC ang kanilang misyon na lugar ng pagsubokAng mga pagpapabuting ito ay nagbigay-daan para sa pagtuklas ng mga bug, pagsasaayos sa mga detalye, at mas kumpiyansang pagdating sa "2.4 stable" na paglabas. Ang mga inuuna ang seguridad higit sa lahat ay mayroon pa ring opsyon na manatili sa mga nakaraang sangay tulad ng 2.3.x hanggang sa maituring nilang sapat na ang 2.4 sa produksyon.
Lahat ng dala ng OpenZFS 2.4 ay batay sa katatagan na nakuha ng proyekto gamit ang seryeng 2.3 at mga update sa pagpapanatili nito, na pinagsasama ang mga pagpapabuti sa compatibility ng kernel, mga bagong tool tulad ng sumulat muli ng zfsKasama sa release ang mga pagsasaayos sa deduplication at block cloning, mga pag-optimize sa encryption, mga panloob na pagbabago sa mga gang block at ashift, at iba't ibang mga bagong opsyon sa pamamahala. Bagama't may ilang kontrobersiya na lumitaw tungkol sa paggamit ng mga release candidate sa ilang partikular na operating system, ang stable na bersyon 2.4 ay nag-aalok ng isang mahalagang hakbang pasulong para sa mga gustong makakuha ng higit pa sa ZFS sa Linux at FreeBSD nang hindi isinasakripisyo ang itinatag na mga garantiya ng integridad at katatagan.
