Erro EXT3-fs (dispositivo dm-10)

1

Eu recebi este erro de log abaixo:

Aug  1 20:44:01 TDBP24LV kernel: EXT3-fs error (device dm-10): ext3_free_blocks_sb: bit already cleared for block 8159746
Aug  1 20:44:01 TDBP24LV kernel: EXT3-fs error (device dm-10): ext3_free_blocks_sb: bit already cleared for block 8159747
Aug  1 20:44:01 TDBP24LV kernel: EXT3-fs error (device dm-10): ext3_free_blocks_sb: bit already cleared for block 8159748
Aug  1 20:44:01 TDBP24LV kernel: EXT3-fs error (device dm-10): ext3_free_blocks_sb: bit already cleared for block 8159749
Aug  1 20:44:01 TDBP24LV kernel: EXT3-fs error (device dm-10): ext3_free_blocks_sb: bit already cleared for block 8159750
Aug  1 20:44:01 TDBP24LV kernel: EXT3-fs error (device dm-10): ext3_free_blocks_sb: bit already cleared for block 8159751
Aug  1 20:44:01 TDBP24LV kernel: EXT3-fs error (device dm-10) in ext3_free_blocks_sb: Journal has aborted
Aug  1 20:44:01 TDBP24LV kernel: EXT3-fs error (device dm-10) in ext3_reserve_inode_write: Journal has aborted
Aug  1 20:44:01 TDBP24LV kernel: EXT3-fs error (device dm-10) in ext3_truncate: Journal has aborted
Aug  1 20:44:01 TDBP24LV kernel: EXT3-fs error (device dm-10) in ext3_reserve_inode_write: Journal has aborted
Aug  1 20:44:01 TDBP24LV kernel: EXT3-fs error (device dm-10) in ext3_orphan_del: Journal has aborted
Aug  1 20:44:01 TDBP24LV kernel: EXT3-fs error (device dm-10) in ext3_reserve_inode_write: Journal has aborted
Aug  1 20:44:01 TDBP24LV kernel: EXT3-fs error (device dm-10) in ext3_delete_inode: Journal has aborted
Aug  1 20:44:01 TDBP24LV kernel: EXT3-fs error (device dm-10): ext3_journal_start_sb: Detected aborted journal

Alguém poderia ajudar?

    
por user3863795 04.08.2014 / 14:34

1 resposta

1

Provavelmente o seu sistema de arquivos mudou automaticamente para o modo somente leitura até agora.

É uma falha geral no seu fs. Provavelmente foi causado por uma falha de gravação.

Se o seu fs ainda estiver gravável, monte-o como readonly ( mount /the/fs/mount/path -o remount,ro ). Se você não pode fazer isso, primeiro você tem que matar qualquer processo que queira / possa escrever alguma coisa lá (você pode encontrá-los com um lsof -n|grep /the/fs/mount/path ).

Em seguida, execute uma verificação do sistema de arquivos ( e2fsck -f -p -C0 /dev/device/path ). Se você não gosta de pressionar y mil vezes, use também -y flag em vez de -p - embora neste caso você diga automaticamente "sim" para todas as ações potencialmente destrutivas do reparo do sistema de arquivos ferramenta.

Depois disso, você pode voltar a gravá-lo novamente ( mount /the/fs/mount/path -o remount,rw ).

Se você puder reinicializar sem problemas (ou seja, você não está trabalhando em seu servidor de missão crítica parters 5000 km por algum tempo), certamente não foi uma prática ruim fazer isso a partir de um shell de raiz de um sistema de recuperação readonly. / p>

Você pode calcular com a mesma perda de dados também, embora não tenha nenhum receio real dessas mensagens de erro ocultas, mesmo que existam muitas. Seu sistema de arquivos provavelmente tem apenas alguns danos, ainda.

    
por 04.08.2014 / 14:42

Tags