Sono stati proposti miglioramenti a Btrfs da includere nel kernel Linux 6.2 per risolvere il problema del buco di scrittura nell'implementazione RAID 5/6. L'essenza del problema è che se si verifica un crash durante la registrazione, inizialmente è impossibile capire su quale blocco, su quale dispositivo RAID, è stato scritto correttamente e in quale la registrazione non è stata completata. Se si tenta di ripristinare un RAID in questa situazione, i blocchi corrispondenti ai blocchi sottoscritti potrebbero essere distrutti perché lo stato dei blocchi RAID non è sincronizzato. Questo problema si verifica in qualsiasi array RAID1/5/6 in cui non sono state adottate misure speciali per combattere questo effetto.
In un'implementazione RAID, come RAID1 in btrfs, questo problema viene risolto utilizzando i checksum in entrambe le copie; se c'è una mancata corrispondenza, i dati vengono semplicemente ripristinati dalla seconda copia. Questo approccio funziona anche se qualche dispositivo inizia a inviare dati errati invece che in caso di guasto completo.
Tuttavia, nel caso di RAID5/6, il file system non memorizza i checksum per i blocchi di parità: in una situazione normale, la validità dei blocchi è verificata dal fatto che sono tutti checksum, e il blocco di parità può essere ricostruito dai dati. Tuttavia, in caso di registrazione parziale, questo approccio potrebbe non funzionare in determinate situazioni. In questo caso, durante il ripristino di un array, è possibile che i blocchi che rientrano in un record incompleto vengano ripristinati in modo errato.
Nel caso di btrfs, questo problema è particolarmente rilevante se il record prodotto è più piccolo dello stripe. In questo caso, il file system deve eseguire un'operazione di lettura-modifica-scrittura (lettura-modifica-scrittura, RMW). Se si incontrano blocchi con scrittura incompleta, l'operazione RMW potrebbe causare danni che non verranno rilevati, indipendentemente dai checksum. Gli sviluppatori hanno apportato modifiche in cui l'operazione RMW controlla il checksum dei blocchi prima di eseguire questa operazione e, se è necessario ripristinare i dati, controlla anche i checksum dopo la registrazione. Sfortunatamente, in una situazione in cui si scrive una striscia incompleta (RMW), ciò comporta un sovraccarico aggiuntivo per il calcolo dei checksum, ma aumenta significativamente l'affidabilità. Per RAID6 tale logica non è ancora pronta, tuttavia, per un tale errore in RAID6 è necessario che la scrittura fallisca su 2 dispositivi contemporaneamente, il che è meno probabile.
Inoltre, possiamo notare le raccomandazioni per l'utilizzo di RAID5/6 da parte degli sviluppatori, la cui essenza è che in Btrfs i metadati e il profilo di archiviazione dei dati potrebbero differire. In questo caso è possibile utilizzare il profilo RAID1 (mirror) o anche RAID1C3 (3 copie) per i metadati e RAID5 o RAID6 per i dati. Ciò garantisce da un lato una protezione affidabile dei metadati e l'assenza di un "buco di scrittura" e dall'altro un utilizzo più efficiente dello spazio, caratteristico di RAID5/6. Ciò consente di evitare la corruzione dei metadati e di correggere la corruzione dei dati.
Si noti inoltre che per gli SSD in Btrfs nel kernel 6.2, l'esecuzione asincrona dell'operazione di “discard” sarà attivata per impostazione predefinita (contrassegnando i blocchi liberati che non necessitano più di essere archiviati fisicamente). Il vantaggio di questa modalità è l'elevata prestazione dovuta all'efficace raggruppamento delle operazioni di "scarto" in una coda e all'ulteriore elaborazione della coda da parte di un processore in background, motivo per cui le normali operazioni FS non rallentano, come nel caso della modalità sincrona " scartare" man mano che i blocchi vengono liberati e l'SSD può prendere decisioni migliori. D'altra parte, non avrai più bisogno di utilizzare utilità come fstrim, poiché tutti i blocchi disponibili verranno cancellati nell'FS senza bisogno di scansioni aggiuntive e senza rallentare le operazioni.
Fonte: opennet.ru