Qual é a granularidade de um URE do disco rígido (erro de leitura irrecuperável)?

tl; dr no caso de ocorrer um URE em um disco rígido, perderei 1bit, 1Byte ou o tamanho de um setor (512Bytes ou 4096 Bytes AF)? e, se possível, explique por que?

Antecedentes: A questão aqui surge quando um disco rígido tem um problema ao ler dados. Certamente um disco pode falhar completamente, deixando todos os seus dados perdidos (DISK FAIL), mas o caso sobre o qual pergunto aqui é quando apenas uma parte menor é perdida (URE, um erro de leitura incorrigível).

Mesmo procurando informações sobre o URE, descobri pouco sobre isso. Isso pode ter sua causa, pois o que acontece internamente na unidade, ou seja, o que está oculto da interação direta do usuário, como a correção de ECCs, é difícil para mim relacionar-me com o que eu acesso como usuário - os setores.

Vamos imaginar que o disco rígido tenha problemas para ler os dados.

Nessa situação, certamente isso deve significar que:

• (a) alguns bits do setor não podem ser lidos, ou
• (b) todos os bits podem ser lidos, mas eles não passam no teste de soma de verificação (é claro que a expectativa de problemas em um setor de 4096 bytes não é apenas 8 * 4096 bits, mas alguns bits / bytes adicionais para verificação / correção de erros (por exemplo, bits de paridade) ) (c) ????

Não, eu acredito que quando estamos na situação em que uma combinação de (a) e (b) ocorreu e uma reconstrução confiável dos bytes do setor 4096 não pode ser feita, é excessivo supor que necessariamente todos eles sejam gargarejos , na verdade, se estivéssemos cientes da lógica de correção de erro do HDD interal, poderíamos dizer "veja se algo não dá certo e, com uma boa alteração, pelo menos 1,2,3, n bits / bytes dos dados do bloco estão" errados " " Se estivéssemos salvando redundantemente "olá, olá ....., olá" seqüências de bytes ASCII nesse setor, na verdade ainda poderíamos ter uma sucessão justa de "olá, olá ..." antes que exista um ... Uellohello ... "(ou seja," e "->" U ").

Então, qual é a granularidade de um URE?

