Tentando remover / diagnosticar um único Current_Pending_Sector nos dados SMART

Estou no processo de fazer uma nova instalação do Linux e, antes de fazer isso, pensei que era um bom momento para verificar a integridade do disco rígido, pois posso substituir com segurança quaisquer dados no disco rígido, se necessário.

Primeiro, tentei verificar com smartmontools ... Meu HD da Seagate relata um setor pendente atual e um offline incorrigível (presumivelmente o mesmo). A contagem do setor realocado é zero.

5 Reallocated_Sector_Ct   0x0033   100   100   036    Pre-fail  Always       -       0
...
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       1
198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -       1

No entanto, os autotestes SMART (curto, longo, offline, transporte) não encontram erros.

SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Extended offline    Completed without error       00%      6631         -
# 2  Conveyance offline  Completed without error       00%      6630         -
# 3  Extended offline    Completed without error       00%      6622         -
# 4  Short offline       Completed without error       00%      6600         -
# 5  Extended offline    Completed without error       00%      6632         -

Eu também tentei executar badblocks -wsv (teste completo de aprovação de gravação e gravação de 4 padrões) na unidade e nenhum bloco defeituoso foi encontrado. Segui o guia (na medida do possível, desde que excluí meu sistema de arquivos após executar badblocks) encontrado aqui: http://smartmontools.sourceforge.net/badblockhowto.html

Lá diz que se eu sobrescrever o setor com todos os zeros, o disco deve mover (realocar) o setor pendente. O último padrão de gravação de badblocks é zeros, portanto, isso deveria ter sido feito. no entanto, nada mudou. Ainda tenho essa contagem de setor pendente 1.
Tentei descobrir qual setor é problemático e, na saída SMART, há um log de erros:

