detecção e correção de podridão de bits com mdadm

Estou prestes a reorganizar todos os meus HDDs nas caixas linux domésticas e gostaria de usar o mdadm raid para proteção de dados e sua flexibilidade para remodelar as matrizes. No entanto, antes de usar o mdadm para isso, gostaria de saber como ele lida com a podridão de bits . Especificamente, os tipos de roteamento de bits que não resultam no envio de mensagens de erro de leitura irrecuperáveis ​​do disco rígido.

Dado que provavelmente usarei pelo menos 21 TB de HDDs em 8 discos nas e as várias cotações de probabilidade de falhas nos HDDs, estou pensando que, durante uma reconstrução a partir de uma única falha de disco, é provável que eu encontre alguma forma de apodrecimento de bits nos discos restantes. Se for um erro de leitura irrecuperável em uma das unidades, que a unidade realmente o relata como um erro, acredito que deve estar bem com o raid6 (não é?). No entanto, se os dados lidos no disco são ruins, mas não são relatados como tal pelo disco, não vejo como isso pode ser corrigido automaticamente, mesmo com o raid6. É com isso que precisamos nos preocupar? Dado o artigo É 2010 e o RAID5 ainda funcionae minhas próprias experiências bem-sucedidas em casa e no trabalho, as coisas não são necessariamente tão sombrias e sombrias quanto as palavras e o marketing nos fazem acreditar, mas eu odeio ter que restaurar os backups apenas porque um HDD falhou.

Dado que os padrões de uso serão, escreva no máximo algumas vezes e leia ocasionalmente, precisarei executar a limpeza de dados . Eu vejo no wiki do archlinux os comandos mdadm para limpeza de dados de uma matriz como

echo check > /sys/block/md0/md/sync_action

então para monitorar o progresso

cat /proc/mdstat

Parece-me que ele lerá todos os setores de todos os discos e verificará se os dados correspondem à paridade e vice-versa. Embora eu note que há muita ênfase nos documentos para dizer que há circunstâncias significativas em que a operação de "verificação" não será capaz de corrigir automaticamente, apenas detectar, e isso deixará o usuário corrigir.

Quais níveis de mdadm RAID devo escolher para maximizar minha proteção contra a podridão de bits e que manutenção e outras etapas de proteção devo executar? E do que isso não vai me proteger?

Edit: Eu não estou olhando para iniciar um RAID vs ZFS ou qualquer outra tecnologia QA. Eu quero saber especificamente sobre mdadm raid. É também por isso que estou perguntando no Unix e Linux e não no SuperUser .

Edit: é a resposta: o mdadm pode corrigir apenas os UREs relatados pelos sistemas de disco durante uma limpeza de dados e detectar a rotação silenciosa de bits durante uma limpeza, mas não pode / não corrigirá isso?

Francamente, acho surpreendente que você rejeite o RAIDZ2 ZFS. Parece atender às suas necessidades quase perfeitamente, exceto pelo fato de não ser o Linux MD. Não estou em uma cruzada para levar o ZFS às massas, mas o simples fato é que o seu é um dos tipos de problemas que o ZFS foi projetado desde o início para resolver. Confiar no RAID (qualquer RAID "regular") para fornecer detecção e correção de erros, possivelmente em uma situação de redundância reduzida ou inexistente, parece arriscado. Mesmo em situações em que o ZFS não pode corrigir um erro de dados corretamente, ele pode pelo menos detectar o erro e informar que há um problema, permitindo que você tome as ações corretivas.

Você não precisa fazer scrubs completos regulares com o ZFS, embora seja uma prática recomendada. O ZFS verificará se os dados lidos no disco correspondem ao que foi gravado enquanto os dados estão sendo lidos e, no caso de uma incompatibilidade (a) use redundância para reconstruir os dados originais ou (b) relate um erro de E / S para a aplicação. Além disso, a limpeza é uma operação on-line de baixa prioridade, bastante diferente de uma verificação do sistema de arquivos na maioria dos sistemas de arquivos, que pode ser de alta prioridade e off-line. Se você estiver executando uma limpeza e algo diferente da limpeza quiser fazer E / S, a limpeza ficará no banco de trás enquanto durar. Uma limpeza ZFS substitui a limpeza RAID e os metadados e dados do sistema de arquivos verificação de integridade, isso é muito mais completo do que apenas esfregar a matriz RAID para detectar qualquer podridão de bits (o que não informa se os dados fazem algum sentido, apenas que foram gravados corretamente pelo controlador RAID).

