Se han propuesto mejoras de Btrfs para su inclusión en el kernel de Linux 6.2 para solucionar el problema del "agujero de escritura" en la implementación de RAID 5/6. La esencia del problema se reduce al hecho de que si se produce una falla durante la grabación, inicialmente es imposible entender en qué bloque se escribió correctamente en qué dispositivo RAID y en cuál no se completó la grabación. Si intenta restaurar un RAID en esta situación, los bloques correspondientes a los bloques suscritos pueden destruirse porque el estado de los bloques RAID no está sincronizado. Este problema ocurre en cualquier matriz RAID1/5/6 donde no se han tomado medidas especiales para combatir este efecto.
En una implementación RAID, como RAID1 en btrfs, este problema se resuelve usando 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 enviar datos incorrectos en lugar de un fallo total.
Sin embargo, en el caso de RAID5/6, el sistema de archivos no almacena sumas de verificación para los bloques de paridad: en una situación normal, la validez de los bloques se verifica por el hecho de que todos están sumados y el bloque de paridad se puede reconstruir. a partir de los datos. Sin embargo, en el caso de una grabación parcial, es posible que este enfoque no funcione en determinadas situaciones. En este caso, al restaurar una matriz, es posible que los bloques que se encuentran en un registro incompleto se restauren incorrectamente.
En el caso de btrfs, este problema es más relevante si el registro que se produce es más pequeño que la franja. En este caso, el sistema de archivos debe realizar una operación de lectura-modificación-escritura (lectura-modificación-escritura, RMW). Si esto encuentra bloques con escritura incompleta, entonces 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 restaurar datos, también verifica la suma de verificación después de la grabación. 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, sin embargo, para tal falla en RAID6 es necesario que la escritura falle en 2 dispositivos a la vez, lo cual es menos probable.
Además, podemos observar las recomendaciones de los desarrolladores para el uso de RAID5/6, cuya esencia es que en Btrfs el perfil de almacenamiento de datos y metadatos 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, característico de RAID5/6, por el otro. Esto permite evitar la corrupción de metadatos y corregir la corrupción de datos.
También se puede observar que para los SSD en Btrfs en el kernel 6.2, la ejecución asincrónica de la operación "descartar" se activará de forma predeterminada (marcando los bloques liberados que ya no necesitan ser almacenados físicamente). La ventaja de este modo es el alto rendimiento debido a la agrupación efectiva de operaciones de "descarte" en una cola y al procesamiento posterior de la cola por parte de un procesador en segundo plano, razón por la cual las operaciones normales de FS no se ralentizan, como es el caso de las sincrónicas ". descartar” a medida que se liberan los bloques y el SSD puede tomar mejores decisiones. Por otro lado, ya no necesitará utilizar utilidades como fstrim, ya que todos los bloques disponibles se borrarán en el FS sin necesidad de realizar análisis adicionales y sin ralentizar las operaciones.
Fuente: opennet.ru