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 -alMv /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 ….
PS: Em outras situações que precisei utilizar o fsck observei que as opções “av” não resolvia exatamente todas as situações de automatização, ela não resolvia situações onde a única solução seria a exclusão completa de um diretório, por isto acabei utilizando a execução manual do comando com as opções “lMv”.
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