Error 2 occurred at disk power-on lifetime: 5344 hours (222 days + 16 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  84 51 7c 1b 1a 02 ae  Error: ABRT at LBA = 0x0e021a1b = 235018779

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  20 20 7f 18 1a 02 ae 00      00:09:05.228  READ SECTOR(S)
  20 20 01 17 1a 02 ae 00      00:09:05.228  READ SECTOR(S)
  20 20 01 01 00 00 a0 00      00:08:59.830  READ SECTOR(S)
  91 20 3f 01 00 00 af 00      00:08:59.826  INITIALIZE DEVICE PARAMETERS [OBS-6]
  10 20 01 01 00 00 a8 00      00:08:59.678  RECALIBRATE [OBS-4]

Error 1 occurred at disk power-on lifetime: 5009 hours (208 days + 17 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  40 51 00 b7 8c 02 e0  Error: UNC at LBA = 0x00028cb7 = 167095

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  25 20 1e 9e 8c 02 e0 00      00:02:20.691  READ DMA EXT
  25 20 1e 80 8c 02 e0 00      00:02:20.691  READ DMA EXT
  25 20 1e 62 8c 02 e0 00      00:02:20.690  READ DMA EXT
  25 20 1e 44 8c 02 e0 00      00:02:20.690  READ DMA EXT
  25 20 1e 26 8c 02 e0 00      00:02:20.690  READ DMA EXT

Então, aparentemente, a unidade teve dois erros.

84 51 7c 1b 1a 02 ae  Error: ABRT at LBA = 0x0e021a1b = 235018779

e

40 51 00 b7 8c 02 e0  Error: UNC at LBA = 0x00028cb7 = 167095

Então, assumi que estes são os números do setor: 167095 e 235018779. E tentei escrever zeros com dd:

dd if=/dev/zero of=/dev/sda bs=512 count=1 seek=167095

Agora que um fez ok. No entanto, quando tentei com o outro setor:

dd if=/dev/zero of=/dev/sda bs=512 count=1 seek=235018779

Eu recebo dd: '/ dev / sda': não é possível procurar: argumento inválido . Vi então que meu HDD tem apenas 234441658 setores. Então, isso está fora de alcance. Mas então por que a SMART relatou um erro nesse endereço ?!

Alguém pode me ajudar a descobrir isso e também me aconselhar como fazer isso corretamente se eu estiver fazendo errado? Eu suspeito que talvez eu esteja errado ao usar o tamanho do bloco 512 com dd. Esse é o tamanho do setor relatado pela SMART. talvez esses endereços LBA sejam bytes, não blocos. Tentei definir bs = 1 e escrever apenas um byte para esses endereços no disco rígido. Isso funcionou (processo de gravação de dd) ... No entanto, a contagem de setores pendentes ainda não mudou depois disso. Também chamei sync e smartctl -t offline / dev / sda para tentar 'forçar' a unidade a realocar o setor. Nada...

Aqui está minha saída smartctl --all / dev / sda completa :

smartctl 5.43 2012-06-30 r3573 [i686-linux-2.6.32-358.el6.i686] (local build)
Copyright (C) 2002-12 by Bruce Allen, http://smartmontools.sourceforge.net

=== START OF INFORMATION SECTION ===
Model Family:     Seagate Barracuda 7200.9
Device Model:     ST3120811AS
Serial Number:    6PT1N4VZ
Firmware Version: 3.AAE
User Capacity:    120,034,123,776 bytes [120 GB]
Sector Size:      512 bytes logical/physical
Device is:        In smartctl database [for details use: -P show]
ATA Version is:   7
ATA Standard is:  Exact ATA specification draft version not indicated
Local Time is:    Mon Nov 18 12:03:00 2013 UTC
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

General SMART Values:
Offline data collection status:  (0x82) Offline data collection activity
                    was completed without error.
                    Auto Offline Data Collection: Enabled.
Self-test execution status:      (   0) The previous self-test routine completed
                    without error or no self-test has ever 
                    been run.
Total time to complete Offline 
data collection:        (  430) seconds.
Offline data collection
capabilities:            (0x5b) SMART execute Offline immediate.
                    Auto Offline data collection on/off support.
                    Suspend Offline collection upon new
                    command.
                    Offline surface scan supported.
                    Self-test supported.
                    No Conveyance Self-test supported.
                    Selective Self-test supported.
SMART capabilities:            (0x0003) Saves SMART data before entering
                    power-saving mode.
                    Supports SMART auto save timer.
Error logging capability:        (0x01) Error logging supported.
                    General Purpose Logging supported.
Short self-test routine 
recommended polling time:    (   1) minutes.
Extended self-test routine
recommended polling time:    (  51) minutes.

SMART Attributes Data Structure revision number: 10
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000f   084   077   006    Pre-fail  Always       -       185600113
  3 Spin_Up_Time            0x0003   095   095   000    Pre-fail  Always       -       0
  4 Start_Stop_Count        0x0032   098   098   020    Old_age   Always       -       2185
  5 Reallocated_Sector_Ct   0x0033   100   100   036    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x000f   073   055   030    Pre-fail  Always       -       25890559714
  9 Power_On_Hours          0x0032   093   093   000    Old_age   Always       -       6632
 10 Spin_Retry_Count        0x0013   100   100   097    Pre-fail  Always       -       0
 12 Power_Cycle_Count       0x0032   098   098   020    Old_age   Always       -       2229
187 Reported_Uncorrect      0x0032   099   099   000    Old_age   Always       -       1
189 High_Fly_Writes         0x003a   100   100   000    Old_age   Always       -       0
190 Airflow_Temperature_Cel 0x0022   071   056   045    Old_age   Always       -       29 (Min/Max 25/29)
194 Temperature_Celsius     0x0022   029   044   000    Old_age   Always       -       29 (0 13 0 0 0)
195 Hardware_ECC_Recovered  0x001a   052   046   000    Old_age   Always       -       194244099
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       1
198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -       1
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       0
200 Multi_Zone_Error_Rate   0x0000   100   253   000    Old_age   Offline      -       0
202 Data_Address_Mark_Errs  0x0032   066   219   000    Old_age   Always       -       34

SMART Error Log Version: 1
ATA Error Count: 2
    CR = Command Register [HEX]
    FR = Features Register [HEX]
    SC = Sector Count Register [HEX]
    SN = Sector Number Register [HEX]
    CL = Cylinder Low Register [HEX]
    CH = Cylinder High Register [HEX]
    DH = Device/Head Register [HEX]
    DC = Device Command Register [HEX]
    ER = Error register [HEX]
    ST = Status register [HEX]
Powered_Up_Time is measured from power on, and printed as
DDd+hh:mm:SS.sss where DD=days, hh=hours, mm=minutes,
SS=sec, and sss=millisec. It "wraps" after 49.710 days.

Error 2 occurred at disk power-on lifetime: 5344 hours (222 days + 16 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  84 51 7c 1b 1a 02 ae  Error: ABRT at LBA = 0x0e021a1b = 235018779

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  20 20 7f 18 1a 02 ae 00      00:09:05.228  READ SECTOR(S)
  20 20 01 17 1a 02 ae 00      00:09:05.228  READ SECTOR(S)
  20 20 01 01 00 00 a0 00      00:08:59.830  READ SECTOR(S)
  91 20 3f 01 00 00 af 00      00:08:59.826  INITIALIZE DEVICE PARAMETERS [OBS-6]
  10 20 01 01 00 00 a8 00      00:08:59.678  RECALIBRATE [OBS-4]

Error 1 occurred at disk power-on lifetime: 5009 hours (208 days + 17 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  40 51 00 b7 8c 02 e0  Error: UNC at LBA = 0x00028cb7 = 167095

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  25 20 1e 9e 8c 02 e0 00      00:02:20.691  READ DMA EXT
  25 20 1e 80 8c 02 e0 00      00:02:20.691  READ DMA EXT
  25 20 1e 62 8c 02 e0 00      00:02:20.690  READ DMA EXT
  25 20 1e 44 8c 02 e0 00      00:02:20.690  READ DMA EXT
  25 20 1e 26 8c 02 e0 00      00:02:20.690  READ DMA EXT

SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Extended offline    Completed without error       00%      6631         -
# 2  Conveyance offline  Completed without error       00%      6630         -
# 3  Extended offline    Completed without error       00%      6622         -
# 4  Short offline       Completed without error       00%      6600         -
# 5  Extended offline    Completed without error       00%      6632         -

SMART Selective self-test log data structure revision number 1
 SPAN  MIN_LBA  MAX_LBA  CURRENT_TEST_STATUS
    1        0        0  Not_testing
    2        0        0  Not_testing
    3        0        0  Not_testing
    4        0        0  Not_testing
    5        0        0  Not_testing
Selective self-test flags (0x0):
  After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.

ATUALIZAR:

Conforme sugerido na resposta de rob, tentei sobrescrever todo o disco rígido com zeros. Verifiquei os valores SMART e comecei a ler o disco rígido inteiro. Verifique novamente os valores SMART. O resultado é: Os valores SMART referentes à contagem de setores pendentes / realocados não mudam, nos dois casos, imediatamente após a gravação e depois da leitura. Realocado 0. Pendente 1.

Um setor é marcado como pendente quando uma leitura falha. O setor pendente será marcado como realocado se uma gravação subsequente falhar. Se a gravação for bem-sucedida, ela será removida dos setores pendentes atuais e será aceita. (O comportamento exato pode diferir um pouco e abordarei isso mais tarde, mas essa é uma aproximação suficientemente próxima por enquanto.)

Quando você executa badblocks -w, cada padrão é primeiro gravado e depois lido. É possível que a gravação no setor superficial seja bem-sucedida, mas a leitura subsequente falhe, o que a adiciona novamente à lista de setores pendentes. Eu tentava escrever zeros em todo o disco dd if=/dev/zero of=/dev/sda, verificando o status SMART, lendo o disco inteiro dd if=/dev/sda of=/dev/nulle verificando o status SMART novamente.

Atualizar:

Com base nos seus resultados anteriores badblocks -w, eu esperava que o setor pendente fosse limpo após a gravação de todo o disco. Mas como isso não aconteceu, é seguro dizer que esse disco não está se comportando conforme o esperado.

Vamos revisar a descrição da Contagem de setor pendente atual :

Contagem de setores "instáveis" (aguardando remapeamento, devido a erros de leitura irrecuperáveis). Se um setor instável for posteriormente lido com êxito, o setor será remapeado e esse valor será diminuído. Os erros de leitura em um setor não remapearão o setor imediatamente (já que o valor correto não pode ser lido e, portanto, o valor a remapear não é conhecido e também poderá ser lido posteriormente); em vez disso, o firmware da unidade lembra que o setor precisa ser remapeado e o remapeará na próxima vez que for gravado. [29] No entanto, algumas unidades não remapearão imediatamente esses setores quando gravadas; em vez disso, a unidade tentará primeiro gravar no setor com problema e, se a operação de gravação for bem-sucedida, o setor será marcado como bom (nesse caso, a "Contagem de eventos de realocação" (0xC4) não será aumentada).

Agora vamos revisar os pontos importantes:

... o firmware da unidade lembra que o setor precisa ser remapeado e o remapeará na próxima vez que for escrito. [29] No entanto, algumas unidades não remapearão imediatamente esses setores quando gravadas; em vez disso, a unidade tentará primeiro gravar no setor com problema e, se a operação de gravação for bem-sucedida, o setor será marcado como bom.

Em outras palavras, o setor pendente deveria ter sido remapeado imediatamente ou a unidade deveria tentar gravar no setor e uma das duas coisas deveria ter acontecido:

1. A gravação falhou; nesse caso, o setor pendente deveria ter sido remapeado.
2. A gravação foi bem-sucedida; nesse caso, o setor pendente deveria ter sido limpo ("marcado como bom").

Eu sugeri isso anteriormente, mas a descrição da Wikipedia sobre o setor pendente atual sugere que a contagem atual do setor pendente deve sempre ser zero após uma gravação completa do disco . Como esse não é o caso aqui, podemos concluir que (a) a Wikipedia está errada (ou pelo menos incorreta para sua unidade) ou (b) o firmware da unidade não pode lidar adequadamente com esse estado de erro (o que eu consideraria um bug de firmware )

Se um setor instável for posteriormente lido com êxito, o setor será remapeado e esse valor será diminuído.

Como a contagem atual do setor pendente ainda permanece inalterada após a leitura de toda a unidade, podemos afirmar que (a) o setor não pôde ser lido com êxito ou (b) o setor foi lido com sucesso e marcado como bom, mas ocorreu um erro ao ler um setor diferente. Mas como a contagem do setor realocado ainda é 0 após a leitura, podemos excluir (b) como uma possibilidade e concluir que o setor pendente ainda era ilegível.

Nesse momento, seria útil saber se a unidade registrou algum novo erro SMART. Minha próxima sugestão seria verificar se a Seagate possui uma atualização de firmware para sua unidade, mas parece que não.

Embora eu recomende não continuar usando essa unidade, parece que você pode estar disposto a aceitar os riscos envolvidos (a saber, que ela pode continuar a agir de forma irregular e / ou degradar ou falhar catastroficamente). Nesse caso, você pode tentar instalar o Linux, inicializar a partir de um CD de resgate e, em seguida (com os sistemas de arquivos desmontados), usar o nome do arquivo e2fsck -l para marcar manualmente o bloco apropriado como incorreto. (Apenas certifique-se de manter bons backups!)

e2fsck -l nome do arquivo

Adicione os números de bloco listados no arquivo especificado pelo nome do arquivo à lista de blocos defeituosos. O formato deste arquivo é o mesmo que o gerado pelo programa badblocks (8). Observe que os números dos blocos são baseados no tamanho do bloco do sistema de arquivos. Portanto, os badblocks (8) devem receber o tamanho do bloco do sistema de arquivos para obter resultados corretos. Como resultado, é muito mais simples e seguro usar a opção -c no e2fsck, pois garantirá que os parâmetros corretos sejam passados ​​para o programa badblocks.

(Observe que e2fsck -cé preferível e2fsck -l filenamee você pode até tentar, mas com base nos seus resultados até agora, duvido muito que o e2fsck -c encontre quaisquer bloqueios.)

Obviamente, você precisará fazer alguma aritmética para converter o LBA do setor defeituoso (conforme fornecido pela SMART) em um número de bloco do sistema de arquivos. O How To Bad Blocks fornece uma fórmula útil:

  b = (int)((L-S)*512/B)
where:
b = File System block number
B = File system block size in bytes
L = LBA of bad sector
S = Starting sector of partition as shown by fdisk -lu
and (int) denotes the integer part.

O HowTo também contém um exemplo completo usando essa fórmula. Após a instalação do sistema operacional, você pode confirmar se um arquivo está ocupando o setor superficial usando debugfs (consulte o HowTo para obter instruções detalhadas).

Outra opção: particionar em torno do bloco suspeito suspeito Ao instalar o sistema operacional, você também pode tentar particionar o erro. Se eu fiz meu direito aritmético, o erro é de cerca de 81,589 MB, portanto, você pode tornar o boot / um pouco pequeno e iniciar sua próxima partição após o setor 167095, ou pular completamente os primeiros 82 MB.

ABRT 235018779 Infelizmente, quanto ao erro ABRT no setor 235018779, podemos apenas especular, mas a especificação ATA8-ACS nos fornece algumas pistas.

Do rascunho de trabalho no anexo 8 - Conjunto de comandos ATA / ATAPI (ATA8-ACS) :

6.2.1 Erro de abortamento (ABRT), bit 2. O abortamento deve ser definido como um se o comando não for suportado. O cancelamento pode ser definido como um se o dispositivo não puder concluir a ação solicitada pelo comando. O cancelamento também deve ser definido como um se um endereço fora do intervalo de endereços acessíveis pelo usuário for solicitado se o IDNF não estiver definido como um.

Observando os comandos que antecederam o ABRT (vários LEITORES SETORES) seguidos de recalibração e reinicialização) ...

O cancelamento deve ser definido como um se o comando não for suportado. - Isso parece improvável.

O cancelamento pode ser definido como um se o dispositivo não puder concluir a ação solicitada pelo comando. - Talvez a lista P de setores realocados altere os endereços acessíveis pelo usuário o suficiente para que um endereço acessível pelo usuário seja traduzido para o setor 235018779 e a operação de leitura não tenha sido concluída (por que motivo, não sabemos ... mas não houve um erro de CRC, então acho que não podemos concluir que o setor 235018779 é ruim).

O cancelamento também deve ser definido como um se um endereço fora do intervalo de endereços acessíveis pelo usuário for solicitado se o IDNF não estiver definido como um. - Para mim, isso parece muito provável, e eu provavelmente o interpretaria como resultado de um erro de software (no seu sistema operacional ou em algum programa que você estava executando). Nesse caso, não é um sinal de destruição iminente para o disco rígido.

Caso você ainda não esteja cansado de executar diagnósticos ...

Você pode tentar smartctl -t long /dev/sdanovamente para verificar se há mais erros no log do SMART ou pode deixá-lo como um arquivo X não resolvido ;) e verificar o log do SMART periodicamente para ver se isso acontece novamente. De qualquer forma, se você continuar a usar a unidade sem realocá-la ou limpar o setor pendente, já estará assumindo um risco.

Use um sistema de arquivos de soma de verificação

Para um pouco mais de segurança, considere o uso de um sistema de arquivos de soma de verificação, como ZFS ou btrfs, para ajudar a proteger contra corrupção de dados de baixo nível. E não esqueça de executar backups frequentes se você tiver algo que não possa ser facilmente reproduzido.

O artigo Remapeamento incorreto do setor fornece o algoritmo usado.

Existem duas listas de defeitos no disco rígido:

• A lista P são defeitos encontrados durante a fabricação e também são conhecidos como defeitos primários. Eles seguem sequencialmente os setores normais. Um setor defeituoso apontará para a sua substituição usando um número de turno (primeiro é +1, depois +2 etc.).
• G-List são defeitos que se desenvolvem no uso normal da unidade e são conhecidos como defeitos crescentes. Não há restrições em sua alocação e eles não precisam seguir sequencialmente os defeitos da lista P. Um setor defeituoso apontará para sua substituição usando um número de setor simples.

Portanto, o fato de seu setor defeituoso estar 577121 setores além do último setor normal não significa que você possui 577121 setores defeituosos, a menos que seja um defeito da lista P. Um defeito da lista G pode ser colocado em qualquer lugar, por isso é perfeitamente possível que o firmware o aloque no final do espaço do setor de reposição.

Da wikipedia Atributos conhecidos do ATA SMART :

Contagem de setores reatribuídos

Contagem de setores realocados. Quando o disco rígido encontra um erro de leitura / gravação / verificação, ele marca esse setor como "realocado" e transfere dados para uma área reservada especial (área de reposição). Esse processo também é conhecido como remapeamento, e os setores realocados são chamados de "remaps". O valor bruto normalmente representa uma contagem dos setores defeituosos que foram encontrados e remapeados.

Contagem atual sector pendente

Contagem de setores "instáveis" (aguardando remapeamento, devido a erros de leitura irrecuperáveis). Se um setor instável for posteriormente lido com êxito, o setor será remapeado e esse valor será diminuído. Os erros de leitura em um setor não remapearão o setor imediatamente (já que o valor correto não pode ser lido e, portanto, o valor a remapear não é conhecido e também poderá ser lido posteriormente); em vez disso, o firmware da unidade lembra que o setor precisa ser remapeado e o remapeará na próxima vez que for gravado.

Portanto, de fato, os erros pendentes são muito piores que o remapeado, pois o erro é difícil o suficiente para impedir a leitura do conteúdo original para remapear. Com efeito, o conteúdo desse setor provavelmente está perdido para sempre.

A ferramenta de diagnóstico Disco rígido de nível muito baixo MHDD do documento explica os códigos de erro como:

UNC : data is uncorrectable
ABRT : command was aborted

Portanto, o setor 167095 é incorrigível e a leitura / gravação para 235018779 foi abortada.

Como escrever para os dois setores não mudou o status de pendente para remapeado, parece-me que o setor de substituição também é ruim. Minha teoria é que o setor 167095 foi remapeado para o setor 235018779, mas que infelizmente este último também é ruim e que o firmware não sabe como refazer o remapeamento dos setores sobressalentes ruins. O resultado é um setor incorreto e incorrigível.