Linux Kernel

Se dio a conocer hace poco que fueron propuestas mejoras de Btrfs para su inclusión en el kernel de Linux 6.2 para solucionar el problema del «write hole» en la implementación de RAID 5/6.

La esencia del problema se reduce al hecho de que si se produce un bloqueo durante la grabación, inicialmente es imposible entender qué bloque en cuál de los dispositivos RAID se escribió correctamente y en cuál no se completó la grabación.

Si se intenta reconstruir un RAID en esta situación, los bloques correspondientes a los bloques suscritos pueden dañarse porque el estado de los bloques RAID no está sincronizado. Este problema ocurre en cualquier arreglo RAID1/5/6 donde no se toman medidas especiales para combatir este efecto.

En una implementación de RAID como RAID1 en btrfs, este problema se resuelve mediante el uso de sumas de verificación en ambas copias, si hay una discrepancia, los datos simplemente se restauran desde la segunda copia. Este enfoque también funciona si algún dispositivo comienza a dar datos incorrectos en lugar de fallar por completo.

Sin embargo, en el caso de RAID5/6, el sistema de archivos no almacena sumas de verificación para bloques de paridad: en una situación normal, la corrección de los bloques se verifica por el hecho de que todos están equipados con una suma de verificación y el bloque de paridad puede recrearse a partir de los datos. Sin embargo, en el caso de grabación parcial, este enfoque puede no funcionar en ciertas situaciones. En este caso, al restaurar la matriz, es posible que los bloques que quedaron en el registro incompleto se restauren incorrectamente.

En el caso de btrfs, este problema es más relevante si la escritura que se produce es más pequeña que la franja. En este caso, el sistema de archivos debe realizar una operación de lectura, modificación y escritura (RMW).

Si encuentra bloques de escritura en curso, la operación RMW puede causar daños que no se detectarán, independientemente de las sumas de verificación. Los desarrolladores han realizado cambios en los que la operación RMW verifica la suma de verificación de los bloques antes de realizar esta operación y, si es necesario, la recuperación de datos también realiza una verificación de suma de verificación después de escribir.

Desafortunadamente, en una situación en la que se escribe una franja incompleta (RMW), esto genera una sobrecarga adicional para calcular las sumas de verificación, pero aumenta significativamente la confiabilidad. Para RAID6, dicha lógica aún no está lista,

Además, podemos observar las recomendaciones sobre el uso de RAID5/6 de los desarrolladores, cuya esencia es que en Btrfs el perfil para almacenar metadatos y datos puede diferir. En este caso, puede utilizar el perfil RAID1 (espejo) o incluso RAID1C3 (3 copias) para metadatos, y RAID5 o RAID6 para datos.

Esto garantiza una protección fiable de los metadatos y la ausencia de un «agujero de escritura», por un lado, y un uso más eficiente del espacio, típico de RAID5/6, por el otro. Esto evita la corrupción en los metadatos y la corrupción de datos se puede corregir.

También se puede señalar que para los SSD en Btrfs en el kernel 6.2, la ejecución asíncrona de la operación «discard» (marcar bloques liberados que ya no se pueden almacenar físicamente) estará activada por defecto.

La ventaja de este modo es el alto rendimiento debido a la agrupación eficiente de las operaciones de «discard» en una cola y el procesamiento posterior de la cola por parte de un controlador en segundo plano, por lo que las operaciones normales de FS no se ralentizan, como es el caso con el síncrono «discard» a medida que se liberan bloques, y el SSD puede tomar mejores decisiones. Por otro lado, ya no necesitará usar utilidades como fstrim, ya que todos los bloques disponibles se borrarán en el FS sin necesidad de escaneo adicional y sin ralentizar las operaciones.

Finalmente si estás interesado en poder conocer más al respecto, puedes consultar los detalles en el siguiente enlace.