Não é possível gravar zeros em setores defeituosos / disco rígido sem contar setores realocados

Eu tenho uma unidade que está relatando que os setores pendentes atuais são "45". Usei badblocks para identificar os setores e tentei escrever zeros neles com dd .

Pelo que entendi, quando tento gravar dados diretamente nos setores defeituosos, ele deve desencadear uma realocação, reduzindo os setores pendentes atuais em um e aumentando a contagem do setor realocado.

No entanto, neste disco, os valores brutos Reallocated_Sector_Ct e Reallocated_Event_Count são 0 e o dd falha com erros de E / S quando tento gravar zeros nos setores defeituosos. O dd funciona bem, no entanto, quando escrevo para um bom setor.

# dd if=/dev/zero of=/dev/sdb bs=512 count=1 seek=217152
dd: error writing ‘/dev/sdb’: Input/output error

Isso significa que minha unidade, de alguma forma, não possui setores extras para serem realocados? Em geral, minha unidade é uma pessoa terrível? (A unidade não é realmente minha, estou ajudando um amigo. Eles podem ter comprado uma unidade barata ou algo assim.)

Caso seja relevante, aqui é a saída do smartctl -i :

Model Family:     Western Digital Caviar Green (AF)
Device Model:     WDC WD15EARS-00Z5B1
Serial Number:    WD-WMAVU3027748
LU WWN Device Id: 5 0014ee 25998d213
Firmware Version: 80.00A80
User Capacity:    1,500,301,910,016 bytes [1.50 TB]
Sector Size:      512 bytes logical/physical
Device is:        In smartctl database [for details use: -P show]
ATA Version is:   ATA8-ACS (minor revision not indicated)
SATA Version is:  SATA 2.6, 3.0 Gb/s
Local Time is:    Fri Oct 18 17:47:29 2013 CDT
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

UPDATE:
Eu executei shredno disco, o que fez com que o Current_Pending_Sector fosse zero. No entanto, Reallocated_Sector_Ct e Reallocated_Event_Count ainda são zero, e o dd agora pode gravar dados nos setores aos quais era incapaz anteriormente. Isso me leva a várias outras perguntas:

• Por que as realocações não estão sendo gravadas pelo disco? Estou assumindo que a realocação ocorreu, pois agora eu posso gravar dados diretamente no setor e não consegui antes.

• Por que o shred causou realocação e não o dd? O fato de o shred gravar dados aleatórios em vez de apenas zeros faz alguma diferença?

A unidade WD15EARS (e a maioria das outras unidades produzidas recentemente) usa o formato avançado , o que significa que o tamanho real do setor físico dessa unidade é de 4 KiB, e o tamanho tradicional do setor de 512 bytes é apenas emulado. Por esse motivo, se um único setor físico de 4 KiB ficar ruim, todos os 8 setores emulados de 512 bytes emulados correspondentes ficarão ilegíveis ao mesmo tempo.

(A Sector Size: 512 bytes logical/physicalsaída de smartctlnão está correta, porque algumas unidades WD15EARS relatam um tamanho incorreto do setor físico  - aparentemente sua unidade possui uma versão de firmware quebrada nesse sentido.)

Além disso, quando um único setor emulado de 512 bytes é gravado, a unidade de Formato Avançado realmente precisa ler todo o setor físico de 4 KiB, alterar a parte correspondente de 512 bytes e gravar todo o setor físico na mídia. Se a mídia estiver boa, essa operação de leitura-modificação-gravação apenas causa uma desaceleração significativa em comparação com uma unidade com setores físicos reais de 512 bytes. No entanto, se o setor físico de 4 KiB estiver ruim e não puder ser lido, qualquer operação de gravação que não reescreva o setor completamente falhará. Devido a isso, você não pode forçar a realocação setor em tais unidades usando ddcom bs=512 count=1 - você deve usar pelo menos bs=512 count=8e certifique-se de que o número do setor noseek= A opção é um múltiplo de 8. (Isso pressupõe que o jumper "Windows XP Compatible" não esteja instalado, caso contrário, o deslocamento de alinhamento adicionado por esse jumper também deverá ser levado em consideração.)

Outra razão pela qual forçar a realocação ddpode falhar é que, por padrão, o Linux usa um cache na camada de bloco para acessar dispositivos de bloco, e isso pode causar operações de leitura-modificação-gravação no software, o que também falharia quando um setor ilegível fosse encontrado. Você pode adicionar a oflag=directopção de ignorar esse cache para o dispositivo especificado por of=...(também existe a iflag=directopção que se aplica ao dispositivo de entrada).

Eu tive que fazer isso recentemente e descobri que a execução do shred em todo o disco funcionava muito bem. Embora o fragmento seja inútil para o objetivo a que se destina, exceto em disquetes, ele faz exatamente o necessário para obter a autocura em blocos ruins.