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

Question

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

Histórico: A questão aqui surge quando um disco rígido apresenta um problema ao ler os dados. Certamente um disco pode falhar completamente deixando todos os seus dados perdidos (DISK FAIL), mas o caso que eu pergunto aqui sobre é que quando apenas uma pequena parte dele é perdida (URE, um erro de leitura incorrigível) .

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

Vamos imaginar que o disco rígido tenha problemas para ler 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 um teste de soma de verificação (claro que esperar um problema 4096 Byte não é apenas 8 * 4096 bits, mas alguns bits / bytes adicionais para verificação / correção de erros ( ou seja, bits de paridade) (c) ????

Não 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, então é excessivo assumir que necessariamente todos eles são garpage, na verdade, se estivéssemos cientes da lógica de correção de erro interal hdd poderíamos dizer "olha algo não faz check-out, e com uma boa mudança pelo menos 1,2,3, n bits / bytes dos dados do bloco é "errado"". Se nós estivéssemos salvando redundantemente "olá, olá ....., olá" cordas de bytes ASCII neste setor nós na verdade ainda poderíamos ter uma sucessão justa de "olá, olá ...." antes de haver um "... Uellohello ... "(ou seja," e "- >" U ").

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

ATUALIZAÇÃO: tem havido um comentário inserindo a idéia de setor ruim (e sugerindo que isso reflete a granularidade de um evento de URE. Não é absurdo, sugerir isso e talvez possa ser usado para responder à pergunta. No entanto, acabei de ler outra pergunta relacionada perguntando sobre setores ilegíveis pendentes (aqui link ) o que me leva a pensar que em alguns cenários há de fato uma linha mais embaçada entre os dados perdidos no caso de um URE.

    

Answer 1

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 juntamente 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, é de 4K bytes (não importa se a unidade está apresentando setores de 512 ou 4 bytes na interface, ou seja, 512e vs. 4kn).

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

• o setor foi lido sem erro. Isso na verdade não é completamente comum nos discos rígidos modernos; as densidades de bits são tais que dependem do trabalho de ECC.

O setor

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

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

No último caso, a unidade normalmente não retorna qualquer 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 ECC e tudo) não é confiável. É impossível determinar qual parte do setor ruim é ruim, e muito menos qual deve ser seu conteúdo. O ECC é um "gestalt" que é calculado em todo o conteúdo do setor e, se não corresponder, é todo o setor que não é correspondido.

O SpinRite funciona simplesmente tentando ler o setor defeituoso várias vezes, usando uma função de "leitura de manutenção" que retorna os dados (mas sem bits ECC), mesmo que a unidade diga "erro incorrigível". Como dito na descrição linkada por DavidPostill, ele pode ter sucesso com uma leitura livre de erro (na verdade, "corrigível" é mais provável); ou pode ser capaz de deduzir, essencialmente pela média dos bits retornados, uma estimativa razoável do conteúdo do setor. Não tem mais capacidade de corrigir com precisão erros usando o ECC do que a unidade; isso é matematicamente impossível.

    

Answer 2

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 erro, não importa se era apenas 1 byte ou todos os bytes do setor.

A granularidade é o tamanho do setor .

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

Os dados de um setor com falha podem ser recuperados?

SpinRite diz:

SpinRite is even able to recover most of the data in a sector that can never be perfectly read, and which any other utility software discards in full.

Veja Como o SpinRite recupera dados ilegíveis .

Isenção de responsabilidade.

Eu não sou afiliado com o SpinRite de nenhuma forma, e nunca o usei.

    

Answer 3

Não existe algo como "não é possível ler um pouco", a menos que você tenha um erro de hardware muito grave, como a falta de capacidade de procurar a trilha correta ou a faixa do servo danificada e o setor correto. t ser encontrado. Obviamente, em ambos os casos, você teria, no mínimo, todo um setor ilegível.

Caso contrário, você sempre recebe bits de volta, eles são apenas possivelmente incorretos bits. É aí que entra o código de correção de erros; Ele adiciona um número extra de bits ECC a cada setor, de modo que qualquer combinação correta de bits de dados e bits ECC observa alguma regra algébrica. Se todos os bits foram lidos corretamente, o código será validado e os dados poderão ser repassados diretamente. Se um pequeno número de bits foi lido incorretamente, o código ECC pode ser usado para determinar exatamente quais deles e corrigi-los, para que todos os dados sejam repassados corretamente. Se um número maior de bits foi lido incorretamente, o código ECC pode detectar que era um erro, mas não tem mais informações suficientes para descobrir quais bits estão incorretos; este é um erro de leitura incorrigível. Se um muito grande número de bits for lido incorretamente, então o código pode validar corretamente "por acidente" e a unidade retornará dados corrompidos, mas com bits ECC suficientes a probabilidade disso acontecer pode ser feita como pequeno como você gosta.

Então, para responder à pergunta que você estava perguntando - se houve um erro de leitura parcial, mas informações suficientes estavam disponíveis para descobrir onde o erro ocorreu, ele também pode ser corrigido e o computador não verá erro em tudo. Isso realmente acontece constantemente. Um erro não corrigido acontece 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 sobre um setor, isso acontece na granularidade do setor.

    

Answer 4

Tendo analisado e inspirado na resposta link de link

Gostaria de responder ao presente uma resposta alternativa um pouco extensa. Primeiro, é verdade que o disco rígido e seu firmware são a origem de um evento URE, que é o evento em que os dados não podem ser lidos. Além disso, é verdade que os dados são gravados em disco em setores de 512 ou 4096 bytes de dados utilizáveis e cerca de 50 ou 100 bytes de dados extras que devem 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 ligado, mas não é idêntico à situação em questão quando temos um setor de URE.

Um setor com alguns problemas para serem lidos 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 foi corrigido de forma confiável (através dos dados extra ECC adicionais adicionados a cada setor) foi corrompido.

No casese, em que apenas alguns poucos bytes a mais do que o hdd foi capaz de corrigir foram corrompidos, há alterações que a fração dos 4096 Bytes ainda possui dados significativos.

Um exemplo poderia ser que o 4096 representa os charts ASCII de 2 sentenças. Então é possível que o hat 1 sentença ou mais esteja completamente intacto. Também pode ser possível que cada segunda ou terceira letra tenha sido eliminada. Se os dados de 4096 forem perdidos em um evento de URE, fica por conta 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 defeituosos:

Typically, automatic remapping of sectors only happens when a sector is written to. The logic behind this is presumably that even if a sector cannot be read normally, it may still be readable with data recovery methods. (from https://en.wikipedia.org/wiki/Bad_sector)

Ou, até certo ponto, pode ser que uma parte do setor ainda contenha dados úteis.