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

Um amigo está conversando comigo sobre o problema de apodrecer bits em unidades que lançam aleatoriamente, corrompendo dados. Incrivelmente raro, mas com tempo suficiente, isso pode ser um problema e é impossível detectá-lo.

A unidade não consideraria um setor ruim e os backups apenas pensariam que o arquivo foi alterado. Não há soma de verificação envolvida para validar a integridade. Mesmo em uma configuração de RAID, a diferença seria detectada, mas não havia como saber qual cópia espelhada está correta.

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

Primeiro: o seu sistema de arquivos pode não ter somas de verificação, mas o próprio disco rígido as possui. Há o SMART, por exemplo. Uma vez que um pouco demais foi invertido, o erro não pode ser corrigido, é claro. E se você for realmente azarado, os bits podem mudar de forma que a soma de verificação não se torne inválida; o erro nem será detectado. Então, coisas desagradáveis podem acontecer; mas a alegação de que uma inversão aleatória de bits corromperá instantaneamente seus dados é falsa.

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

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

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

Mas um sistema de arquivos, por si só, nunca pode garantir 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.

Sim, é um problema, principalmente porque os tamanhos das unidades aumentam. A maioria das unidades SATA possui uma taxa de URE (erro incorreto de leitura) 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 em todas as outras partes da unidade. As unidades Enterprise FC e SCSI geralmente têm uma taxa de URE de 10 ^ 15 (120 TB) junto com um pequeno número de unidades SATA, o que ajuda a reduzi-la.

Eu nunca vi discos pararem de girar exatamente ao mesmo tempo, mas tive um volume raid5 que atingiu esse problema (há 5 anos, com unidades PATA de consumidor de 5400 RPM). A unidade falha, é marcada como morta e ocorre uma reconstrução na unidade sobressalente. O problema é que, durante a reconstrução, uma segunda unidade não consegue ler esse pequeno bloco de dados. Dependendo de quem está realizando a invasão, todo o volume pode estar morto ou apenas esse pequeno bloco pode estar morto. Supondo que apenas um bloco esteja morto, se você tentar lê-lo, receberá um erro, mas se escrever nele, a unidade o remapeará para outro local.

Existem vários métodos para se proteger: o raid6 (ou equivalente) que protege contra falhas duplas no disco é o melhor; outros são um sistema de arquivos com reconhecimento de URE, como o ZFS, usando grupos de raides menores, para que, estatisticamente, você tenha uma chance menor de atingir a unidade URE limites (unidades grandes espelhadas ou unidades menores raid5), a limpeza de disco e o SMART também ajudam, mas não são realmente uma proteção em si, mas são usados ​​além de um dos métodos acima.

Eu gerencio quase 3000 eixos em matrizes, e as matrizes estão constantemente limpando as unidades à procura de UREs latentes. E recebo um fluxo razoavelmente constante deles (toda vez que encontra um, o corrige antes da falha da unidade e me alerta), se eu estivesse usando o raid5 em vez do raid6 e uma das unidades estivesse completamente morta ... estar com problemas se atingir determinados locais.

Geralmente, os discos rígidos não codificam os bits de dados como domínios magnéticos únicos - os fabricantes de discos rígidos sempre souberam que os domínios magnéticos poderiam inverter e criar detecção e correção de erros nas unidades.

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

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

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ê precisaria ter um grande número de erros de bits em um único setor, tudo isso ocorrendo antes que o setor fosse lido novamente e os erros teriam que ser tais que os códigos internos de detecção de erros os vejam como dados válidos novamente, antes de você jamais teria um fracasso silencioso. Não é impossível, e tenho certeza que as empresas que operam datacenters muito grandes veem isso acontecer (ou melhor, ocorre e não veem isso acontecer), mas certamente não é um problema tão grande quanto você imagina.

Os discos rígidos modernos (desde 199x) não têm apenas somas de verificação, mas também ECC, que podem detectar e corrigir uma podridão de bits "aleatória". Veja: http://en.wikipedia.org/wiki/SMART .

Por outro lado, certos erros no firmware e nos drivers de dispositivos também podem corromper dados em raras ocasiões (caso contrário, o controle de qualidade detectaria os erros) que seriam difíceis de detectar se você não tiver somas de verificação de nível superior. Os primeiros drivers de dispositivo para SATA e NICs haviam corrompido os dados no Linux e no Solaris.

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

Teoricamente, isso é motivo de preocupação. Na prática, isso é parte do motivo pelo qual mantemos backups filhos / pais / avós. Os backups anuais precisam ser mantidos por pelo menos 5 anos, IMO, e se você tiver um caso disso voltando além disso, obviamente o arquivo não é tão importante.

A menos que você esteja lidando com bits que possam potencialmente liquefazer o cérebro de alguém , não tenho certeza se o risco versus a recompensa está no ponto de alterar os sistemas de arquivos.

Sim, é um problema.

Essa é uma das razões pelas quais o RAID6 está em voga (assim como o aumento do tamanho do HD aumenta o tempo para reconstruir uma matriz). Ter dois blocos de paridade permite um backup adicional.

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

Em relação à declaração do OP sobre o RAID, não entendo quais dados são bons ou ruins.

Os controladores RAID usam no mínimo bits de paridade (ímpares / pares) em cada faixa de dados. Isto é 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 possui distribuição por redundância (RAID 5/6), o controlador pode determinar com precisão se a faixa de dados original foi alterada e se a faixa de dados de redundância foi alterada.

Se você introduzir uma segunda faixa redundante como o RAID6, precisará ter três faixas de dados, em três unidades diferentes, corrompidas, que correspondem aos mesmos dados reais do arquivo. Lembre-se de que a maioria dos sistemas RAID usa faixas de dados relativamente pequenas (128kb ou menos), de modo que as chances de a "podridão de bits" alinhada com os mesmos 128kb, do mesmo arquivo, são praticamente impossíveis.

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

Se você tiver apenas um disco rígido cheio de fotos, pode não valer a pena. Está cheio de dados científicos importantes, pode ser outro tipo de história, você entendeu.