A redundância do ZFS (RAIDZ, espelhamento, ...) tem a vantagem de que os locais de disco não utilizados não precisam ser verificados quanto à consistência durante a limpeza; somente dados reais são verificados durante a limpeza, à medida que as ferramentas percorrem a cadeia de blocos de alocação. É o mesmo que com um pool não redundante. Para RAID "regular", todos os dados (incluindo todos os locais não utilizados no disco) devem ser verificados porque o controlador RAID (seja hardware ou software) não tem idéia de quais dados são realmente relevantes.

Ao usar o RAIDZ2 vdevs, qualquer uma das duas unidades constituintes pode falhar antes que você corra o risco de perda de dados real devido a outra falha da unidade, pois você tem redundância em duas unidades. É essencialmente o mesmo que RAID6.

No ZFS, todos os dados, dados do usuário e metadados, são somados (exceto se você optar por não, mas isso é recomendado) e essas somas de verificação são usadas para confirmar que os dados não foram alterados por qualquer motivo. Novamente, se uma soma de verificação não corresponder ao valor esperado, os dados serão reconstruídos de forma transparente ou um erro de E / S será relatado. Se um erro de E / S for relatado ou uma limpeza identificar um arquivo com corrupção, você saberá com certeza que os dados nesse arquivo estão potencialmente corrompidos e podem restaurar esse arquivo específico do backup; não há necessidade de uma restauração completa da matriz.

Simples, mesmo com dupla paridade, o RAID não o protege contra situações como, por exemplo, quando uma unidade falha e mais uma lê os dados incorretamente no disco. Suponha que uma unidade falhe e há um único toque em qualquer lugar em qualquer uma das outras unidades: de repente, você tem corrupção não detectada e, a menos que esteja satisfeito com isso, precisará de pelo menos uma maneira de detectá-la. A maneira de atenuar esse risco é a soma de verificação de cada bloco no disco e garantir que a soma de verificação não possa ser corrompida junto com os dados (proteção contra erros como gravações de alta velocidade, gravações órfãs, gravações em locais incorretos no disco etc.), o que é exatamente o que o ZFS faz desde que a soma de verificação esteja ativada.

A única desvantagem real é que você não pode aumentar facilmente um RAIDZ vdev adicionando dispositivos a ele. Existem soluções alternativas para isso, geralmente envolvendo coisas como arquivos esparsos como dispositivos em um vdev e , muitas vezes, denominadas "eu não faria isso se fossem meus dados". Portanto, se você seguir uma rota RAIDZ (independentemente de ir com RAIDZ, RAIDZ2 ou RAIDZ3), precisará decidir antecipadamente quantas unidades deseja em cada vdev. Embora o número de unidades em um vdev seja fixo, você pode aumentar um vdev gradualmente (certificando-se de permanecer dentro do limite de redundância do vdev) substituindo as unidades por unidades de maior capacidade e permitindo um resilver completo.

Esta resposta é o produto do raciocínio com base nos vários fragmentos de evidência que encontrei. Não sei como funciona a implementação do Linux no kernel, pois não sou um desenvolvedor de kernel e parece haver uma quantidade razoável de informações erradas por aí. Presumo que o kernel Linux faça escolhas sensatas. Minha resposta deve ser aplicada, a menos que eu esteja enganado.

Muitas unidades usam ECCs (códigos de correção de erros) para detectar erros de leitura. Se os dados estiverem corrompidos, o kernel deverá receber um URE (erro de leitura irrecuperável) para esse bloco de uma unidade de suporte do ECC. Nessas circunstâncias (e há uma exceção abaixo), copiar dados corrompidos ou vazios sobre dados bons seria insanidade. Nesta situação, o kernel deve saber quais são bons dados e quais são ruins. De acordo com o It is 2010 e o RAID5 ainda funciona… artigo:

