Meu HD Externo Toshiba parou de funcionar do nada

HMSLIMA · Março 31, 2023, 1:08am

Comprei um HD externo Toshiba (veio da China, comprei pelo Shopee se não me engano) para armazenar os meus filmes e séries baixados, mas quando fui abri-lo hoje (após tê-lo usado por dois dias), deu a seguinte mensagem de erro:

mount: /media/sdb1: wrong fs type, bad option, bad superblock on /dev/sdb1, missing codepage or helper program, or other error.

Basicamente, ontem eu tinha dois HDs externos conectados no meu notebook e eu estava copiando os arquivos de um para o outro, gigas e gigas de filmes baixados. Se bem que teve um momento que deu ruim na transferência e quando fui olhar, somente um filme (de uns 40) foi transferido e ainda assim o arquivo parcialmente corrompido.

Eis alguns comandos e seus respectivos resultados:

$ lsblk -f
NAME   FSTYPE FSVER LABEL      UUID                                 FSAVAIL FSUSE% MOUNTPOINT
sda                                                                                
├─sda1 vfat   FAT32 EFI System 4B47-53CA                            1021,4M     0% /boot/efi
├─sda2 btrfs                   619d7b7d-3682-43ce-893e-1bb30343e7f1  536,2G    39% /home
└─sda3 swap   1     swapMX     0bde20b8-bfba-45e3-93b6-f5569e68d988                [SWAP]
sdb                                                                                
└─sdb1 exfat  1.0              76E8-CACF

.

$ sudo fdisk -l
Disk /dev/sda: 894,25 GiB, 960197124096 bytes, 1875385008 sectors
Disk model: KINGSTON SA400S3
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 8E9A023E-6B2E-446A-8612-D0DA4451F51A

Device          Start        End    Sectors   Size Type
/dev/sda1        2048    2099199    2097152     1G EFI System
/dev/sda2     2099200 1845299199 1843200000 878,9G Linux filesystem
/dev/sda3  1845299200 1875369983   30070784  14,3G Linux filesystem


Disk /dev/sdb: 1,91 TiB, 2097152000000 bytes, 4096000000 sectors
Disk model: USB 3.0         
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xfa2cb833

Device     Boot Start        End    Sectors  Size Id Type
/dev/sdb1  *       32 4095999999 4095999968  1,9T  7 HPFS/NTFS/exFAT

.

$ sudo smartctl -t short /dev/sdb1
smartctl 7.2 2020-12-30 r5155 [x86_64-linux-6.0.0-6mx-amd64] (local build)
Copyright (C) 2002-20, Bruce Allen, Christian Franke, www.smartmontools.org

Short offline self test failed [unsupported field in scsi command]

.

$ sudo smartctl -H  /dev/sdb1
smartctl 7.2 2020-12-30 r5155 [x86_64-linux-6.0.0-6mx-amd64] (local build)
Copyright (C) 2002-20, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF READ SMART DATA SECTION ===
SMART Health Status: OK

.

sudo btrfs rescue chunk-recover /dev/sdb1
[sudo] senha para hmslima: 
read super block error
recover prepare error
Chunk tree recovery failed

Meu sistema operacional é MX Linux, com ambiente gráfico KDE. Como vocês podem ver, o sistema de arquivos do sistema é Btrfs.

Tentei reiniciar o notebook, mas o resultado continuou o mesmo. Parece que o HD externo está morto.

aguamole · Março 31, 2023, 2:40am

Não é o sdb1 né? é extFAT(FAT64) esse filesystem não presta usa tecnologia de segurança da época do MSDOS em 1981 você nem era nascido quando FAT surgiu. A única utilidade desse filesystem é para fazer transferência de arquivo entre, BSD, MacOS, Linux, Windows, talvez Unix. Mas ele pode dar pau a qualquer momento portanto não pode deletar os arquivos da maquina original para que se der pau antes de transferir poder voltar a fonte e realizar uma nova copia.
Se você não fez o procedimento de manter a fonte vc perdeu tudo a menos que você contrate o serviço de uma empresa especializada em recuperação de dados.

acvsilva · Março 31, 2023, 7:12am

se apareceu o erro de montagem, vc n perdeu seu ssd. o mais provável é o problema de escrita de gdes qtdes de dados. escolha outro formato, como ntfs ou mesmo ext4 ou btrfs, se puder. qto ao que vc gravou, acho que já era. use o gparted pra formatar: sudo apt install gparted -y

aguamole · Março 31, 2023, 6:30pm

