Eu tenho que dizer que esta é uma pergunta justa. Eu posso entender a natureza de suas expectativas e acreditar que elas sejam coerentes - em algum momento eu estava com a mesma impressão.
Primeiro, em relação à temperatura: acredito que os dados sobre 99C estão errados. Isso já é superaquecimento extremo. A temperatura normal de operação, para um disco rígido, é de cerca de 20-45 * C (55 * C para modelos de maior capacidade). Qualquer coisa acima desses limites e a mecânica da unidade começam a degradar muito mais rapidamente. O calor faz com que o metal se expanda - o primeiro a sofrer seria o HSA (HeadStackAssembly). Como as cabeças flutuam sobre o prato (devido ao rolamento de ar) em altitudes extremamente baixas (mas ainda não tocando a superfície dos pratos) - você pode ver o quanto isso pode resultar, se algo, exatamente assim, começar a deformar . É por isso que você deve sempre fornecer resfriamento adequado. Além disso, há uma diferença entre a temperatura dentro do HDA (HardDiskAssembly, basicamente o ambiente temporário próximo às cabeças) - isto é, Seagate fornece um atributo SMART apenas para isso.
Agora, responda sua pergunta. A questão é que apenas os casos mais triviais são tratados automaticamente. Normalmente, você não terá setores realocados em uma operação de leitura. Apenas em uma gravação. Se houver dificuldades em ler um setor (somas de verificação incompatíveis), mas os dados foram recuperados com êxito por ECC , ele simplesmente deixa o setor sozinho, sem fazer nada.
Então, basicamente, se você substituísse a unidade inteira com zeros - somente então o firmware da unidade teria remapeado os setores problemáticos para os reservados e diminuiria o valor do atributo SMART # 197 . O raciocínio aqui é que o mecanismo ECC da unidade tenta corrigir o erro e quando ele falha após uma série de tentativas no setor em questão (percebido como tempo limite) - ele simplesmente sinaliza o setor como UNC (incorrigível, também conhecido como bad block). O problema aqui é que ele não sabe mais como lidar com seus dados! E não deveria, como esta já é sua chamada. Você terá que tomar uma decisão - adiar e tentar de alguma forma recuperar os dados naquele setor mais tarde ou, em vez disso, substituí-los e causar realocação. Obviamente, apenas uma dessas coisas pode ser feita automaticamente e é por isso que não é.
O que você está fazendo com mkfs é apenas escrever metadata , que será colocado em setores específicos. Ele não preencherá a unidade inteira (portanto, talvez nunca encontre nenhum dos setores defeituosos atuais). No entanto, um preenchimento com zero seria.
Em suma, a unidade está se deteriorando visivelmente. Eu recomendaria uma passagem de dd (se = / dev / zero), se você ainda quiser respirar alguma (curta) vida nele.