Como checar e corrigir erros de disco no linux

Author: Ricardo Soares - Postado em: 27/08/2018
Relacionado as categorias: Diversos, Tecnologia | Leave a Comment 





Antes de começarmos listamos as unidades de disco

Primeiro do primeiro identifique o disco, no meu cado eu havia plugado um pendrive de 32G que quero corrigir, então com o comando abaixo podemos ver o comando utilizado e a partição com aproximadamente 32G para particionar

# fdisk -l
Disk /dev/sda: 465,8 GiB, 500107862016 bytes, 976773168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0x93b45529

Dispositivo Inicializar     Start       Fim   Setores   Size Id Tipo
/dev/sda1   *                2048 960172031 960169984 457,9G 83 Linux
/dev/sda2               960174078 976771071  16596994   7,9G  5 Estendida
/dev/sda5               960174080 976771071  16596992   7,9G 82 Linux swap / Solaris

Partition 2 does not start on physical sector boundary.

Disk /dev/sdb: 29,7 GiB, 31914983424 bytes, 62333952 sectors
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: 0x00000000

Dispositivo Inicializar Start      Fim  Setores  Size Id Tipo
/dev/sdb1   *            2048 62333951 62331904 29,7G  c W95 FAT32 (LBA)

Importante: Desmontar unidade

Ok, agora que sabemos onde executar a manutenção (no meu caso o dispositivo /dev/sdb ou /dev/sdb1) primeiro desmontamos o disco pois a execução destes comandos com o disco montado pode gerar problemas.

# umount /dev/

Importante2: Boas práticas antes da correção

Em seguida é uma boa prática visualizar se realmente existem bad blocks pois você pode estar tendo outros problemas …

O comando badblocks faz isto, com a opção v e s você terá um relatório do que está acontecendo enquanto ele checa a unidade

PS: Os parâmetros do comando fsck que iremos comentar a seguir também apresentam um relatório, mas com este você pode prever o que irá acontecer e ter mais dados do que está acontecendo em caso de necessidade.

# badblocks -vs /dev/sdb
Verificando blocos 0 até 31166975
Verificando por blocos defeituosos (teste em modo de leitura):  26.92% done, 7:2 62.74% done, 17:28 elapsed. (0/0/0 errors)

Abaixo o relatório do comando após termino e olha só que legal, esta unidade é um cartão de memória que utilizo em meu celular que não foi montado e foi reportado como problemático pelo android, porem o ubuntu não encontrou nenhum problema nele, porem o comando badblocks não encontrou nenhum defeito. Ocorre que o problema estava no nome de arquivos e na tabela de alocação, com isto eu pude identificar que a unidade estava perfeita, o que era necessário era uma revisão nos nomes de arquivos.

# badblocks -vs /dev/sdb
Verificando blocos 0 até 31166975
Verificando por blocos defeituosos (teste em modo de leitura):  26.92% done, 7:2done                                                 
Pass completed, 0 bad blocks found. (0/0/0 errors)

Fazendo efetivamente as correções

Ok, mas digamos que houvessem problemas, qual o comando a ser executado? Abaixo exemplo de execução do mesmo.

fsck -av /dev/sdb1

# Abaixo exemplo de output gerado no fsck acima
                                               ╖V
  Bad short file name (ƒ╪ÑZÅ─ƒq.
                                ╖V).
  Auto-renaming it.
  Renamed to FSCK0003.603
/Android/data/net.cachapa.libra/cache/â≈:ú┐├V┐.╘w
  Bad short file name (â≈:ú┐├V┐.╘w).
  Auto-renaming it.
  Renamed to FSCK0003.604
/Android/data/net.cachapa.libra/cache/║S╟≤|6."`

huuuummm … olha que legal, o fsck encontrou erros que o badblocks não havia encontrado ….

Elucidação

Neste pendrive eu tenho vários arquivos de música e quando copiei do meu HD linux para meu pendrive eu utilizei alguma técnica (não lembro qual, mas provavelmente um rsync) que não converteu corretamente os dados sendo transportados de um particionamento Ext4 para um particionamento FAT32 gerando alguns nomes que o FAT32 entende como errôneos gerando dúvidas para o android. Com o fsck acima os nomes foram “corrigidos” do jeito “foestes como foestes” e eu pude escutar as músicas na boas, porem se isto acontecer em um ambiente sério o correto seria efetuar backup do pendrive, zerar o mesmo com nova formatação completa, separar algumas horas para renomear da forma adequada os arquivos no Ext4 de maneira a serem compatíveis com o FAT32 e finalmente efetuar nova cópia para o particionamento recém formatado.













Comments

Leave a Reply






Últimos posts