Ext4 usa tecnologia de segurança de 2001, ele é a mesma coisa do EXT3 em segurança. Todas as melhorias do Ext3 para Ext4 foi em desempenho e tamanho de partição e soma de verificação que so presta para identificar problema nos dados, e outras coisinhas que não da segurança. O Ext4 usa tecnologias de segurança pouco eficiente. Já o Ext2 é mesma coisa do FAT em segurança. A tecnologia moderna é adicionar COW para mais segurança.

Se não fizerem uma att do Ext para COW ele vai continuar sendo rejeitado nos grandes servidores que tenha técnicos capazes de analisar o quanto que ele é obsoleto, A Canonical sabendo disso ela coloco o ZFS no Ubuntu. Podia deixar sem o ZFS fora e colocar o BTRFS como padrão, mas o problema do BTRFS é que ele ainda esta em desenvolvimento, pode ser que ocorra uma atualização do driver BTRFS quebrada e então ferrar com o servidor, dai ela partiu para o ZFS que já foi concluído e testado por muito tempo.

acvsilva · Março 31, 2023, 7:18pm

para o fim a que se destina, guardar vídeos, isso não faz a menor diferença. milhões de celulares android rodam no fat 32. a microsoft ganha royalties e obrigou as empresas a instalarem o office como compensação.

aguamole · Março 31, 2023, 7:28pm

O chip SD usa Fat mas o filesystem do sistema eu não sei não. Além do mais o SD no celular não vai ter queda de energia abrupta e nem ele será removido durante a escrita, remover dispositivo sem antes terminar de escrever toda a cache é que é o monstro. A memória interna então muito menos que vai ser removida, queda de energia em celular não acontece já que ele tem bateria. Nem deve ter cache de escrita em Smartphone.

A Microsoft desabilito a cache de escrita em seu sistema operacional por padrão em dispositivos de armazenamento móvel, não sei como fazer isso no Linux. E nem tenho interesse, cache de escrita adianta a vida, a gravação aparece como terminada para o sistema mas na verdade ainda tem arquivos a serem gravados da memória para o dispositivo isso adianta a minha vida porque não preciso ficar esperando.

HMSLIMA · Abril 1, 2023, 1:23am

Pra quem está perguntando (como @aguamole ), o HD externo de 2TB é montado em /dev/sdb. Marco aqui o @acvsilva para que este veja esta minha nova mensagem

Quando aos dados dentro do HD externo, não tenho problema em perdê-los porque eles já estão seguros em outro lugar, minha preocupação é com o HD externo em si!

Galera, não estou conseguindo formatar esse HD externo. Já estou começando a ficar preocupado.

Quando tento criar uma nova partição, ele diz que não tem nenhuma tabela de partições localizada no dispositivo /dev/sdb.

Screenshot_20230331_220955

O problema é que isso não dá em nada, tanto faz se eu escolher msdos (escolha padrão do GParted) ou GPT (que é o padrão de fábrica dos meus outros HDs externos que tenho e funcionam bem).

Já tentei usar o comando…

sudo dd if=/dev/zero of=/dev/sdb bs=512 count=1

…mas não deu em nada

Quando tento usar o comando gdisk:

$ sudo gdisk -l /dev/sdb
[sudo] senha para hmslima: 
GPT fdisk (gdisk) version 1.0.6

Warning: Partition table header claims that the size of partition table
entries is 1276646114 bytes, but this program  supports only 128-byte entries.
Adjusting accordingly, but partition table may be garbage.
Warning: Partition table header claims that the size of partition table
entries is 0 bytes, but this program  supports only 128-byte entries.
Adjusting accordingly, but partition table may be garbage.
Partition table scan:
  MBR: not present
  BSD: not present
  APM: not present
  GPT: not present

Creating new GPT entries in memory.
Disk /dev/sdb: 4096000000 sectors, 1.9 TiB
Model: USB 3.0         
Sector size (logical/physical): 512/512 bytes
Disk identifier (GUID): 4F92B72F-54B8-4BEE-98B4-D8164B47B207
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 4095999966
Partitions will be aligned on 2048-sector boundaries
Total free space is 4095999933 sectors (1.9 TiB)

Number  Start (sector)    End (sector)  Size       Code  Name

Se eu rodar o comando acima, novamente, aparecerá a mesmíssima mensagem, nenhuma alteração útil foi feita

A única coisa que dá uma alteraçãozinha é isso aqui:

$ sudo gdisk /dev/sdb
GPT fdisk (gdisk) version 1.0.6

Warning: Partition table header claims that the size of partition table
entries is 4244255471 bytes, but this program  supports only 128-byte entries.
Adjusting accordingly, but partition table may be garbage.
Warning: Partition table header claims that the size of partition table
entries is 0 bytes, but this program  supports only 128-byte entries.
Adjusting accordingly, but partition table may be garbage.
Partition table scan:
  MBR: not present
  BSD: not present
  APM: not present
  GPT: not present

