Para a ativação do kernel Linux 6.2, melhorias para o Btrfs foram propostas, visando corrigir o problema do "write hole" na implementação do RAID 5/6. A essência do problema é que, se uma falha ocorrer durante a gravação, inicialmente não é possível entender qual bloco foi gravado corretamente em qual dispositivo RAID e em qual a gravação não foi concluída. Ao tentar recuperar o RAID em tal situação, pode ocorrer a destruição dos blocos correspondentes aos blocos não gravados, uma vez que o estado dos blocos RAID está dessincronizado. Esse problema surge em qualquer conjunto RAID1/5/6, onde não foram adotadas medidas especiais para combater esse efeito.
Na implementação do RAID, como o RAID1 no Btrfs, esse problema é resolvido com o uso de somas de verificação em ambas as cópias; na discrepância, os dados são simplesmente recuperados da segunda cópia. Essa abordagem também é eficaz se algum dispositivo começar a fornecer dados incorretos em vez de falhar completamente.
No entanto, no caso do RAID5/6, o sistema de arquivos não armazena somas de verificação para os blocos de paridade: em uma situação normal, a correção dos blocos é verificada pelo fato de que todos eles possuem uma soma de verificação, e o bloco de paridade pode ser reconstruído a partir dos dados. No entanto, em caso de gravação parcial, essa abordagem pode não funcionar em certas situações. Nesse caso, ao recuperar o conjunto, não é impossível que os blocos atingidos pela gravação inacabada sejam recuperados incorretamente.
No caso do btrfs, esse problema é mais relevante quando a gravação realizada é menor do que o stripe. Nesse caso, o sistema de arquivos deve executar a operação de leitura-modificação-gravação (read-modify-write, RMW). Se bloqueios com gravação incompleta forem encontrados, a operação RMW pode causar corrupções que não serão detectadas, apesar das somas de verificação. Os desenvolvedores fizeram alterações, onde a operação RMW verifica a soma de verificação dos blocos antes de realizar essa operação e, ao restaurar dados, faz também a verificação das somas de verificação após a gravação. Infelizmente, na situação de gravação de um stripe incompleto (RMW), isso resulta em sobrecargas adicionais para o cálculo das somas de verificação, mas aumenta significativamente a confiabilidade. Para o RAID6, essa lógica ainda não está implementada, porém, para essa falha no RAID6, é necessário que a gravação falhe em dois dispositivos ao mesmo tempo, o que é menos provável.
Além disso, pode-se notar as recomendações dos desenvolvedores sobre o uso do RAID5/6, que resumem que, no Btrfs, o perfil de armazenamento de metadados e dados pode ser diferente. É possível usar o perfil RAID1 (espelho) ou até mesmo RAID1C3 (3 cópias) para metadados, enquanto para dados, utiliza-se RAID5 ou RAID6. Isso garante uma proteção confiável dos metadados e a ausência de "write hole" de um lado, e um uso mais eficiente do espaço, característico do RAID5/6, do outro. Isso ajuda a evitar corrupções nos metadados, enquanto as falhas nos dados podem ser corrigidas.
É importante mencionar que, para SSDs, no Btrfs do núcleo 6.2, a execução assíncrona da operação "discard" (marcação de blocos liberados que não precisam mais ser armazenados fisicamente) será ativada por padrão. A vantagem desse modo é o alto desempenho devido ao agrupamento eficiente das operações de "discard" na fila e o processamento da fila pelo manipulador em segundo plano, o que evita que as operações normais do sistema de arquivos sejam desaceleradas, como no caso de "discard" síncrono durante a liberação de blocos, permitindo que o SSD tome decisões mais eficientes. Por outro lado, não será mais necessário utilizar utilitários como fstrim, uma vez que todos os blocos disponíveis serão limpos no sistema de arquivos sem a necessidade de uma varredura adicional e sem desacelerar as operações.
Fonte: opennet.ru
