Un’altra funzionalità pianificata per essere inviata per l’imminente finestra di unione del kernel di Linux 6.5 è l’introduzione del supporto per le primitive di provisioning per lo storage con thin provisioning con il codice Device Mapper (DM).
Un ramo creato durante il fine settimana era dm-6.5-provision-support di linux-dm.git. Con esso ora su un ramo contrassegnato per”6.5″, sembra posizionato per essere inviato per l’imminente finestra di unione di Linux 6.5, escludendo eventuali problemi sollevati da Linus Torvalds o altri sviluppatori del kernel.
Queste primitive di provisioning sono state sviluppate dal team Chrome OS di Google. Sarthak Kukreti di Google ha precedentemente spiegato questa iniziativa nelle precedenti patch RFC sulla mailing list:
“Questa serie di patch è una RFC di un meccanismo per passare attraverso le richieste di provisioning su dispositivi di storage/filesystem con thin provisioning in pila.
Il kernel di Linux fornisce diversi meccanismi per impostare astrazioni di storage a blocchi con thin provisioning ( ad es. dm-thin, dispositivi di loop su file sparsi), direttamente come dispositivi a blocchi o storage di supporto per file system. in tali configurazioni di archiviazione. Considera i seguenti casi d’uso:
1) Sospensione su disco e ripristino da un dispositivo dm-thin: per garantire che i metadati thinpool sottostanti non vengano modificati durante il meccanismo di sospensione, è necessario eseguire il provisioning completo del dispositivo dm-thin.
2) Se un filesystem utilizza un dispositivo loop su un file sparse, fallocate() sul filesystem allocherà i blocchi per i file ma il file sparse sottostante rimarrà intatto.
3) Un altro esempio è una macchina virtuale che utilizza un file sparse/dm-thin come dispositivo di archiviazione; per impostazione predefinita, le allocazioni all’interno dei limiti della VM non influiranno sull’host.
4) Diversi standard di archiviazione supportano meccanismi per il thin provisioning su dispositivi hardware reali. Ad esempio:
a. La sezione 2.1.1 della specifica NVMe 1.0b parla vagamente di thin provisioning:”Quando il bit THINP nel campo NSFEAT della struttura dati di Identity Namespace è impostato su’1′, il controller… deve tenere traccia del numero di blocchi allocati in il campo Utilizzo dello spazio dei nomi”
b. La sezione SCSi Block Commands reference-4 fa riferimento a”Thin provisioning logic units”,
c. La sezione delle specifiche UFS 3.0 13.3.3 fa riferimento a”Thin provisioning”.In tutte le situazioni di cui sopra, attualmente l’unico modo per pre-allocare lo spazio è emettere scritture (o utilizzare WRITE_ZEROES/WRITE_SAME). Tuttavia, ciò non si adatta bene con dimensioni di pre-allocazione maggiori.
Questo patchset introduce le primitive per supportare le richieste di provisioning a livello di blocco (nota: il termine”provisioning”è usato per evitare di sovraccaricare il termine”allocazioni/pre-allocazioni”) attraverso filesystem e dispositivi a blocchi. Ciò consente a fallocate() e alle richieste di creazione di file di riservare spazio su livelli sovrapposti di dispositivi a blocchi e filesystem. Attualmente, il set di patch copre un prototipo sui target device-mapper, loop device ed ext4, ma lo stesso meccanismo può essere esteso ad altri filesystem/dispositivi a blocchi ed esteso per l’uso con i dispositivi in 4 a-c.”
La patch che introduce la richiesta REQ_OP_PROVISION riassume semplicemente questo provisioning come:
“Introduci la richiesta di blocco REQ_OP_PROVISION. Lo scopo di questa richiesta è richiedere all’archiviazione sottostante di preallocare lo spazio su disco per l’intervallo di blocchi specificato. I dispositivi a blocchi che supportano questa funzionalità esporteranno un limite di provisioning all’interno delle loro code di richiesta.
Questa patch aggiunge anche la possibilità di chiamare fallocate() in modalità 0 sui dispositivi a blocchi, che invierà REQ_OP_PROVISION al dispositivo a blocchi per l’intervallo specificato,”
Questa primitiva di provisioning dei blocchi Il lavoro è in lavorazione da diversi mesi ed è stato testato con successo su Chrome OS e rispetto al kernel Linux originale. Le modifiche al blocco e al DM relative a REQ_OP_PROVISION, nonché il relativo supporto del dispositivo di loopback, sono ora pronte a comparire in Linux 6.5.
La finestra di unione di Linux 6.5 dovrebbe iniziare la prossima settimana se la versione stabile di Linux 6.4 non viene posticipata di una settimana in più. Linux 6.5 stabile a sua volta dovrebbe debuttare verso la fine di agosto.
