HD Sata 750GB pifou….

O meu desktop fica ligado direto…. sempre tem algum programinha agendado para rodar e acaba sendo pouco prático o desligamento nas horas de folga… mas (sempre tem um mas), cheguei em casa e a configuração estava desligada. Isso acontece quando se tem alguma falha de energia, ou um pico de tensão, mas realmente não havia observado nada de anormal.

Após conferir as conexões, religuei o equipamento. Tudo parecia normal. abrindo disco rigidoConsegui fazer as minhas atividades corriqueiras. Apenas percebi o problema quando precisar em um arquivo que esta no HD750Gb! Ele contem basicamente, backups e arquivos de pouco uso. Ele não estava montado no sistema! Normalmente, ele leva um pouco mais de tempo para se montar no sistema, porque é grande e porque ele é pouco solicitado. Mas desta vez, mesmo quando solicitado, ele emite o aviiso de abrindo o disco, demora mais do que usual, faz um ruido diferente como se estivesse forçando a rotação do disco, e colocando a mão sobre a unidade se percebe que ele está muito mais quente que os demais discos.

Depois de mais tempo do que o usual, o sistema apresenta a tela com a mensagem de erro, indicando que a unidade demorou demais para responder à solicitação. Alternativamente, aparece a mensagem com o erro de montagem do disco. Ainda não consegui perceber quando aparece uma e quando aparece a outra mensagem.

Bom…. este é o meu disco de backup. Guarda basicamente cópias dos meus arquivos de trabalho preservados periodicamente. Então, consigo continuar operando normalmente, mas :

  • Porque isso aconteceu? Houve mesmo uma falha no fornecimento de energia?
  • como recuperar este disco?
  • recomendações adicionais?

Como o dispositivo é reconhecido normalmente pela BIOS, parece que a placa controladora está integra. O problema se apresenta quando se tenta fazer acesso ao disco!

Outros sistemas operacionais não obtiveram melhor resultado em conseguir ler o dispositivo. Vale a tentativa de acesso por outros sistemas operacionais, mas realmente as chances são remotas pois parece que o problema está mesmo no capacidade de leitura da mídia pelo controlador do disco!

 

 

As tentativas de fazer uma cópia fisica do disco com o comando dd não funcionáram porque o comando para no primeiro erro que ele encontra. Alternativamente, a ferramenta dd_rescue consegue fazer a imagem do disco, deixando nos pontos de erro um "espaço"! Porque será que este processo de cópia é tão lento?

 

As mensagens geradas na execução do dd_rescue que dá uma idéia de onde está acontecendo problema no HD750gb:

omy@omy:~$ sudo dd_rescue /dev/sdc1 /media/"Novo volume"/hd750cpy
[sudo] password for omy:
dd_rescue: (fatal): open "/media/Novo volume/hd750cpy" failed: Is a directory
omy@omy:~$ sudo dd_rescue /dev/sdc1 /media/"Novo volume"/hd750cpy/rescue
dd_rescue: (info): ipos:     25928.0k, opos:     25928.0k, xferd:     25928.0k
                *  errs:      0, errxfer:         0.0k, succxfer:     25928.0k
             +curr.rate:        0kB/s, avg.rate:      191kB/s, avg.load:  0.1%
dd_rescue: (warning): /dev/sdc1 (25928.0k): Input/output error!

dd_rescue: (info): ipos:     25928.5k, opos:     25928.5k, xferd:     25928.5k
                *  errs:      1, errxfer:         0.5k, succxfer:     25928.0k
             +curr.rate:        0kB/s, avg.rate:      167kB/s, avg.load:  0.1%
dd_rescue: (warning): /dev/sdc1 (25928.5k): Input/output error!

dd_rescue: (info): ipos:     25929.0k, opos:     25929.0k, xferd:     25929.0k
                *  errs:      2, errxfer:         1.0k, succxfer:     25928.0k
             +curr.rate:        0kB/s, avg.rate:      149kB/s, avg.load:  0.1%
dd_rescue: (warning): /dev/sdc1 (25929.0k): Input/output error!

dd_rescue: (info): ipos:     25929.5k, opos:     25929.5k, xferd:     25929.5k
                *  errs:      3, errxfer:         1.5k, succxfer:     25928.0k
             +curr.rate:        0kB/s, avg.rate:      135kB/s, avg.load:  0.1%
dd_rescue: (warning): /dev/sdc1 (25929.5k): Input/output error!

dd_rescue: (info): ipos:     25930.0k, opos:     25930.0k, xferd:     25930.0k
                *  errs:      4, errxfer:         2.0k, succxfer:     25928.0k
             +curr.rate:        0kB/s, avg.rate:      123kB/s, avg.load:  0.1%
