Kernel Linux
È stato recentemente rivelato che sono stati proposti miglioramenti a Btrfs per l'inclusione nel kernel Linux 6.2 per risolvere il problema del buco di scrittura nell'implementazione RAID 5/6.
L'essenza del problema si riduce al fatto che se si verifica un arresto anomalo durante la registrazione, inizialmente è impossibile capire quale blocco su quale dei dispositivi RAID sia stato scritto correttamente e su quale la registrazione non sia stata completata.
Se si tenta di ricostruire un RAID in questa situazione, i blocchi corrispondenti ai blocchi sottoscritti potrebbero danneggiarsi perché lo stato dei blocchi RAID non è sincronizzato. Questo problema si verifica in qualsiasi array RAID1/5/6 in cui non vengono prese misure speciali per combattere questo effetto.
In un'implementazione RAID come RAID1 in btrfs, questo problema è risolto utilizzando checksum su entrambe le copie, se c'è una mancata corrispondenza, i dati vengono semplicemente ripristinati dalla seconda copia. Questo approccio funziona anche se un dispositivo inizia a fornire dati errati invece di fallire completamente.
Tuttavia, nel caso di RAID5/6, il file system non memorizza i checksum per i blocchi di parità - in una situazione normale, la correttezza dei blocchi è verificata dal fatto che sono tutti dotati di un checksum e il blocco di parità può essere ricreato dai dati. Tuttavia, in caso di registrazione parziale, questo approccio potrebbe non funzionare in determinate situazioni. In questo caso, quando si ripristina l'array, è possibile che i blocchi lasciati nel record incompleto vengono ripristinati in modo errato.
Nel caso di btrfs, questo problema è più rilevante se la scrittura che si verifica è più piccola della striscia. In questo caso, il file system deve eseguire un'operazione di lettura-modifica-scrittura (RMW).
Se incontra blocchi di scrittura in corso, l'operazione RMW può causare un danneggiamento che non verrà rilevato, indipendentemente dai checksum. Gli sviluppatori hanno apportato modifiche in cui l'operazione RMW verifica il checksum dei blocchi prima di eseguire questa operazione e, se necessario, il ripristino dei dati esegue anche una verifica del checksum dopo la scrittura.
Sfortunatamente, in una situazione in cui viene scritta una frangia incompleta (RMW), questo crea un sovraccarico aggiuntivo per calcolare i checksum, ma aumenta significativamente l'affidabilità. Per RAID6, tale logica non è ancora pronta,
Inoltre, possiamo notare le raccomandazioni sull'uso di RAID5/6 da parte degli sviluppatori, la cui essenza è che in Btrfs il profilo per l'archiviazione di metadati e dati potrebbe differire. In questo caso, puoi 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 uso più efficiente dello spazio, tipico di RAID5/6. Ciò impedisce il danneggiamento dei metadati e il danneggiamento dei dati può essere corretto.
anche Si può notare che per gli SSD su Btrfs nel kernel 6.2, la esecuzione asincrona dell'operazione "discard". (contrassegna i blocchi liberati che non possono più essere archiviati fisicamente) sarà attivo per impostazione predefinita.
La ventata di este la modalità è ad alte prestazioni grazie al raggruppamento efficiente delle operazioni di scarto in una coda e alla post-elaborazione della coda da parte di un gestore in background, quindi le normali operazioni di FS non vengono rallentate come nel caso dello "scarto" sincrono man mano che i blocchi vengono liberati e l'SSD può migliorare decisioni. D'altra parte, non sarà più necessario utilizzare utilità come fstrim, poiché tutti i blocchi disponibili verranno cancellati in FS senza la necessità di scansioni aggiuntive e senza rallentare le operazioni.
Infine, se sei interessato a poterne saperne di più, puoi consultare i dettagli in il seguente collegamento.