Linux Kernel
Es va donar a conèixer fa poc que van ser proposades millores de Btrfs per a la seva inclusió al kernel de Linux 6.2 per solucionar el problema del write hole a la implementació de RAID 5/6.
L'essència del problema es redueix al fet que si es produeix un bloqueig durant l'enregistrament, inicialment és impossible entendre quin bloc a quin dels dispositius RAID es va escriure correctament i en quin no es va completar l'enregistrament.
Si intenteu reconstruir un RAID en aquesta situació, els blocs corresponents als blocs subscrits es poden fer malbé perquè l'estat dels blocs RAID no està sincronitzat. Aquest problema passa en qualsevol arranjament RAID1/5/6 on no es prenen mesures especials per combatre aquest efecte.
En una implementació de RAID com RAID1 a btrfs, aquest problema es resol mitjançant l'ús de sumes de verificació a les dues còpies, si hi ha una discrepància, les dades simplement es restauren des de la segona còpia. Aquest enfocament també funciona si algun dispositiu comença a donar dades incorrectes en lloc de fallar del tot.
No obstant això, en el cas de RAID5/6, el sistema de fitxers no emmagatzema sumes de verificació per a blocs de paritat: en una situació normal, la correcció dels blocs es verifica pel fet que tots estan equipats amb una suma de verificació i el bloc de paritat es pot recrear a partir de les dades. Tanmateix, en el cas d'enregistrament parcial, aquest enfocament pot no funcionar en certes situacions. En aquest cas, en restaurar la matriu, és possible que els blocs que van quedar al registre incomplet es restaurin incorrectament.
En cas de btrfs, aquest problema és més rellevant si l'escriptura que es produeix és més petita que la franja. En aquest cas, el sistema de fitxers ha de fer una operació de lectura, modificació i escriptura (RMW).
Si trobeu blocs d'escriptura en curs, l'operació RMW pot causar danys que no es detectaran, independentment de les sumes de verificació. Els desenvolupadors han fet canvis en què l'operació RMW verifica la suma de verificació dels blocs abans de realitzar aquesta operació i, si cal, la recuperació de dades també fa una verificació de suma de verificació després d'escriure.
Malauradament, en una situació en què s'escriu una franja incompleta (RMW), això genera una sobrecàrrega addicional per calcular les sumes de verificació, però augmenta significativament la confiança. Per a RAID6, aquesta lògica encara no està llesta,
A més, podem observar les recomanacions sobre l'ús de RAID5/6 dels desenvolupadors, l'essència dels quals és que a Btrfs el perfil per emmagatzemar metadades i dades pot diferir. En aquest cas, podeu utilitzar el perfil RAID1 (mirall) o fins i tot RAID1C3 (3 còpies) per a metadades, i RAID5 o RAID6 per a dades.
Això garanteix una protecció fiable de les metadades i l'absència d'un «forat d'escriptura», d'una banda, i un ús més eficient de l'espai, típic de RAID5/6, de l'altra. Això evita la corrupció a les metadades i la corrupció de dades es pot corregir.
També es pot assenyalar que per als SSD a Btrfs al nucli 6.2, la execució asíncrona de l'operació «discard» (marcar blocs alliberats que ja no es poden emmagatzemar físicament) estarà activada per defecte.
L'avantatge d'aquest mode és l'alt rendiment a causa de l'agrupació eficient de les operacions de discard en una cua i el processament posterior de la cua per part d'un controlador en segon pla, per la qual cosa les operacions normals de FS no s'alenteixen, com és el cas amb el síncron discard a mesura que s'alliberen blocs, i l'SSD pot prendre millors decisions. D'altra banda, ja no necessitareu utilitzar utilitats com a fstrim, ja que tots els blocs disponibles s'esborraran al FS sense necessitat d'escaneig addicional i sense alentir les operacions.
Finalment si estàs interessat en poder conèixer més a l'respecte, pots consultar els detalls a el següent enllaç.