Vedvarende L2ARC kommer muligvis til ZFS på Linux

L2ARC-funktionens værdi vil stige kraftigt med vedholdenhed på tværs af genstarter.

Intels vedholdende Optane-hukommelse betragtes i vid udstrækning som det bedste valg for ZFS-skrivebuffeenheder. 
Men L2ARC er mere tilgivende end SLOG, og større, langsommere enheder som standardforbruger M.2 SSD’er burde også fungere godt til det.

I dag kom en anmodning om kodegennemgang over ZFS-udviklernes mailingliste. Udvikler George Amanakis har porteret og revideret kodeforbedring, der gør L2ARC — OpenZFSs funktion til læse cache-enhed – vedvarende på tværs af genstarter. Amanakis forklarer:

De sidste par måneder har jeg arbejdet på at få L2ARC-persistens til at arbejde i ZFSonLinux.

Denne indsats var baseret på tidligere arbejde fra Saso Kiselkov (@skiselkov) i Illumos ( https://www.illumos.org/issues/3525 ), som senere blev portet af Yuxuan Shui (@yshui) til ZoL (https: // github.com/zfsonlinux/zfs/pull/2672), senere ændret af Jorgen Lundman (@lundman), og ombaseret til master med flere tilføjelser og ændringer af mig (@gamanakis).

Slutresultatet er i: https://github.com/zfsonlinux/zfs/pull/9582

For dem bekendt med den møtrikker og bolte af ZFS , et af dens kendetegn er brugen af ARC-Adaptive Udskiftning cache- algoritme til læse cache. Standard filsystem LRU (mindst nyligt anvendte) cacher – brugt i NTFS, ext4, XFS, HFS +, APFS og stort set alt andet, du sandsynligvis har hørt om – vil let afvise “varme” (ofte tilgængelige) lagerblokke, hvis store mængder af data læses en gang.

Derimod, hver gang en blok læses igen i ARC, bliver den mere tungt prioriteret og vanskeligere at skubbe ud af cachen, når nye data læses ind. ARC sporer også for nylig udsatte blokke – så hvis en blok bliver ved med at blive læst tilbage  i cache efter udsættelse, også dette vil gøre det vanskeligere at fjerne. Dette fører til meget højere cache-hitrater – og derfor lavere latenstider og mere gennemstrømning og IOPS tilgængelig fra de faktiske diske – for de fleste virkelige arbejdsbelastninger.

Den primære ARC opbevares i system RAM, men en L2ARC — Layer 2 Adaptive Replacement Cache — enhed kan oprettes fra en eller flere hurtige diske. I en ZFS-pool med en eller flere L2ARC-enheder flyttes de, når der blokeres fra den primære ARC i RAM, ned til L2ARC snarere end at blive smidt væk. Tidligere har denne funktion været af begrænset værdi, både fordi indeksering af en stor L2ARC optager system RAM, som kunne have været bedre brugt til primær ARC, og fordi L2ARC ikke var vedvarende på tværs af genstarter.

Spørgsmålet om indeksering af L2ARC, der forbruger for meget system RAM, blev stort set afbødet for flere år siden, da L2ARC-overskriften (delen for hver cache-post, der skal gemmes i RAM) blev reduceret fra 180 byte til 70 byte. For en 1TiB L2ARC, der kun udfører service på datasæt med standardstørrelsen på 128 KB, fungerer dette til 640 MB RAM, der er brugt til at indeksere L2ARC.

Selvom RAM-begrænsningsproblemet stort set er løst, var værdien af ​​en stor, hurtig L2ARC stadig kraftigt begrænset af en mangel på vedholdenhed. Efter hvert systemstart (eller anden eksport af poolen) tømmes L2ARC. Amanakis ‘kode løser det, hvilket betyder, at mange gigabyte data, der er cachelagret på hurtige enheder med fast tilstand, stadig vil være tilgængelige efter en systemstart, hvilket øger værdien af ​​en L2ARC-enhed. Ved første rødme virker dette mest vigtigt for personlige systemer, der ofte genstartes – men det betyder også, at langt mere tungt belastede servere muligvis potentielt har brug for meget mindre “babying”, mens de opvarmer deres cacher efter en genstart.

Denne kode er endnu ikke slået sammen til master, men Brian Behlendorf, Linux-platformleder for OpenZFS-projektet, har logget på den, og den venter på en ny kodegennemgang, før den smelter sammen til master, som forventes at ske et eller andet tidspunkt i de næste par uger hvis intet dårligt kommer op i yderligere gennemgang eller indledende test.