Depende.
No dia a dia, seu disco rígido grava uma soma de verificação e algumas informações de ECC para cada setor sendo gravado e verifica esses dados durante uma operação de leitura.
Se o erro for pequeno o suficiente (por exemplo, um bit invertido ou outros erros menores) para ser coberto pelos recursos de ECC do disco rígido, o disco rígido poderá se recuperar sozinho. O erro corrigido ainda pode estar visível na saída SMART, mas o sistema operacional ou o controlador de RAID de hardware não percebeu um erro de leitura.
Caso contrário, o disco rígido reportará um erro de leitura irrecuperável ao seu controlador e marcará internamente o setor como sendo quebrado. A tentativa de gravar dados no mesmo setor (lógico) permite que seu disco rígido aloque um setor de substituição de uma lista de setores reservados e mapeie de forma transparente o acesso do setor lógico para o novo setor físico (de substituição). Sua solicitação de gravação será armazenada em diferentes setores físicos, corrigindo o erro para você.
Se o disco estiver fora dos setores de substituição, isso também falhará e você não poderá mais se recuperar disso apenas reescrevendo o mesmo setor lógico.
Os controladores de hardware raid normalmente tentam descobrir tais setores com falha "antes" do que um acesso de leitura usual executando varreduras de mídia em segundo plano, autotestes programados e verificando a precisão da paridade de raid armazenada.
Se o erro está sendo corrigido, reescrevendo o mesmo setor é uma história diferente, o campo é em grande parte indocumentado e, principalmente, até a experiência pessoal de alguém. Apenas a partir da minha experiência de 15 anos em dezenas de milhares de servidores executando dezenas de controladores de ataque de hardware de meia dúzia de fornecedores diferentes:
- alguns fornecedores sempre executam verificações de mídia em segundo plano e tentam silenciosamente corrigir os blocos inválidos automaticamente. A HP / Compaq está desse lado.
- alguns fornecedores fazem da mídia permanente em segundo plano uma opção, que deve ser especificamente ativada (e padronizada como "desligada" após a energização).
- alguns fornecedores oferecem a verificação de mídia em segundo plano como uma operação única, que é para ser acionado manualmente por meio de uma interface administrativa ou CLI
- alguns fornecedores quebram ainda mais.
Como exemplo de "break even more", há cerca de 10 anos tive sérios problemas em uma configuração RAID 10 em um tipo de controlador específico: ocasionalmente, os dados do sistema de arquivos e do aplicativo foram danificados. Uma investigação mais detalhada e a introdução de uma soma de verificação no nível do aplicativo mostraram que, às vezes, zeros foram lidos, mas dados não zerados são esperados.
Culpado: ao ler de um bloco defeituoso, o controlador registrou isso como um erro, mas não se recuperou da cópia de trabalho. Em vez disso, ele relatou que a faixa de dados em torno de 8k era uma faixa de zeros e a operação de leitura seria bem-sucedida. O comportamento foi reproduzível em > 100 controladores e o suporte ao cliente do fornecedor até afirmaram que isso é perfeitamente aceitável, já que o RAID recuperava apenas a falha total do disco e não lidava com a falha de blocos individuais.
Em uma configuração RAID4 / RAID5, o mesmo controlador se recuperaria da redundância RAID e entregaria a faixa recuperada ao sistema operacional, mas não recuperaria o bloco danificado no disco automaticamente. Para recuperar-se do bloco defeituoso, era necessário reescrever o mesmo bloco lógico no nível do sistema operacional ou emitir uma operação de "regeneração de paridade" na interface administrativa. A mais recente faria a varredura de todos os discos, verificaria checksums de paridade de RAID e tentaria recuperar os bad blocks, reescrevendo qualquer bloco com um erro de leitura ou uma falha na paridade de RAID.
No outro extremo, a Compaq / HP tem feito varreduras em segundo plano em seus controladores RAID por muito tempo, e se o bloco / setor não puder ser recuperado automaticamente da paridade ou algo parecido com suspeito, o controlador registraria isso, iniciar piscar os LEDs das unidades afetadas e tentar alertar o administrador (por exemplo, por uma tela de mensagem irritante durante o POST). Eu não ouvi falar de nenhum problema de bloqueio ruim em nossa frota atual de cerca de 10k de controladores HP Smart Array, incluindo cerca de 1100 P800s. No entanto, essa é apenas a minha experiência.