O RAID 1 e o RAID 5 (e seus irmãos 10 e 50) alcançam redundância de dados, respectivamente, através do espelhamento e da verificação de paridade. Isso permite que uma matriz RAID ainda acesse dados quando um setor em um disco (ou um disco inteiro) se torna ilegível. O RAID 6 (ou 60) usa uma verificação adicional para permitir falhas duplas.
Mas como uma matriz RAID pode lidar com dados que não são totalmente ilegíveis, mas simplesmente inconsistentes?
Se ocorrer algum erro, de modo que os dados fe em uma faixa sejam alterados em um disco, mas a alteração não seja propagada para a (s) outra (s), a faixa inteira se tornará inconsistente. Se em um conjunto espelhado um disco diz "este bit é 0" enquanto o outro disco diz "este bit é 1", como um controlador RAID pode saber qual é o correto? O mesmo raciocínio pode ser aplicado a uma faixa RAID-5, com a complexidade adicional de que você não pode saber facilmente qual setor está realmente errado na faixa. Além disso, o RAID 6 atenua esse problema com suas checagens duplas, ou ainda pode ter problemas para se recuperar da corrupção de dados quando os dados são realmente legíveis, mas estão errados em algum lugar, especialmente porque as matrizes RAID 6 tendem a ter muitos discos?
Teoricamente, isso poderia ser resolvido por somas de verificação, para garantir qual cópia dos dados (ou paridade) é a correta; mas algum controlador RAID realmente implementa esse tipo de soma de verificação (o que obviamente exigiria espaço adicional)? Ou ele precisa ser tratado no nível do SO, onde a maioria dos sistemas de arquivos pode e fará a soma de verificação de seu conteúdo? E se esse for o caso, como eles podem dizer ao controlador RAID "os dados do setor X no disco Y na faixa Z estão incorretos", quando a abordagem geral de um controlador RAID é abstrair o SO da camada de armazenamento subjacente, tanto quanto possível?
fonte
Respostas:
Nos controladores Areca que usamos (e todos os controladores RAID de hardware modernos) durante uma verificação de consistência, o controlador pode detectar se a corrupção está nos dados de paridade, nos dados físicos no disco ou em ambos. A maioria dos controladores realiza isso com bits de soma de verificação simples para dados de paridade e dados em disco.
No caso de os dados de paridade estarem corrompidos, o controlador notará o problema quando você executar uma verificação de consistência e reler o disco físico para os bits corretos e reescrever a faixa de paridade. Os usuários não terão problemas porque estão lendo dados em disco ao abrir os arquivos. Salvar novamente qualquer coisa que faça com que a faixa de paridade corrompida seja reescrita também corrigirá o problema.
Se ocorrer o contrário, e um pouco inverter os dados reais em disco, seu controlador examinará a faixa de paridade durante uma verificação de consistência para verificar se ela foi alterada. Nesse caso, o controlador substituirá os dados no disco para coincidir com os dados de paridade, o que pode ser confirmado como inalterado / bom. Os usuários receberão um erro de CRC ou um arquivo corrompido, dependendo de quais são os dados até que uma verificação de consistência seja executada e corrija o erro.
Como os dados de paridade para dados específicos em disco nunca são armazenados na mesma unidade que os dados reais, uma única falha na unidade não deve causar problemas de corrupção de dados. Ou dois discos para RAID6, etc.
As verificações de consistência mantêm os dados mais precisos possíveis e, se você deixar dados corrompidos em seu volume por tempo suficiente, eles poderão ser gravados em dados de paridade, o que significa que o arquivo está corrompido para sempre e precisará ser restaurado a partir de um backup. Se uma unidade estiver em um estado de pré-falha em que está mostrando erros durante as verificações de consistência, substitua-a imediatamente, em vez de esperar que o controlador a marque como falha. Executamos verificações de consistência diariamente em volumes menores e semanalmente em volumes maiores.
O controlador / firmware do disco rígido pode corrigir o problema. Se isso não for possível, o controlador RAID terá muita dificuldade para corrigir o problema. Nesse caso, você provavelmente precisaria ler as unidades individualmente para recuperar os dados.
Execute verificações de consistência no intervalo recomendado pelo seu cartão RAID mfg. Se você está realmente preocupado com a corrupção, também pode empilhar um sistema de arquivos resiliente em um volume RAID. Os sistemas de arquivos resilientes modernos podem corrigir muitos desses problemas de integridade de dados e o empilhamento de um FS resiliente sobre RAID6 ofereceria excelente tempo de atividade dos dados, sem corrupção. E mesmo com duas falhas de unidade simultâneas, você ainda teria dados de paridade FS disponíveis para evitar a apresentação de dados corrompidos ao usuário.
fonte
Você descreve efetivamente a situação em que um disco grava (ou lê) um erro. O controlador RAID não possui uma maneira prática (por exemplo, a gravação e a leitura prejudicariam seu desempenho) para se proteger contra essa situação. Ele precisa confiar nos discos capazes de detectar esse tipo de erro e usar um bloco diferente ou reduzir o volume - causando uma degradação do RAID.
Se você pensar na situação do disco único, a única proteção contra gravações inconsistentes (ou leituras) é o próprio disco. O RAID se baseia nisso, mas não introduz uma proteção adicional.
NB: Eu sei por experiência que o XFS reage bastante sensivelmente a discos errados em uma matriz. Portanto, pelo menos meus controladores não low-end e o sistema operacional reconheceram, mas não protegeram, contra essa inconsistência (um disco com defeito conhecido foi adicionado com força a um volume).
fonte