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

9

Eu tenho uma unidade que informa que os setores pendentes atuais são "45". Eu usei badblocks para identificar os setores e tenho tentado escrever zeros para eles com dd .

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

No entanto, neste disco, os valores brutos Reallocated_Sector_Ct e Reallocated_Event_Count são 0, e dd falha com erros de E / S quando tento gravar zeros nos setores defeituosos. 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 sobressalentes a serem usados para realocação? A minha unidade é, em geral, uma pessoa terrível? (A unidade não é realmente minha, eu estou ajudando um amigo. Eles podem ter acabado de ter uma unidade barata ou algo assim.)

Caso seja relevante, aqui está a saída de 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 shred no disco, o que fez com que Current_Pending_Sector fosse zerado. No entanto, Reallocated_Sector_Ct e Reallocated_Event_Count ainda são zero e dd agora é capaz de gravar dados para os setores que anteriormente não conseguiu. Isso me leva a várias outras perguntas:

  • Por que as realocações não estão sendo registradas pelo disco? Estou assumindo que a realocação ocorreu, já que agora posso escrever dados diretamente para o setor e não consegui antes.

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

por MetaNova 19.10.2013 / 00:56

2 respostas

8

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 desta unidade é de 4 KiB, e o tradicional tamanho de setor de 512 bytes é apenas emulado. Por causa disso, se um único setor físico de 4 KiB ficar ruim, todos os 8 setores emulados correspondentes de 512 bytes ficarão ilegíveis de uma vez.

(A saída Sector Size: 512 bytes logical/physical de smartctl não está correta, porque algumas unidades WD15EARS reportam tamanho de setor físico errado - aparentemente, sua unidade possui uma versão de firmware que está quebrada a esse respeito.

Além disso, quando um único setor de 512 bytes emulado é gravado, a unidade 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 for boa, essa operação de leitura-modificação-gravação causará uma lentidão significativa em comparação a 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 completamente o setor falhará. Por causa disso, você não pode forçar a realocação do setor em tais unidades usando dd com bs=512 count=1 - você deve usar pelo menos bs=512 count=8 e certificar-se de que o número do setor na opção seek= seja um múltiplo de 8. (Este assume que o jumper “Compatível com Windows XP” não está instalado, caso contrário, o deslocamento de alinhamento adicionado por este jumper também deve ser levado em consideração.)

Outra razão para forçar a realocação com dd pode ser que, por padrão, o Linux use 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, que também falhará um setor ilegível é encontrado. Você pode adicionar a opção oflag=direct para ignorar esse cache para o dispositivo especificado por of=... (há também a opção iflag=direct , que se aplica ao dispositivo de entrada).

    
por 19.10.2013 / 18:21
0

Eu tive que fazer isso recentemente e descobri que executar o fragmento em todo o disco funcionou muito bem. Embora o fragmento seja inútil para o propósito a que se destina, exceto em disquetes, ele faz exatamente o que é necessário para fazer com que a autocura atinja blocos ruins.

    
por 02.02.2014 / 21:37