Recentemente foi revelado que melhorias para Btrfs foram propostas para inclusão no kernel Linux 6.2 para corrigir o problema de gravação na implementação do RAID 5/6.
A essência do problema se resume ao fato de que, se ocorrer uma falha durante a gravação, é inicialmente impossível entender qual bloco em qual dos dispositivos RAID foi gravado corretamente e em qual a gravação não foi concluída.
Se você tentar reconstruir um RAID nessa situação, os blocos correspondentes aos blocos assinados podem ser corrompidos porque o estado dos blocos RAID está fora de sincronia. Esse problema ocorre em qualquer matriz RAID1/5/6 em que nenhuma medida especial é tomada para combater esse efeito.
Em uma implementação de RAID como RAID1 em btrfs, esse problema é resolvido usando somas de verificação em ambas as cópias, se houver uma incompatibilidade, os dados são simplesmente restaurados da segunda cópia. Essa abordagem também funciona se algum dispositivo começar a fornecer dados incorretos em vez de falhar completamente.
No entanto, no caso de RAID5/6, o sistema de arquivos não armazena somas de verificação para blocos de paridade - em uma situação normal, a exatidão dos blocos é verificada pelo fato de estarem todos equipados com uma soma de verificação e o bloco de paridade pode ser recriado a partir dos dados. No entanto, no caso de gravação parcial, essa abordagem pode não funcionar em determinadas situações. Neste caso, ao restaurar o array, é possível que os blocos deixados no registro incompleto são restaurados incorretamente.
No caso do btrfs, esse problema é mais relevante se a escrita que ocorre for menor que o stripe. Nesse caso, o sistema de arquivos deve executar uma operação de leitura-modificação-gravação (RMW).
Se encontrar blocos de gravação em andamento, a operação RMW pode causar danos que não serão detectados, independentemente das somas de verificação. Os desenvolvedores fizeram alterações em que a operação RMW verifica a soma de verificação dos blocos antes de executar esta operação e, se necessário, a recuperação de dados também realiza uma verificação de soma de verificação após a gravação.
Infelizmente, em uma situação em que uma margem incompleta (RMW) é gravada, isso cria uma sobrecarga adicional para calcular as somas de verificação, mas aumenta significativamente a confiabilidade. Para RAID6, essa lógica ainda não está pronta,
Além disso, podemos observar as recomendações dos desenvolvedores sobre o uso de RAID5/6, cuja essência é que no Btrfs o perfil para armazenamento de metadados e dados pode ser diferente. Nesse caso, você pode usar o perfil RAID1 (espelho) ou até RAID1C3 (3 cópias) para metadados e RAID5 ou RAID6 para dados.
Isso garante proteção confiável de metadados e ausência de "buraco de gravação", por um lado, e uso de espaço mais eficiente, típico de RAID5/6, por outro. Isso evita a corrupção de metadados e a corrupção de dados pode ser corrigida.
também Pode-se notar que para SSDs em Btrfs no kernel 6.2, la execução assíncrona da operação "descartar" (marcar blocos liberados que não podem mais ser armazenados fisicamente) estará ativado por padrão.
A vantagem deste modo é alto desempenho devido ao agrupamento eficiente de operações de descarte em uma fila e pós-processamento da fila por um manipulador de segundo plano, de modo que as operações FS normais não sejam retardadas, como é o caso do "descarte" síncrono, pois os blocos são liberados e o SSD pode melhorar decisões. Por outro lado, você não precisará mais usar utilitários como fstrim, pois todos os blocos disponíveis serão apagados no FS sem a necessidade de varredura adicional e sem tornar as operações lentas.
Por fim, se você estiver interessado em saber mais sobre o assunto, consulte os detalhes em o seguinte link.