fsck mostra erros do sistema de arquivos ext4, mas apenas ao inicializar a partir da partição do sistema

Question

Estou tendo um problema com a partição do sistema ext4. Estou correndo 17.04 (atualizado de 16.10), mas o problema já estava presente em 16.10.

Ocasionalmente (mais comumente depois de acordar o sistema de suspensão) o sistema trava com um monte de erros no sistema de arquivos ext4.

Agora, ao verificar o sistema de arquivos com

sudo fsck -n /dev/nvme0n1p2

fsck afirma que o sistema de arquivos está limpo

fsck from util-linux 2.29
e2fsck 1.43.4 (31-Jan-2017)
Warning!  /dev/nvme0n1p2 is mounted.
Warning: skipping journal recovery because doing a read-only filesystem check.
/dev/nvme0n1p2: clean, 434755/15089664 files, 46490132/60347136 blocks

No entanto, se eu forçar um cheque, recebo um monte de erros:

sudo fsck -nf /dev/nvme0n1p2
fsck from util-linux 2.29
e2fsck 1.43.4 (31-Jan-2017)
Warning!  /dev/nvme0n1p2 is mounted.
Warning: skipping journal recovery because doing a read-only filesystem check.
Pass 1: Checking inodes, blocks, and sizes
Inodes that were part of a corrupted orphan linked list found.  Fix? no

Inode 131275 was part of the orphaned inode list.  IGNORED.
Inode 135221 was part of the orphaned inode list.  IGNORED.
Inode 135244 was part of the orphaned inode list.  IGNORED.
Inode 135260 was part of the orphaned inode list.  IGNORED.
Inode 135263 was part of the orphaned inode list.  IGNORED.
Inode 135268 was part of the orphaned inode list.  IGNORED.
Deleted inode 135272 has zero dtime.  Fix? no

Inode 135274 was part of the orphaned inode list.  IGNORED.
Inode 135384 was part of the orphaned inode list.  IGNORED.
Inode 135396 was part of the orphaned inode list.  IGNORED.
Inode 135697 was part of the orphaned inode list.  IGNORED.
Inode 135711 was part of the orphaned inode list.  IGNORED.
Inode 135713 was part of the orphaned inode list.  IGNORED.
Inode 12059086 was part of the orphaned inode list.  IGNORED.
Inode 12061077 was part of the orphaned inode list.  IGNORED.
Inode 12062594 was part of the orphaned inode list.  IGNORED.
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Block bitmap differences:  -(40927357--40927367) -(40927563--40927569) -(40940652--40940653) -(40940676--40940681) -(48296964--48296970) -(48296978--48296984) -(48304145--48304165) -(48304315--48304321) -(48326677--48326690) -(48326733--48326739) -(48326775--48326781)
Fix? no

Free blocks count wrong (13857004, counted=13856542).
Fix? no

Inode bitmap differences:  -131275 -135221 -135244 -135260 -135263 -135268 -135272 -135274 -135384 -135396 -135697 -135711 -135713 -12059086 -12061077 -12062594
Fix? no

Free inodes count wrong (14654909, counted=14654758).
Fix? no


/dev/nvme0n1p2: ********** WARNING: Filesystem still has errors **********

/dev/nvme0n1p2: 434755/15089664 files (0.3% non-contiguous), 46490132/60347136 blocks

Agora, meu problema é que não posso corrigir esses erros, pois é a partição do meu sistema, que não posso desmontar. Mas quando eu inicializo de uma unidade externa ou no modo de recuperação, o fsck não relata nenhum erro, mesmo com -f . Após a reinicialização do meu sistema, no entanto, os erros persistem. Eu estou atualmente em uma perda como eu poderia consertar o sistema de arquivos. Qualquer ajuda seria muito apreciada.

    

Answer 1

Se você forçar uma verificação do sistema de arquivos em um sistema de arquivos ext4 que esteja montado no modo r / w usando fsck -nf <filesystem> , sempre obterá mensagens de erro como as que você postou ( lista vinculada órfã corrompida , inode excluído ... tem zero dtime ). O fato de que fsck -n <filesystem> o relata como limpo é um pouco enganador aqui.

O motivo pelo qual você não está vendo esses erros no modo de recuperação ou quando inicializado a partir da unidade externa é simplesmente o fato de que, nesse caso, o sistema de arquivos em questão não está montado no modo r / w ou .

A página de manual do e2fsck também declara explicitamente:

% bl0ck_qu0te%

Conclusão : Se você pretende usar o -f flag para fsck, certifique-se de entender 100% o que ele faz. Em particular, usá-lo em um sistema de arquivos montado geralmente não é o que você deseja.

Por que você está recebendo erros ext4 quando acordar da suspensão é um problema completamente diferente que parece ter resolvido. Por razões de referência, incluirei os links que você postou em um comentário aqui, pois eles foram úteis para resolver seu problema original:

• Erro EXT4-fs após o upgrade do Ubuntu 17.04
• link