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...
Comentarios
¿Pero los modos RAID5 y RAID6 de BTRFS ya son estables, o siguen siendo "no recomendables para sistemas de producción"?
La primera vez que oí hablar de Linux fue en Radio3 a principios de los dosmiles. Supongo que sería en el programa Siglo 21que traía los miércoles a un experto en informática que traía temas muy buenos y era lo mejor del programa. Radio3 de entonces, no la de ahora, al menos todavía algo queda de ese espíritu innovador.
"en el caso de RAID5/6, el sistema de archivos no almacena sumas de verificación para bloques de paridad"
Esto está mal explicado ¿no? O eso o yo no entiendo porque en Raid-5 hay un disco "de más".
#3 Creo (porque, efectivamente, está explicado como el culo) que se refiere a que cada bloque/conjunto de sectores incluya un CRC para confirmar que es correcto. Luego, a mayores, estaría el "disco de más" que se utilizaría para recuperar los datos de aquel bloque que se ha confirmado que es erróneo.