Creating new GPT entries in memory.

Command (? for help): w

Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING
PARTITIONS!!

Do you want to proceed? (Y/N): y
OK; writing new GUID partition table (GPT) to /dev/sdb.
The operation has completed successfully.

Quando vamos ver no lsblk:

$ lsblk -f
NAME   FSTYPE FSVER LABEL      UUID                                 FSAVAIL FSUSE% MOUNTPOINT
sda                                                                                
├─sda1 vfat   FAT32 EFI System 4B47-53CA                            1021,4M     0% /boot/efi
├─sda2 btrfs                   619d7b7d-3682-43ce-893e-1bb30343e7f1  536,5G    39% /home
└─sda3 swap   1     swapMX     0bde20b8-bfba-45e3-93b6-f5569e68d988                [SWAP]
sdb                                                                                
├─sdb2                                                                             
└─sdb3

Pelo menos apareceram esses sdb2 e sdb3. Mas nada mudou no GParted, que não consegue fazer nada

Deleterium · Abril 1, 2023, 1:17pm

512 bytes só zera a MBR. O particionamento GPT usa 32 setores do início do disco (16k) mas é comum o programa de particionamento alinhar a próxima partição para 1M (2048 setores). Também ele salva uma cópia no fim do disco (backup). Eu costumo zerar os primeiro 2048 setores do início, e mesmo assim o gparted ainda me diz que achou o backup.

Tenta dd if=/dev/zero of=/dev/sdb bs=512 count=2048 pra zerar o início e dd if=/dev/zero of=/dev/sdb seek=4095997952 bs=512 count=2048 pra zerar os finais.

Caso dê problema para zerar os finais com I/O error (acompanhe em outra janela com sudo journalctl -f), pode ser que o disco seja falso. Coloque aqui as saídas em caso de erro.

Caso dê tudo certo, desconecte o disco, reinicie (só pra ter certeza), daí conecte novamente e tente particionar novamente.

** Edit: aqui estou assumindo que cada setor do disco tem 512 bytes, pois já vi pela info que vc postou que é o seu caso. Alguns discos podem trabalhar com tamanho de setor diferente, daí esses cálculos mudam.

HMSLIMA · Abril 1, 2023, 1:28pm

Eis os resultados do comando dd:

sudo dd if=/dev/zero of=/dev/sdb bs=512 count=2048
[sudo] senha para hmslima: 
2048+0 registros de entrada
2048+0 registros de saída
1048576 bytes (1,0 MB, 1,0 MiB) copiados, 2,2528 s, 465 kB/s

.

$ sudo dd if=/dev/zero of=/dev/sdb seek=4095997952 bs=512 count=2048
2048+0 registros de entrada
2048+0 registros de saída
1048576 bytes (1,0 MB, 1,0 MiB) copiados, 0,293183 s, 3,6 MB/s

Quando ao journalctl, o abri em outra janela do Konsole e ele não mostrou nenhuma mudança, ficou parado em:

$ sudo journalctl -f
[sudo] senha para hmslima: 
No journal files were found.

Desconectei o HD externo e o reconectei novamente (vou reiniciar o sistema agora, se houver mudança eu aviso).Quando abro o GParted, não vejo nenhum avanço.

Mas o lsblk já mostra uma coisinha diferente:

$ lsblk -f
NAME   FSTYPE FSVER LABEL      UUID                                 FSAVAIL FSUSE% MOUNTPOINT
sda                                                                                
├─sda1 vfat   FAT32 EFI System 4B47-53CA                            1021,4M     0% /boot/efi
├─sda2 btrfs                   619d7b7d-3682-43ce-893e-1bb30343e7f1  530,9G    40% /home
└─sda3 swap   1     swapMX     0bde20b8-bfba-45e3-93b6-f5569e68d988                [SWAP]
sdb                                                                                
└─sdb2

Tem esse sdb2. Não deve ser sdb1 porque fiz o procedimento com o comando dd duas vezes, é que na primeira eu não tinha aberto o journalctl.

$ sudo fdisk -l
Disk /dev/sda: 894,25 GiB, 960197124096 bytes, 1875385008 sectors
Disk model: KINGSTON SA400S3
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 8E9A023E-6B2E-446A-8612-D0DA4451F51A

Device          Start        End    Sectors   Size Type
/dev/sda1        2048    2099199    2097152     1G EFI System
/dev/sda2     2099200 1845299199 1843200000 878,9G Linux filesystem
/dev/sda3  1845299200 1875369983   30070784  14,3G Linux filesystem


Disk /dev/sdb: 1,91 TiB, 2097152000000 bytes, 4096000000 sectors
Disk model: USB 3.0         
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes