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

17

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?

BeowulfNode42
fonte
No que diz respeito à proteção de dados, o principal benefício que vejo no zfs é que ele limpa a localização dos arquivos nos discos sempre que você lê um arquivo. É por isso que atualmente o tenho configurado com o zfs. Mas ainda preciso executar regularmente uma limpeza completa. Eu tenho 2 pools do zfs, cada um com 3 discos, e quero atualizar para um sistema de 8 discos em que qualquer unidade possa falhar e ainda haverá mais 1 unidade redundante e o zfs não é flexível para permitir uma reformulação como essa. Desde que estou reconstruindo de qualquer maneira, estou re-visitando o mdadm.
BeowulfNode42
Você teve sorte com o RAID5 / 6 até agora. O fato é que é 2013 e o RAID ainda sofre com um furo de gravação. Se você perder o poder depois que os dados forem gravados, mas antes da paridade, você acaba de corromper seus bons dados e é possível que, com a inconsistência, sua matriz também esteja brindando. Obrigado RAID5.
bahamat
O problema é que o que você quer fazer é melhor na camada do sistema de arquivos. Caso contrário, você precisaria de alguma maneira para detectar e, de preferência, corrigir a podridão de bits, possivelmente em uma situação de redundância reduzida ou sem redundância, e o RAID simplesmente não é adequado para isso. Não só não há garantia de que você não acabará com a podridão dos bits (e se uma unidade falhar e outra ler o bit errado do prato?), Mas o RAID comum também não tem noção do que são dados importantes e o que é apenas barulho. Como o ZFS limpa apenas os dados referenciados , a podridão de bits em uma parte não utilizada do disco se torna um problema.
um CVn
Realmente, você não pode esperar que um sistema de arquivos aleatório em camadas sobre vários discos (mesmo com redundância) proteja repentinamente contra falhas de armazenamento. Não estou em uma cruzada sagrada para levar o ZFS às massas (embora eu ache que seja uma grande invenção, e o uso no Linux para basicamente tudo, menos a partição raiz, que é ext4 no mdraid1 para compatibilidade de software), mas Também reconheço que o seu é um dos tipos de problemas que o ZFS foi projetado desde o início para resolver: detecção garantida e, se possível, reparo da corrupção de dados, independentemente da causa.
um CVn
Eu acho que você deve revisar seus requisitos. Você realmente precisa de proteção bitrot mesmo para o caso em que a correção de erros é aplicada? Você sabe o quão improvável é a existência de um bitrot GIVEN que também foi corrigido pelo ECC do disco?
das cavernas

Respostas:

5

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.

um CVn
fonte
5
Na minha pergunta original, eu estava tentando evitar o argumento zfs vs raid, pois há muitas informações sobre isso. Quero informações específicas sobre o mdadm. Além disso, como não lerei todos os dados com frequência suficiente para garantir que os dados sejam limpos regularmente, precisarei forçar uma limpeza completa da matriz regularmente, independentemente do zfs ou da invasão.
BeowulfNode42
@ BeowulfNode42 pessoalmente, sugiro o uso de somas de verificação da camada de aplicação para dados excepcionalmente importantes (por exemplo, use sha256 para somar os dados importantes). O ZFS pode fazer isso por bloco, o que eu acho realmente um exagero. Eu acho que isso explica por que não há muitos sistemas de arquivos somados a seus blocos, como o ZFS, porque na IMO isso é mais um problema da camada de aplicativo.
homem das cavernas
1
@ caveman Eu não sei sobre você; Eu realmente gosto do fato de não precisar verificar constantemente os arquivos da soma de verificação apenas para ter certeza de que eles não foram corrompidos. Claro, na grande maioria das vezes não há corrupção ; nesse caso, nenhum dano é causado (com o ZFS, você escolhe o algoritmo de soma de verificação entre alguns, para poder escolher seu ponto preferido ao longo do continuum de segurança / desempenho), mas as somas de verificação automatizadas no nível do sistema de arquivos garantem que não haja corrupção não corrigida, porque, se houver, você saberá disso, no caso do ZFS, recebendo um erro de E / S em vez de dados corrompidos.
a CVn
@ MichaelKjörling não, ele não "garante" (apenas reduz a probabilidade de erros não detectados em relação às verificações somente em disco, em uma quantia que ninguém quantificou ainda! Portanto, ninguém realmente sabe o quão útil a soma de verificação do ZFS é :)), além de você pode usar um invólucro simples de "leitura" e "gravação" que faça a soma de verificação transparente para você. Não é necessário colocar essa coisa sofisticada no espaço do kernel.
homem das cavernas
3
@ caveman não, o zfs não está no tópico. Nem são possíveis implementações de RAID que não sejam mdadm. Eu quero saber sobre mdadm. Eu já votei esta resposta o máximo que pude e seus comentários em uma resposta fora do tópico preenchendo mais informações sobre a resposta fora do tópico não estão ajudando na pergunta original.
BeowulfNode42
3

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.

