O HDD de 3TB é um escravo do caos ~ Reparando e ressuscitando setores defeituosos de um HDD de 3TB morto ~
Olá, sou um inútil.
Eu estava imerso em desespero no artigo anterior, mas não sou o tipo de homem que desiste facilmente.
O verão não acaba. Até que a lição de casa termine______
O que aconteceu
Ontem, de repente, a conexão SSH parou e o GNU/Linux parecia ter travado. Após reiniciar, verifiquei o syslog.
Aug 27 04:03:55 localhost kernel: [2768521.366336] EXT4-fs (sdc1): error count since last fsck: 52
Aug 27 21:19:27 haturatu kernel: [ 28.915465] EXT4-fs (sdc1): warning: mounting fs with errors, running e2fsck is recommended
Aug 27 21:24:30 haturatu kernel: [ 332.803482] EXT4-fs (sdc1): error count since last fsck: 53
Aug 27 22:28:45 haturatu kernel: [ 5.694598] EXT4-fs (sdc1): warning: mounting fs with errors, running e2fsck is recommended
Aug 27 22:33:55 haturatu kernel: [ 316.412146] EXT4-fs (sdc1): error count since last fsck: 53
Aug 28 08:19:17 haturatu kernel: [ 5.710007] EXT4-fs (sdc1): warning: mounting fs with errors, running e2fsck is recommended
Aug 28 08:24:39 haturatu kernel: [ 316.427213] EXT4-fs (sdc1): error count since last fsck: 53
O quê?
Ah...
Hmm?
O HDD não voltou no Obon
Tentando fsck
Por enquanto, conectei via USB-HDD.
$ sudo fsck -f -y /dev/sdb
Após verificar o disco com lsblk, executei-o por enquanto.
727810) +(77856769--77859749) +(77987841--77990269) +(78118913--78121629) +(78249985--78252434) +(78381057--78383008) +(78512129--78515588) +(78643201--78644782) +(78774273--78776000) +(78905345--78907598) +(79036417--79038955) +(79167489--79169769) +(79298561--79300360) +(79429633--79431425) +(79560705--79562857) +(79691777--79695179) +(79822849--79857556) +(79953921--79960927) +(80084993--80113787) +140247041
Fix? yes
Padding at end of inode bitmap is not set. Fix? yes
Error reading block 32768 (Erro de entrada/saída). Ignore error? yes
Force rewrite? yes
Error writing block 32768 (Erro de entrada/saída). Ignore error? yes
Error reading block 98304 (Erro de entrada/saída). Ignore error? yes
Certo!!!!!
Sim, é o erro de I/O desesperador que já vi no passado.
Verificando com dmesg
Vou omitir um pouco, mas verifico os itens da unidade relevante com grep.
$ sudo dmesg | grep ' I/O error,' | grep "sdb"
[227123.296980] I/O error, dev sdb, sector 62916608 op 0x0:(READ) flags 0x83700 phys_seg 1 prio class 0
[227175.622027] I/O error, dev sdb, sector 78880 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0
[227175.622087] I/O error, dev sdb, sector 62916624 op 0x0:(READ) flags 0x83700 phys_seg 14 prio class 0
[227459.286465] I/O error, dev sdb, sector 373295104 op 0x0:(READ) flags 0x80700 phys_seg 5 prio class 0
[227490.240900] I/O error, dev sdb, sector 377489408 op 0x0:(READ) flags 0x80700 phys_seg 4 prio class 0
Ahhh
Meu coração está prestes a quebrar, Patrasche.
Pesquisando no Google
Vou me apoiar na sabedoria dos engenheiros do passado.
(Setores defeituosos ocorreram no HDD do Linux, então tentei repará-los)[https://web.archive.org/web/20240828125146/https://neocat.hatenablog.com/entry/2019/10/21/061645]
Li e entendi o mecanismo de alguma forma.
Nesses casos, se você escrever neste setor, o firmware do HDD deve substituí-lo por um setor alternativo.
Parece que sim. Por enquanto, mesmo com pressa, continuo inserindo os setores que apareceram na saída do dmesg.
$ cat secter.sh
#!/bin/bash
sudo dd if=/dev/zero of=/dev/sdc bs=4k seek=$((62916608 / 8)) count=1
sudo dd if=/dev/zero of=/dev/sdc bs=4k seek=$((62916624 / 8)) count=1
sudo dd if=/dev/zero of=/dev/sdc bs=4k seek=$((373295104 / 8)) count=1
sudo dd if=/dev/zero of=/dev/sdc bs=4k seek=$((406849536 / 8)) count=1
sudo dd if=/dev/zero of=/dev/sdc bs=4k seek=$((411043840 / 8)) count=1
sudo dd if=/dev/zero of=/dev/sdc bs=4k seek=$((415238144 / 8)) count=1
sudo dd if=/dev/zero of=/dev/sdc bs=4k seek=$((419432448 / 8)) count=1
sudo dd if=/dev/zero of=/dev/sdc bs=4k seek=$((423626752 / 8)) count=1
Também estou omitindo isso, mas o sdb→sdc→sdd está mudando um pouco porque estou tentando fsck e desconectando/reconectando devido a erros de I/O, então, por favor, entenda.
Por enquanto, executei de uma vez os comandos roteirizados para os setores que apareceram no dmesg.
Poderia ser feito de forma mais concisa, mas em momentos como este, não consigo pensar em eficiência. Mesmo que seja uma abordagem suja, se for para arriscar perder todos os dados da unidade, eu faria isso com a mesma determinação de beber água lamacenta.
E então, para o fsck...
De alguma forma, enquanto executava várias vezes no mesmo setor,
Bad sectors playing hide and seek on my hard drive
Dizia que o smartctl também verificaria setores defeituosos, então tentei no início, mas não funcionou.
No entanto, depois de algumas tentativas daquela 'luta suja' mencionada, começou a funcionar, então executei sudo smartctl -a /dev/sda, sudo smartctl -t short /dev/sda e deu certo, e repeti a 'luta suja' novamente...
$ sudo fsck -f -y /dev/sdd1
fsck from util-linux 2.40.2
e2fsck 1.47.1 (20-May-2024)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Block bitmap differences: +(7864320--7872543) +(7929856--7946227) +(7946240--7962599) +(46661632--46669855) +(50855936--50864159) +(51380224--51388447) +(51388796--51404769) +(51404800--51412989) +(51904512--51928992) +(51929026--51929058) +(51929088--51937274) +(52428800--52453339) +(52453376--52461542) +(52953088--52962248) +(52964143--52977649) +(52977664--52985847)
Corrigir? sim
Uaaaaahhhhhhhhhhhhhh!!!!!
Ressurreição!!!!
Ainda não consegui verificar quais arquivos estão corrompidos, mas a maioria dos 1TB de dados voltou.
E assim, foi um dia em que senti profundamente a grandeza da sabedoria dos antepassados.
Foi um dia em que eu nunca imaginei que, ao descobrir pela manhã que o HDD havia morrido, conseguiria recuperá-lo no mesmo dia.
Então.
Até a próxima.