A podridão nos discos rígidos é um problema real? O que pode ser feito sobre isso?

Question

Um amigo está falando comigo sobre o problema da podridão de bits - bits nas unidades que invertem aleatoriamente, corrompendo os dados. Incrivelmente raro, mas com tempo suficiente, pode ser um problema e é impossível detectá-lo.

A unidade não considera que seja um setor defeituoso, e os backups apenas acham que o arquivo foi alterado. Não há checksum envolvido para validar a integridade. Mesmo em uma configuração RAID, a diferença seria detectada, mas não haveria como saber qual cópia espelhada está correta.

Este é um problema real? E se sim, o que pode ser feito sobre isso? Meu amigo está recomendando o zfs como uma solução, mas eu não posso imaginar achatar nossos servidores de arquivos no trabalho, colocando o Solaris e o zfs.

    

Answer 1

Primeiro: seu sistema de arquivos pode não ter somas de verificação, mas seu próprio disco rígido as possui. Há S.M.A.R.T., por exemplo. Uma vez que um bit a mais tenha sido invertido, o erro não pode ser corrigido, é claro. E se você for realmente infeliz, os bits podem mudar de tal forma que a soma de verificação não se torne inválida; então o erro nem será detectado. Então, coisas desagradáveis podem acontecer; mas a alegação de que um lançamento aleatório de bits irá corrompê-lo instantaneamente é falso.

No entanto, sim, quando você coloca trilhões de bits em um disco rígido, eles não ficam assim para sempre; isso é um problema real! O ZFS pode fazer a verificação de integridade toda vez que os dados são lidos; Isso é semelhante ao que seu disco rígido já faz por si mesmo, mas é outra proteção para a qual você está sacrificando algum espaço, por isso você está aumentando a resiliência contra a corrupção de dados.

Quando o seu sistema de arquivos é bom o suficiente, a probabilidade de um erro ocorrer sem ser detectado torna-se tão baixa que você não precisa se preocupar com isso por mais tempo e pode decidir que somas de verificação são incorporadas no formato de armazenamento de dados que você re usar é desnecessário.

De qualquer forma: não, não é impossível detectar .

Mas um sistema de arquivos, por si só, nunca pode ser uma garantia de que todas as falhas possam ser recuperadas; Não é uma bala de prata. Você ainda deve ter backups e um plano / algoritmo para o que fazer quando um erro for detectado.

    

Answer 2

Sim, isso é um problema, principalmente quando os tamanhos das unidades aumentam. A maioria das unidades SATA tem uma taxa URE (erro de leitura incorrigível) de 10 ^ 14. Ou para cada 12 TB de dados lidos estatisticamente, o fornecedor da unidade diz que a unidade retornará uma falha de leitura (normalmente você pode consultá-los nas folhas de especificações da unidade). A unidade continuará funcionando bem para todas as outras partes da unidade. Enterprise FC & A unidade SCSI geralmente tem uma taxa de URE de 10 ^ 15 (120TB), juntamente com um pequeno número de unidades SATA, o que ajuda a reduzi-la.

Eu nunca vi discos parar de girar ao mesmo tempo, mas eu tive um volume raid5 atingiu esse problema (há 5 anos com drives PATA de 5400RPM para o consumidor). O drive falha, está marcado como morto e ocorre uma reconstrução na unidade de reposição. O problema é que, durante a reconstrução, uma segunda unidade não consegue ler esse pequeno bloco de dados. Dependendo de quem estiver fazendo o ataque, todo o volume pode estar morto ou apenas aquele pequeno bloco pode estar morto. Supondo que seja apenas um bloco morto, se você tentar lê-lo, receberá um erro, mas se você gravar nele, a unidade irá remapear para outro local.

Existem vários métodos para proteger contra: raid6 (ou equivalente) que protege contra falha de disco duplo é melhor, os adicionais são um sistema de arquivos URE como ZFS, usando grupos de raids menores, então estatisticamente você tem uma chance menor de acessar os limites da unidade URE (unidades grandes espelhadas ou unidades menores raid5), depuração de disco & O SMART também ajuda, mas não é realmente uma proteção em si, mas é usado em adição a um dos métodos acima.

Eu gerencio cerca de 3000 spindles em arrays, e as matrizes estão constantemente limpando as unidades procurando por UREs latentes. E eu recebo um fluxo razoavelmente constante deles (toda vez que ele encontra um, ele corrige isso antes da falha da unidade e me alerta), se eu estivesse usando o raid5 ao invés do raid6 e uma das unidades estivesse completamente morta ... estar em apuros se atingir certos locais.

    