dd_rescue: (warning): /dev/sdc1 (25930.0k): Input/output error!

dd_rescue: (info): ipos:     25930.5k, opos:     25930.5k, xferd:     25930.5k
                *  errs:      5, errxfer:         2.5k, succxfer:     25928.0k
             +curr.rate:        0kB/s, avg.rate:      113kB/s, avg.load:  0.1%
dd_rescue: (warning): /dev/sdc1 (25930.5k): Input/output error!

 Observando o consumo de CPU, percebi que o processo mount-ntfs consome praticamente 100% de uma das CPUs. Este parece ser um erro antigo do ambiente em que um processo tenta copiar grande dados entre duas estruturas NTFS praticamente trava o módulo com alto consumo de CPU. Uma idéia seria "kill" este processo, mas como isso poderia afetar o processo de recuperação do disco, estou deixando o processo correr. Vamos ver no que dá. Isso pode estar causando a baixa velocidade na cópia que já dura mais de uma semana.

Depois de rodar por mais de 10 dias, com umas contas rápidas descobri que levaria mais 20 dias para terminar. O problema é que a cópia está ficando cada vez mais lenta e a maquina cada vez mais carregada. Então ctl-C no processo terminando com ele. Será que o arquivo gerado serve para alguma coisa? Ele tem mais de 500gb. Mais do que eu me lembro estar usando na unidade com problemas. Se eu montá-lo, consigo ver os arquivos?

Rodando o fsck sobre o arquivo cópia, como se ele fosse uma partição, dava a mensagem de que ele tinha problema no "EOF : End of File". Apressadamente eu eliminei o arquivo achando que não tinha mais solução. Mas, algumas idéias surgiram depois. Abrir e gravar com o Vim, por exemplo! Acredito que ele fecharia o arquivo corretamente! Agora fica para uma próxima vez.

 

Uma tentativa é com a ferramenta fsck que verifica o disco por erros e tenta se recuperar deles.

 

[/sbin/fsck.reiserfs (1) — /dev/sdc1] fsck.reiserfs -r /dev/sdc1
reiserfsck 3.6.21 (2009 www.namesys.com)

*************************************************************
** If you are using the latest reiserfsprogs and  it fails **
** please  email bug reports to reiserfs-list@namesys.com, **
** providing  as  much  information  as  possible —  your **
** hardware,  kernel,  patches,  settings,  all reiserfsck **
** messages  (including version),  the reiserfsck logfile, **
** check  the  syslog file  for  any  related information. **
** If you would like advice on using this program, support **
** is available  for $25 at  www.namesys.com/support.html. **
*************************************************************

Will read-only check consistency of the filesystem on /dev/sdc1
Will put log info to ‘stdout’

Do you want to run this program?[N/Yes] (note need to type Yes if you do):Yes
###########
reiserfsck –check started at Thu Oct 20 10:10:52 2011
###########
Replaying journal: Done.
Reiserfs journal ‘/dev/sdc1’ in blocks [18..8211]: 0 transactions replayed
Checking internal tree.. finished
Comparing bitmaps..finished
Checking Semantic tree:
finished
No corruptions found
There are on the filesystem:
    Leaves 347339
    Internal nodes 2192
    Directories 164517
    Other files 1081532
    Data block pointers 96219596 (333112 of them are zero)
    Safe links 0
###########
reiserfsck finished at Thu Oct 20 10:32:48 2011
###########

Bom… parece que o fsck ajudou… consegui montar o disco no nautilus e estou conseguindo copiar os arquivos para uma outra unidade. Pelo que parece, o problema estava numa área de Journal do sistema de arquivos. Quando o fsck conferiu os dados ele percebeu que os dados estavam integros e restaurou a unidade para condições de uso.

De qualquer forma, esta unidade de disco precisa ser colocada como suspeita e usada convenientemente. Por exemplo, reparticionando e usando para trabalhos menores.

 

 

Truque da Geladeira. Entre os mitos urbanos que circulam na internet, o truque da Geladeira para recuperar HD é um bem comentado ForumPCs, VivaoLinux, ISTF,  O HD envolto em material impermeável é colocado na geladeira por algum tempo (alguns dizem 8 horas), depois disso é devidamente seco inclusive da condensação provocada pela camara fria da geladeira, e reinstalado no micro. Funciona? Depoimentos na internet e, mesmo pessoalmente como o MAC, confirmam que funcionou! Qual é a Lógica? O problema acontece por causa do aquecimento do dispositivo provocando a deformação de componentes, ao resfriar na geladeira, a deformação seria reduzida permitindo o uso de novamente. Sim, eu tentei isso também, sem melhores resultados.

 


Comments

Deixe um comentário

Esse site utiliza o Akismet para reduzir spam. Aprenda como seus dados de comentários são processados.