Ingrandisci / La memoria persistente Optane di Intel è ampiamente considerata la scelta migliore per i dispositivi con buffer di scrittura ZFS. Ma L2ARC è più indulgente di SLOG e anche dispositivi più grandi e più lenti come gli SSD M.2 consumer standard dovrebbero funzionare bene. Oggi, una richiesta di revisione del codice è arrivata alla mailing list degli sviluppatori ZFS. Lo sviluppatore George Amanakis ha portato e rivisto il miglioramento del codice che rende L2ARC, la funzionalità del dispositivo cache di lettura di OpenZFS, persistente durante i riavvii. Amanakis spiega:
Negli ultimi due mesi ho lavorato per far funzionare la persistenza L2ARC in ZFSonLinux.
Questo sforzo si basava sul lavoro precedente di Saso Kiselkov (@skiselkov) su Illumos (https://www.illumos.org/issues/3525), successivamente portato da Yuxuan Shui (@yshui) su ZoL (https:// github.com/zfsonlinux/zfs/pull/2672), successivamente modificato da Jorgen Lundman (@lundman), e ribasato su master con più aggiunte e modifiche da parte mia (@gamanakis).
Il risultato finale è in: https://github.com/zfsonlinux/zfs/pull/9582
Per coloro che non hanno familiarità con i dettagli di ZFS, una delle sue caratteristiche distintive è l’uso dell’algoritmo ARC (Adaptive Replacement Cache) per la cache di lettura. Le cache LRU (Usate meno di recente) del file system standard, utilizzate in NTFS, ext4, XFS, HFS+, APFS e praticamente qualsiasi altra cosa di cui probabilmente hai sentito parlare, elimineranno prontamente blocchi di archiviazione “caldi” (a cui si accede frequentemente) se grandi volumi di i dati vengono letti una volta.
Al contrario, ogni volta che un blocco viene riletto all’interno dell’ARC, diventa più prioritario e più difficile estrarlo dalla cache man mano che vengono letti nuovi dati. L’ARC tiene traccia anche dei blocchi eliminati di recente, quindi se un blocco continua a essere letto di nuovo nella cache dopo lo sfratto, anche questo renderà più difficile lo sfratto. Ciò comporta tassi di accesso alla cache molto più elevati, e quindi latenze inferiori e maggiori velocità effettiva e IOPS disponibili dai dischi effettivi, per la maggior parte dei carichi di lavoro del mondo reale.
Annuncio
L’ARC primario viene mantenuto nella RAM di sistema, ma è possibile creare un dispositivo L2ARC (Layer 2 Adaptive Replacement Cache) da uno o più dischi veloci. In un pool ZFS con uno o più dispositivi L2ARC, quando i blocchi vengono rimossi dall’ARC primario nella RAM, vengono spostati in L2ARC anziché essere eliminati completamente. In passato, questa funzionalità aveva un valore limitato, sia perché l’indicizzazione di un L2ARC di grandi dimensioni occupa la RAM di sistema che avrebbe potuto essere utilizzata meglio per l’ARC primario, sia perché L2ARC non era persistente durante i riavvii.
Il problema dell’indicizzazione L2ARC che consuma troppa RAM di sistema è stato ampiamente mitigato diversi anni fa, quando l’intestazione L2ARC (la parte per ogni record memorizzato nella cache che deve essere archiviato nella RAM) è stata ridotta da 180 byte a 70 byte. Per un L2ARC da 1 TiB, che gestisce solo i set di dati con la dimensione record predefinita di 128 KiB, questo equivale a 640 MiB di RAM consumati per indicizzare L2ARC.
Sebbene il problema del vincolo della RAM sia in gran parte risolto, il valore di un L2ARC grande e veloce era ancora nettamente limitato dalla mancanza di persistenza. Dopo ogni riavvio del sistema (o altra esportazione del pool), L2ARC si svuota. Il codice di Amanakis risolve questo problema, il che significa che molti gigabyte di dati memorizzati nella cache su dispositivi a stato solido veloci saranno ancora disponibili dopo un riavvio del sistema, aumentando così il valore di un dispositivo L2ARC. A prima vista, questo sembra importante soprattutto per i sistemi personali che vengono riavviati spesso, ma significa anche che i server molto più caricati potrebbero potenzialmente aver bisogno di molto meno “babying” mentre riscaldano le loro cache dopo un riavvio.
Questo codice non è ancora stato unito a master, ma Brian Behlendorf, responsabile della piattaforma Linux del progetto OpenZFS, lo ha firmato e sta aspettando un’altra revisione del codice prima di fondersi con master, che dovrebbe avvenire nelle prossime settimane se non emerge nulla di male in un’ulteriore revisione o test iniziale.