Answer 3

Os discos rígidos geralmente não codificam os bits de dados como domínios magnéticos únicos - os fabricantes de discos rígidos sempre estiveram cientes de que os domínios magnéticos poderiam virar e construir na detecção e correção de erros para os drives.

Se um bit inverte, a unidade contém dados redundantes suficientes que podem e serão corrigidos na próxima vez que o setor for lido. Você pode ver isso se verificar as estatísticas do SMART na unidade, como a "Taxa de erro corrigível".

Dependendo dos detalhes da unidade, ela deve ser capaz de recuperar de mais de um bit invertido em um setor. Haverá um limite para o número de bits invertidos que podem ser silenciosamente corrigidos e, provavelmente, outro limite para o número de bits invertidos que podem ser detectados como um erro (mesmo que não haja dados confiáveis suficientes para corrigi-lo)

Isso tudo se soma ao fato de que os discos rígidos podem corrigir automaticamente a maioria dos erros à medida que ocorrem e podem detectar com segurança a maior parte do restante. Você teria que ter um grande número de erros de bit em um único setor, todos ocorreram antes que o setor fosse lido novamente, e os erros teriam que ser tais que os códigos de detecção de erros internos o vejam como dados válidos novamente, antes de você jamais teria um fracasso silencioso. Não é impossível, e tenho certeza de que as empresas que operam grandes data centers veem isso acontecer (ou melhor, ocorre e elas não vêem isso acontecer), mas certamente não é tão grande problema como você pode pensar.

    

Answer 4

Os discos rígidos modernos (desde 199x) não têm apenas somas de verificação, mas também ECC, que pode detectar e corrigir um pouco de rot acid. Veja: link .

Por outro lado, certos bugs no firmware e nos drivers de dispositivos também podem corromper os dados em ocasiões raras (caso contrário, o controle de qualidade pegaria os bugs), o que seria difícil de detectar se você não tivesse checksums de nível mais alto. Os primeiros drivers de dispositivos para SATA e NICs tinham dados corrompidos no Linux e no Solaris.

As somas de verificação do ZFS visam principalmente os erros no software de nível inferior. Um sistema de armazenamento / banco de dados mais novo, como o Hypertable, também possui somas de verificação para cada atualização, a fim de proteger contra erros nos sistemas de arquivos:)

    

Answer 5

Teoricamente, isso é motivo de preocupação. Na prática, isso é parte do motivo pelo qual mantemos backups filho / pai / avô. Os backups anuais precisam ser mantidos por pelo menos 5 anos, IMO, e se você tiver um caso de voltar mais longe, o arquivo obviamente não é tão importante.

A menos que você esteja lidando com fragmentos que possam potencialmente liquefazer o cérebro de alguém , eu não sou Certifique-se de que o risco versus recompensa é bem o suficiente para mudar os sistemas de arquivos.

    

Answer 6

Sim, isso é um problema.

Esta é uma das razões pelas quais o RAID6 agora está em voga (assim como o aumento dos tamanhos HD aumenta o tempo para reconstruir um array). Ter dois blocos de paridade permite um backup adicional.

Os sistemas RAID agora também executam o RAID Scrubbing, que periodicamente lê blocos de disco, verifica as paridades e o substitui se achar que um bloco está ruim.

    

Answer 7

No que diz respeito à declaração do OP sobre o RAID não entender quais dados são bons e ruins.

Os controladores RAID usam, no mínimo, bits de paridade (ímpar / par) em cada faixa de dados. Isso é para tudo; as faixas de dados em disco e as faixas de dados de paridade (backup).

Isso significa que, para qualquer tipo de RAID que tenha striping para redundância (RAID 5/6), o controlador pode informar com precisão se a faixa de dados original foi alterada, bem como se a faixa de dados de redundância foi alterada.

Se você introduzir uma segunda faixa redundante como o RAID6, precisará ter 3 distribuições de dados, em três unidades diferentes corrompidas, todas correspondendo aos mesmos dados reais do arquivo. Lembre-se que a maioria dos sistemas RAID usa faixas de dados relativamente pequenas (128kb ou menos), então as chances de o "bit rot" se alinhar aos mesmos 128kb, do mesmo arquivo, são praticamente impossíveis.

    

Answer 8

É um problema do mundo real, sim, mas a questão é se você deve se preocupar com isso ou não.

Se você só tiver um disco rígido cheio de fotos, talvez não valha a pena. É cheio de dados científicos importantes, pode ser outro tipo de história, você entendeu a ideia.