UPDATE: houve um comentário inserindo a idéia de setor ruim (e sugerindo que isso reflete a granularidade de um evento URE. Não é absurdo sugeri-lo e talvez possa ser usado para responder à pergunta. No entanto, acabei de ler outro artigo relacionado pergunta sobre setores ilegíveis pendentes (aqui /unix/1869/how-do-i-make-my-disk-unmap-pending-unreadable-sectors ), o que me leva a pensar que em alguns Nos cenários, há de fato uma linha mais embaçada entre os dados perdidos no caso de um URE.

O código de correção de erros em um disco rígido é um pedaço adicional de dados associado a cada setor de hardware. Durante a gravação, o firmware da unidade calcula esses dados e os grava junto com os dados do usuário. Durante a leitura, o firmware lê o ECC junto com os dados e os verifica juntos.

Para um disco rígido tradicional, o setor de hardware é de 512 bytes. Para uma unidade de formato avançado, são 4 bytes de 4K (não importa se a unidade está apresentando setores de 512 bytes ou 4K bytes na interface, por exemplo, 512e vs. 4kn).

O resultado da verificação após uma leitura tem basicamente três resultados possíveis:

• setor foi lido sem erros. Na verdade, isso não é completamente comum nos discos rígidos modernos; as densidades de bits são tais que dependem do funcionamento do ECC.

• setor foi lido com erros corrigíveis. Como está implícito acima, isso não é incomum; é esperado. O inversor retorna os dados, com a correção de erros aplicada, ao usuário.

• setor foi lido, mas havia muitos "bits errados"; os erros não puderam ser corrigidos.

Neste último caso, a unidade normalmente não retorna nenhum conteúdo; apenas retorna um status indicando o erro. Isso ocorre porque não é possível saber quais bits são suspeitos, muito menos quais devem ser seus valores. Portanto, todo o setor (bits de ECC e tudo) não é confiável. É impossível determinar qual parte do setor ruim é ruim, muito menos qual deve ser seu conteúdo. O ECC é uma "gestalt" calculada em todo o conteúdo do setor e, se não corresponder, é o setor inteiro que não corresponde.

O SpinRite funciona simplesmente tentando ler o setor defeituoso repetidamente, usando uma função "manutenção de leitura" que retorna os dados (mas sem bits ECC), mesmo que a unidade diga "erro incorrigível". Como dito na descrição vinculada por DavidPostill, pode ser bem-sucedido com uma leitura sem erros (na verdade, é mais provável que "corrigível"); ou pode deduzir, essencialmente calculando a média dos bits retornados, uma estimativa razoável do conteúdo do setor. Ele não tem mais capacidade de corrigir erros com precisão usando o ECC do que a unidade; isso é matematicamente impossível.

Qual é a granularidade de um URE?

Erros de leitura irrecuperáveis ​​(URE) são falhas de leitura do setor. Se o setor não puder ser lido sem erros, não importa se era apenas 1 byte ou todos os bytes do setor.

A granularidade é o tamanho do setor .

Mesmo que apenas 1 byte falhe, você normalmente não recuperará nenhum dado desse setor sem usar um software especializado.

Os dados de um setor com falha podem ser recuperados?

SpinRite diz:

O SpinRite é capaz de recuperar a maioria dos dados em um setor que nunca pode ser perfeitamente lido e que qualquer outro software utilitário descarta por completo.

Veja Como o SpinRite recupera dados ilegíveis .

Aviso Legal.

Não sou afiliado ao SpinRite de forma alguma e nunca o usei.

Não existe algo como "não consigo ler um pouco", a menos que você tenha um erro de hardware realmente grave, como a cabeça não conseguir procurar a trilha correta ou a trilha servo estiver danificada e o setor correto não possa ser encontrado . Obviamente, em ambos os casos, você teria, no mínimo, todo um setor ilegível.

Caso contrário, você sempre recupera os bits, eles são possivelmente bits incorretos . É aqui que entra o código de correção de erros; ele adiciona um número extra de bits ECC a todos os setores, de forma que qualquer combinação correta de bits de dados e bits ECC observe alguma regra algébrica. Se todos os bits foram lidos corretamente, o código será validado e os dados poderão ser retornados diretamente. Se um pequeno número de bits foi lido incorretamente, o código ECC pode ser usado para determinar exatamente quais e corrigi-los, para que todos os dados sejam transmitidos corretamente. Se um número maior de bits foi lido de forma incorrecta, o código ECC pode detectar que não foi um erro, mas já não tem informação suficiente para descobrir o que os bits estão incorretas; este é um erro de leitura incorrigível. Se umSe um número muito grande de bits for lido incorretamente, o código poderá ser validado corretamente "por acidente" e a unidade retornará dados corrompidos, mas com bits ECC suficientes, a probabilidade de que isso aconteça pode ser tão pequena quanto você desejar.

Então, para responder à pergunta que acho que você estava respondendo - se houve um erro de leitura parcial, mas havia informações suficientes disponíveis para descobrir onde o erro ocorreu, ele também pode ser corrigido e o computador não verá nenhum erro . Isso realmente acontece constantemente. Um erro não corrigido ocorre quando não é possível descobrir quais bits de dados são válidos e quais não são, e como o código de correção de erros é calculado em um setor, isso ocorre na granularidade do setor.

Tendo analisado e inspirado pela resposta https://superuser.com/a/969917/160771 de https://superuser.com/users/337631/davidpostill

Gostaria de responder a apresentar uma resposta alternativa um tanto extensa. Primeiro, é verdade que o disco rígido e seu firmware são a origem de um evento URE, ou seja, o evento em que os dados não podem ser lidos. Além disso, é verdade que os dados são gravados no disco em setores de 512 ou 4096 bytes de dados utilizáveis ​​e cerca de 50 ou 100 bytes adicionais de dados extras, o que deve permitir a verificação e correção de erros.

Falar sobre um URE acontece, portanto, naturalmente no contexto de um setor de disco rígido. O termo setor ruim certamente está um pouco vinculado, mas não é idêntico à situação atual quando temos um setor de URE.

Um setor com alguns problemas para ser lido sem erros não é necessariamente completamente sem sentido. Pode ser que, de fato, todos os 4096 dados tenham sido corrompidos, mas também pode ser que apenas 1 bit a mais do que possa ser corrigido de forma confiável (através dos dados extras redundantes do ECC adicionados a cada setor) esteja corrompido.

Em alguns casos, nos quais apenas alguns poucos bytes a mais que o disco rígido foi capaz de corrigir foram corrompidos, há alterações na fração dos 4096 bytes ainda com dados significativos.

Um exemplo pode ser que o 4096 represente os caracteres ASCII de 2 sentenças. Então é possível que uma ou mais frases esteja completamente intacta. Também é possível que todas as letras 2 ou 3 tenham sido excluídas. Se os dados de 4096 forem perdidos em um evento de URE, depende da interpretação e depende dos dados. Pode-se imaginar que os dados em si tinham outra camada de shell ECC, o que permitiria uma recuperação adicional.

Portanto, é bom que a maioria dos firmwares trate os setores de URE de maneira diferente dos setores ruins:

Normalmente, o remapeamento automático de setores só acontece quando um setor é gravado. A lógica por trás disso é presumivelmente que, mesmo que um setor não possa ser lido normalmente, ele ainda poderá ser lido com métodos de recuperação de dados. (de https://en.wikipedia.org/wiki/Bad_sector )

Ou, até certo ponto, pode ser que uma parte do setor ainda contenha dados utilizáveis.