Para activar el núcleo de Linux 6.2, se proponen mejoras en Btrfs relacionadas con la solución del problema del «write hole» en la implementación RAID 5/6. La esencia del problema radica en que, si ocurre un fallo durante la escritura, inicialmente es impossible determinar qué bloque en cuál de los dispositivos RAID se escribió correctamente y cuál no finalizó la escritura. En caso de intentar recuperar el RAID en tal situación, puede producirse la destrucción de los bloques correspondientes a los bloques no escritos, ya que el estado de los bloques RAID está desincronizado. Este problema surge en cualquier arreglo RAID 1/5/6 donde no se toman medidas especiales para mitigar tal efecto.
En la implementación de RAID, como RAID 1 en btrfs, este problema se resuelve utilizando sumas de verificación en ambas copias; en caso de discrepancia, los datos simplemente se recuperan de la segunda copia. Este enfoque también funciona si algún dispositivo comienza a devolver datos incorrectos en lugar de fallar por completo.
Sin embargo, en el caso de RAID 5/6, el sistema de archivos no almacena sumas de verificación para los bloques de paridad: en condiciones normales, la corrección de los bloques se verifica por el hecho de que todos están provistos de una suma de verificación, y el bloque de paridad se puede recrear a partir de los datos. Sin embargo, en caso de escritura parcial, este enfoque puede no funcionar en ciertas situaciones. En este caso, al recuperar el arreglo, no se puede descartar que los bloques afectados por la escritura incompleta sean restaurados incorrectamente.
En el caso de btrfs, este problema es más relevante si la escritura realizada es menor que el tamaño del stripe. En este caso, el sistema de archivos debe llevar a cabo la operación de lectura-modificación-escritura (read-modify-write, RMW). Si se encuentran bloques con escritura incompleta, la operación RMW puede causar daños que no se detectarán, a pesar de las sumas de verificación. Los desarrolladores han realizado cambios para que la operación RMW verifique la suma de verificación de los bloques antes de llevar a cabo la operación, y, si es necesario restaurar los datos, también se realiza una verificación de las sumas de verificación después de la escritura. Desafortunadamente, en la situación de escritura de un stripe incompleto (RMW), esto conlleva un costo adicional en el cálculo de sumas de verificación, sin embargo, aumenta significativamente la fiabilidad. Para RAID6, esta lógica aún no está lista, pero para tal fallo en RAID6 es necesario que la escritura falle en dos dispositivos simultáneamente, lo que es menos probable.
Además, se pueden mencionar las recomendaciones de los desarrolladores sobre el uso de RAID5/6, que se centran en que en Btrfs el perfil de almacenamiento de metadatos y datos puede diferir. Se puede utilizar un perfil RAID1 (espejo) o incluso RAID1C3 (3 copias) para los metadatos, mientras que para los datos se puede optar por RAID5 o RAID6. Esto proporciona una protección fiable de los metadatos y elimina el 'write hole', al tiempo que permite un uso más eficaz del espacio, característico de RAID5/6. Esto ayuda a evitar daños en los metadatos y las corrupciones de datos pueden ser corregidas.
También se puede señalar que para SSD en Btrfs en el kernel 6.2 se activará por defecto la ejecución asíncrona de la operación 'discard' (marcando los bloques liberados que ya no se deben almacenar físicamente). La ventaja de este modo es el alto rendimiento debido a la agrupación eficaz de las operaciones 'discard' en la cola y la posterior gestión de esta cola por parte del procesador en segundo plano, por lo que las operaciones normales del sistema de archivos no se ralentizan, como ocurre con el 'discard' sincrónico al liberar bloques, permitiendo al SSD tomar decisiones más favorables. Por otro lado, ya no será necesario usar utilidades como fstrim, ya que todos los bloques disponibles se limpiarán en el sistema de archivos sin necesidad de un escaneo adicional y sin ralentizar las operaciones.
Fuente: opennet.ru
