Eu escrevia o firmware do disco para a WD e uma vez escrevi o firmware que transferia os blocos defeituosos.
Primeiro, a maioria dos blocos defeituosos é detectada nas leituras, não nas gravações. As gravações são feitas às cegas, o que significa que os dados são gravados sem serem verificados. Assim, em uma gravação, se a mídia for ruim, você não saberá até que o host faça uma leitura para esse setor. Há uma pequena parte do setor (o cabeçalho do setor) que é lido nas gravações para localizar o setor correto, de modo que, se houver um erro na leitura do cabeçalho do setor, a unidade irá reatribuir o setor e gravá-lo com os dados recebidos do comando write. Mas a grande maioria dos blocos defeituosos é detectada nas leituras, e apenas porque uma gravação é bem-sucedida em um setor não significa que a mídia seja boa ou que o setor tenha sido reatribuído.
Agora, sobre a reatribuição de bloco inválida (também chamada de realocação). Sim, normalmente a unidade tentará reatribuir um setor se o erro for ruim o suficiente (ou seja, a falha do ECC for ruim o suficiente), mas a unidade ainda poderá recuperar os dados após a correção do ECC. Geralmente isso é feito automaticamente. A única exceção é que o host poderia ter dito anteriormente à unidade para não fazer realocações automáticas, mas isso raramente é feito.
Então, o que acontece se a unidade faz uma leitura e não consegue recuperar os dados? Nada. O erro é relatado ao host, mas nenhuma reatribuição é feita. O problema é que a unidade pode reatribuir o setor, mas não tem a menor idéia de quais dados gravar no setor reatribuído. Se apenas digitasse zeros, digamos, e o setor fosse lido novamente, retornaria todos os zeros sem nenhuma indicação de que os dados não eram válidos. Isso é essencialmente a mesma coisa que corrupção de dados. A unidade não pode contar com o host acompanhando os erros por vários motivos (por exemplo, e se a unidade foi movida para um novo host?), Portanto, o melhor curso de ação é não fazer nada quando os dados puderem ' Não seja recuperado.
As unidades modernas, no entanto, salvarão a localização do setor defeituoso quando ele não puder ser realocado. O número de setores defeituosos que aguardam realocação pode ser encontrado nos dados SMART. O que acontece é que, se uma gravação é feita em um dos setores defeituosos que aguardam realocação, a realocação é feita porque a unidade agora possui dados válidos para gravar após a realocação. Assim, quando as pessoas dizem que escrever para um setor ruim irá realocá-lo, isso é apenas metade da história. A unidade deve ser lida primeiro, para descobrir todos os setores defeituosos que não podem ser realocados automaticamente. Assim, você pode gravar uma unidade inteira e os dados SMART dirão que não há setores defeituosos aguardando realocação, mas você não limpou necessariamente a unidade de todos os setores defeituosos. Então, se você realmente deseja limpar todos os setores defeituosos,
Existem outras maneiras de lidar com blocos defeituosos que não podem ser realocados. Se a unidade fizer parte de uma configuração RAID redundante (ou seja, qualquer coisa menos RAID 0), o software RAID deve recuperar automaticamente os dados de um setor defeituoso das outras unidades e gravá-los no setor realocado. Os discos SCSI têm um comando explícito de reatribuição de blocos que o host pode usar para forçar a reatribuição mesmo quando não há dados válidos para gravar no bloco, mas seu uso é de nível bastante baixo.