sudoman
fonte
1
Eu pensei que todos os HDD modernos têm algum tipo de ECC interno. Se é ou não eficaz, correto ou com defeito é outra questão. O ECC deve ser usado internamente na unidade para poder relatar um URE. O apodrecimento silencioso de bits, no qual estou mais interessado, não relata um URE mesmo em unidades que o suportam, pois eles acham que têm os dados corretos quando não o fazem.
BeowulfNode42
Por podridão por bits, presumo que você queira dizer bits invertendo aleatoriamente. Em qualquer caso, o ECC é projetado para detectar bits invertidos. Segundo a Wikipedia, a correção de erros de Reed-Solomon é um formato ECC comum inventado em 1960 e ainda é usado em discos Blu-Ray + HDDs. Se você descobrir que esse algoritmo é extremamente confiável, sua pergunta deverá ser respondida, pois o hardware moderno decente, por definição, é tão bom, se não melhor, mesmo que você não conheça a decência de um hardware apenas por olhando para ele.
Sudoman 5/10
1
A podridão de bits também pode ocorrer devido a outros problemas, como quando algum problema faz com que os cabeçotes da unidade não sejam alinhados corretamente com o local que eles pensam estar gravando e transbordando para setores próximos. Pode corrigir o setor em que pretendia trabalhar, mas o setor próximo será danificado. Se, por acaso, você tiver gravado os dados + ecc de maneira que o ECC do setor próximo relata estar bom, a unidade nunca saberá que está com um problema. Muito provavelmente, algum software não autorizado instrui a unidade a gravar dados ruins, o disco rígido armazenará fielmente esses dados ruins. por exemplo, um comando dd ruim
BeowulfNode42 5/16
2

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.

djsmiley2k - CoW
fonte
1
mas quais recursos de detecção / correção de podridão por bits isso oferece?
BeowulfNode42
1
O RAID6 com lavagem frequente oferece alguma proteção contra a rotatividade de bits, pois a paridade dupla cria efetivamente três versões do mesmo bloco, para que seja possível realizar uma "votação" na versão correta. AFAIK, limpeza de RAID6 no linux dm-raid faz exatamente isso, por favor me corrija se eu estiver errado.
P.Péter 7/10/2015
1
@ P.Péter Percebo que a matemática envolvida PODE usar um sistema de votação, mas mdadm? Você conhece alguma documentação sobre isso ou teve experiência pessoal que o levou a essa conclusão. Particularmente à luz da resposta de Ethan.
BeowulfNode42
Isso foi há algum tempo, mas eu me lembro vagamente de ler os mecanismos RAID6 do mdadm antes de comentar. Desculpe, não muito específico. :( Eu acho que poderia usar um verdadeiro especialista em mdadm ...
P.Péter
2

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.

Ethan
fonte
1
Isso parece bastante improvável, a menos que eu o entenda mal. Você quer dizer que os dados dos blocos corrompidos geralmente são copiados nos blocos corretos? Isso exigiria que o bloco defeituoso não provenha de uma unidade compatível com ECC (e, portanto, não reportaria um URE), e que você estivesse usando RAID5 ou 2 cópias RAID1 (em vez de RAID6, como sugerido.)
sudoman
@sudoman, durante uma limpeza, se o subsistema Linux MD detectar uma incompatibilidade entre os dados e a paridade, ele assume cegamente que a paridade está errada e a reescreve com base nos dados. É possível usar a paridade dupla do RAID 6 para descobrir qual está errado, mas o subsistema Linux MD não faz isso.
Mark
1
Ethan, suponho que você não tenha referências para essa informação? ou exemplos de experiência pessoal que você deseja compartilhar do que se lembra? Dados os tumbleweeds que esse Q gerou, mesmo informações anedóticas seriam úteis. Desde que este Q foi publicado, tive alguns problemas com o mdadm RAID1 para a unidade de inicialização, em pen drives (baratos) quando um deles deu errado. Mais tarde, algumas investigações apontam que o pendrive USB com falha não possui o suficiente ou nenhuma verificação de erro, ou apenas falhava em gravar dados em alguns blocos e não produzia um erro de gravação. Eu tive que reinstalar o sistema operacional.
BeowulfNode42 26/06
-2

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,

savvy2
fonte
1
Acabei de esclarecer que estava falando sobre meu sistema doméstico, de modo que o hardware ECC e de nível de servidor está fora do meu orçamento. Meu laboratório doméstico é muito mais propenso a uma perda inesperada de energia, mesmo com seus mini ups ou outros eventos aleatórios, como a torre caindo ou algo assim. Existem muitas outras maneiras de um HDD ser instruído a armazenar os dados errados e solicitar que o HDD armazene os bits do ECC para esses dados errados. Não me importo como os erros ocorreram, quero que sejam corrigidos facilmente.
BeowulfNode42