Propóñense melloras de Btrfs para incluír no núcleo de Linux 6.2 para solucionar o problema do "buraco de escritura" na implementación de RAID 5/6. A esencia do problema redúcese no feito de que se se produciu un fallo durante a gravación, inicialmente é imposible entender que bloque en cal dos dispositivos RAID se escribiu correctamente e en que non se completou a gravación. Se tenta reconstruír un RAID nesta situación, os bloques correspondentes aos bloques subscritos poden estar danados porque o estado dos bloques RAID non está sincronizado. Este problema ocorre en calquera matriz RAID1/5/6 onde non se toman medidas especiais para combater este efecto.
Nunha implementación RAID, como RAID1 en btrfs, este problema resólvese usando sumas de comprobación en ambas as copias, se hai un desajuste, os datos simplemente restaúranse desde a segunda copia. Este enfoque tamén funciona se algún dispositivo comeza a proporcionar datos incorrectos en lugar de producir un fallo completo.
Non obstante, no caso de RAID5/6, o sistema de ficheiros non almacena sumas de verificación para bloques de paridade: nunha situación normal, a corrección dos bloques compróbase polo feito de que todos están equipados cunha suma de verificación e o bloque de paridade pode recrearse a partir dos datos. Non obstante, no caso dunha gravación parcial, este enfoque pode non funcionar en determinadas situacións. Neste caso, ao restaurar a matriz, é posible que os bloques que quedaron no rexistro incompleto se restauren incorrectamente.
No caso de btrfs, este problema é máis relevante se a escritura que se produce é máis pequena que a franxa. Neste caso, o sistema de ficheiros debe realizar unha operación de lectura, modificación e escritura (RMW). Se atopa bloques de escritura en curso, a operación RMW pode provocar corrupcións que non se detectarán, independentemente das sumas de comprobación. Os desenvolvedores realizaron cambios nos que a operación RMW verifica a suma de verificación dos bloques antes de realizar esta operación e, se é necesario, a recuperación de datos tamén realiza unha comprobación de suma de verificación despois de escribir. Desafortunadamente, nunha situación na que se escribe unha franxa incompleta (RMW), isto leva a unha sobrecarga adicional para calcular as sumas de verificación, pero aumenta significativamente a fiabilidade. Para RAID6, tal lóxica aínda non está lista, non obstante, para tal fallo en RAID6, é necesario que a escritura falle en 2 dispositivos á vez, o que é menos probable.
Ademais, podemos observar as recomendacións sobre o uso de RAID5/6 dos desenvolvedores, cuxa esencia é que en Btrfs o perfil para almacenar metadatos e datos pode diferir. Neste caso, pode usar o perfil RAID1 (espello) ou incluso RAID1C3 (3 copias) para os metadatos e RAID5 ou RAID6 para os datos. Isto garante unha protección fiable dos metadatos e a ausencia dun "burato de escritura", por unha banda, e un uso máis eficiente do espazo, típico de RAID5/6, por outra. Isto evita a corrupción dos metadatos e pódese corrixir.
Tamén se pode notar que para os SSD en Btrfs no núcleo 6.2, a execución asíncrona da operación "descartar" (marcando bloques liberados que xa non poden almacenarse fisicamente) estará activada por defecto. A vantaxe deste modo é o alto rendemento debido á agrupación eficiente das operacións "descartar" nunha cola e ao procesamento posterior da cola por parte dun manejador en segundo plano, polo que as operacións normais de FS non se ralentizan, como é o caso dos sincrónicos ". descartar" a medida que se liberan os bloques e o SSD pode tomar mellores decisións. Por outra banda, xa non necesitarás usar utilidades como fstrim, xa que todos os bloques dispoñibles borraranse no FS sen necesidade de escanear adicionais e sen ralentizar as operacións.
Fonte: opennet.ru