Per attivare il kernel Linux 6.2, sono state proposte delle migliorie a Btrfs riguardanti la risoluzione del problema del "write hole" nella realizzazione di RAID 5/6. La questione principale è che, se si verifica un crash durante la scrittura, inizialmente non è possibile determinare quale blocco su quale dei dispositivi RAID sia stato registrato correttamente e quale scrittura non sia stata completata. Tentando di ripristinare il RAID in una situazione simile, può avvenire la corruzione dei blocchi corrispondenti a blocchi non registrati, poiché lo stato dei blocchi RAID è desincronizzato. Questo problema si presenta in qualsiasi array RAID1/5/6 dove non sono state adottate misure specifiche per affrontare tale effetto.
Nella realizzazione di RAID, come RAID1 in btrfs, questo problema viene risolto utilizzando checksum in entrambe le copie; in caso di incoerenza, i dati vengono semplicemente ripristinati dalla seconda copia. Questo approccio funziona anche se uno dei dispositivi inizia a restituire dati errati anziché fallire completamente.
Tuttavia, nel caso di RAID5/6, il file system non memorizza checksum per i blocchi di parità: in condizioni normali, la correttezza dei blocchi viene verificata dal fatto che tutti sono dotati di checksum e il blocco di parità può essere ricreato dai dati. Tuttavia, in caso di scrittura parziale, questo approccio potrebbe non funzionare in determinate situazioni. In tal caso, durante il ripristino dell'array, non si può escludere che i blocchi soggetti a registrazioni incomplete possano essere ripristinati in modo errato.
Nel caso di btrfs, questo problema è particolarmente rilevante se la scrittura effettuata è inferiore alla dimensione dello striping. In questo caso, il file system deve eseguire l'operazione di lettura-modifica-scrittura (read-modify-write, RMW). Se si incontrano blocchi con scritture incomplete, l'operazione RMW può causare danni che non saranno rilevati, nonostante i checksum. Gli sviluppatori hanno apportato modifiche affinché l'operazione RMW controlli i checksum dei blocchi prima di eseguire questa operazione e, se necessario per il recupero dei dati, esegue anche il controllo dei checksum dopo la scrittura. Purtroppo, nel caso della scrittura di uno strip incompleto (RMW), questo porta a costi aggiuntivi per il calcolo dei checksum, ma aumenta notevolmente l'affidabilità. Per RAID6, questa logica non è ancora pronta, ma per tale guasto in RAID6 è necessario che la scrittura fallisca su due dispositivi contemporaneamente, il che è meno probabile.
In aggiunta, si possono notare le raccomandazioni degli sviluppatori sull'uso di RAID5/6, che si riassumono nel fatto che in Btrfs il profilo di archiviazione dei metadati e dei dati può differire. In questo caso, è possibile utilizzare un profilo RAID1 (mirroring) o addirittura RAID1C3 (3 copie) per i metadati, mentre per i dati si possono utilizzare RAID5 o RAID6. Ciò garantisce una protezione affidabile dei metadati e l'assenza di "write hole" da un lato, e un utilizzo più efficiente dello spazio, tipico di RAID5/6, dall'altro. Questo consente di evitare danni ai metadati, mentre i danneggiamenti dei dati possono essere corretti.
Si può anche notare che per SSD in Btrfs nel kernel 6.2 l'esecuzione asincrona dell'operazione "discard" (marcatura dei blocchi liberati che possono già essere fisicamente rimossi) sarà attivata di default. Il vantaggio di questo regime è l'alta prestazione grazie all'efficace raggruppamento delle operazioni "discard" in coda e al successivo trattamento della coda da parte di un elaboratore in background, il che impedisce che le normali operazioni del file system vengano rallentate, come avviene con il "discard" sincronizzato man mano che i blocchi vengono liberati, e consente agli SSD di prendere decisioni più efficaci. D'altra parte, non sarà più necessario utilizzare strumenti come fstrim, poiché tutti i blocchi disponibili saranno puliti nel file system senza necessità di scansioni aggiuntive e senza rallentamenti delle operazioni.
Fonte: opennet.ru
