Per il kernel Linux 6.2 sono previsti miglioramenti a Btrfs relativi alla risoluzione del problema del "write hole" nell'implementazione RAID 5/6. Il problema consiste nel fatto che, se si verifica un crash durante la scrittura, non è possibile determinare inizialmente quale blocco sia stato correttamente registrato su quale dispositivo RAID, e quale scrittura non sia stata completata. In caso di tentativo di ripristino del RAID, in una situazione simile, potrebbero verificarsi danni ai blocchi corrispondenti ai blocchi non registrati, poiché lo stato dei blocchi RAID è desincronizzato. Questo problema si verifica in qualsiasi array RAID1/5/6 in cui non vengono adottate misure specifiche per affrontare questo fenomeno.
Nell'implementazione RAID, come RAID1 in btrfs, questo problema viene risolto mediante l'uso di checksum in entrambe le copie; in caso di discrepanza, i dati vengono semplicemente ripristinati dalla seconda copia. Questo approccio funziona anche se un dispositivo inizia a restituire dati non corretti invece di guastarsi completamente.
Tuttavia, nel caso di RAID5/6, il filesystem non memorizza checksum per i blocchi di parità: in una situazione normale, la correttezza dei blocchi è verificata dal fatto che sono tutti 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 circostanze. In questo caso, durante il ripristino dell'array, è possibile che i blocchi soggetti a scrittura incompleta vengano ripristinati in modo errato.
Nel caso di btrfs, questo problema è particolarmente rilevante se la scrittura effettuata è di dimensioni inferiori allo stripe. In questo caso, il filesystem deve eseguire un'operazione di lettura-modifica-scrittura (read-modify-write, RMW). Se durante ciò si incontrano blocchi con scritture incomplete, l'operazione RMW può causare danni che non verranno rilevati, nonostante i checksum. Gli sviluppatori hanno apportato modifiche in modo che l'operazione RMW controlli i checksum dei blocchi prima di eseguire l'operazione stessa e, se necessario, esegua anche un controllo dei checksum dopo la scrittura. Sfortunatamente, nel caso di scrittura di uno stripe incompleto (RMW), ciò comporta un onere aggiuntivo per il calcolo dei checksum, ma aumenta significativamente l'affidabilità. Per RAID6, questa logica non è ancora pronta; tuttavia, per un guasto in RAID6, è necessario che la scrittura non riesca su almeno 2 dispositivi, il che è meno probabile.
Inoltre, è possibile notare le raccomandazioni degli sviluppatori riguardo all'uso di RAID5/6, che sostanzialmente indicano che in Btrfs il profilo di archiviazione dei metadati e dei dati può differire. È possibile utilizzare un profilo RAID1 (mirror) o persino RAID1C3 (3 copie) per i metadati, mentre per i dati si utilizza RAID5 o RAID6. In questo modo si garantisce una protezione affidabile dei metadati e l'assenza del "write hole" da un lato, e un utilizzo più efficiente dello spazio, tipico di RAID5/6, dall'altro. Questo aiuta a evitare danni ai metadati, mentre eventuali danni ai dati possono essere corretti.
È inoltre degno di nota che per SSD in Btrfs, nel kernel 6.2 sarà attivata per default l'esecuzione asincrona dell'operazione di "discard" (marchiatura dei blocchi liberati che non devono più essere fisicamente conservati). Il vantaggio di questa modalità è l'elevata performance grazie all'efficace raggruppamento delle operazioni di "discard" in coda e successivamente all'elaborazione della coda da parte di un processore in background, il che evita che le normali operazioni del filesystem rallentino, come avviene nel caso del "discard" sincrono durante la liberazione dei blocchi, e consente agli SSD di prendere decisioni più ottimali. D'altra parte, non sarà più necessario utilizzare utilità come fstrim, poiché tutti i blocchi disponibili saranno puliti nel filesystem senza necessità di scansione aggiuntiva e senza rallentare le operazioni.
Fonte: opennet.ru