Considere esta alternativa, que eu sei que deve ser usada por pelo menos alguns fornecedores de matriz. Quando uma unidade em um volume RAID relata um URE, o controlador da matriz incrementa uma contagem e satisfaz a E / S reconstruindo o bloco da paridade. Em seguida, ele executa uma reescrita no disco que relatou o URE (potencialmente com verificação) e se o setor estiver ruim, o microcódigo será remapeado e tudo ficará bem.

No entanto, agora a exceção: se uma unidade não suporta ECC, uma unidade mente sobre corrupção de dados ou o firmware é particularmente disfuncional, um URE pode não ser relatado e dados corrompidos serão fornecidos ao kernel. No caso de dados incompatíveis: parece que se você estiver usando um RAID1 de 2 discos ou um RAID5, o kernel não poderá saber quais dados estão corretos, mesmo quando em um estado não degradado, porque existe apenas uma paridade bloco e não houve relato de URE. Em um RAID1 de 3 discos ou um RAID6, um único bloco corrompido sem sinalização de URE não corresponderia à paridade redundante (em combinação com os outros blocos associados), portanto, a recuperação automática adequada deve ser possível.

A moral da história é: use drives com ECC. Infelizmente, nem todas as unidades que suportam ECC anunciam esse recurso. Por outro lado, tenha cuidado: conheço alguém que usou SSDs baratos em um RAID1 de 2 discos (ou um RAID10 de 2 cópias). Uma das unidades retornou dados corrompidos aleatórios em cada leitura de um setor específico. Os dados corrompidos foram copiados automaticamente sobre os dados corretos. Se o SSD usava ECCs e estava funcionando adequadamente, o kernel deveria ter tomado as ações corretivas adequadas.

Para a proteção que você deseja, eu usaria o RAID6 + o backup externo normal em 2 locais.

De qualquer forma, faço uma limpeza pessoal uma vez por semana e faço o backup noturno, semanal e mensal, dependendo da importância dos dados e da velocidade de alteração.

Não tenho representante suficiente para comentar, mas quero ressaltar que o sistema mdadm no Linux NÃO corrige nenhum erro. Se você pedir para "corrigir" erros durante uma limpeza de, por exemplo, RAID6, se houver uma inconsistência, ele será "corrigido", assumindo que as partes dos dados estejam corretas e recalculando a paridade.

pouco podridão fud.? certo...

Eu acho que você precisa falar com a SEAGATE. (esqueça? essa é a desculpa)? Agora, todos os drives têm correção ECC de 100 bits. Você precisa provar primeiro a podridão.
Aposto que você não pode. (é coisa de FUD se preocupar, certo?) como medo de fantasmas ou o # 13? e não feito aqui. zero prova aconteceu. e pior, nenhuma prova de causa.

Primeiro defina o que significa podridão por bits. ai ... HDD: O ECC verifica os dados (até 1 bit) no armazenamento de 100 bits do ECC. se estiver errado, corrige-o; se ele falha constantemente no mecanismo SMART, com certeza nas unidades SAS, ele substitui logicamente o cluster ou o setor por um que seja bom. usando clusters de reposição. isso repara o dano. Sim, todas as unidades crescem bits ruins desde o primeiro dia até as primeiras unidades da IBM até o NOW. mas agora fazemos o reparo automático, leia os documentos técnicos completos da Seagate. interminável e aprenda como uma unidade funciona. OK?

isso continua até você ficar sem peças de reposição (cérebro do disco rígido, inteligente) e, em seguida, a SMART grita FIM DA VIDA. (ou ainda mais cedo, como a HP faz), digamos que um controlador HP P420, assiste isso o tempo todo. O meu até me envia um e-mail, mostrando os clusters NEAR OUT OF SPARE. Às vezes, as peças de reposição vão muito mais rápido, um sinal certo de desgraça em breve (com 10 anos de idade, com certeza, menos em sata junky).

Eu chamo de BOGUS e FUD na podridão dos bits.

Meu palpite é que alguém brinquedo PC escreveu os dados de forma errada, por qualquer motivo. não está executando a memória ECC? oops, servidores reais têm RAM de ECC. vírus infectado.? ou perda de energia durante a gravação (sem UPS>?)? ou tem memória ruim.? ou ESD danificado. Ou PSU fazendo muito barulho (ruim)

Eu chamo FUD aqui. Desculpe,