Causas de danos repentinos e maciços ao sistema de arquivos? (“Inode raiz não é um diretório”) [fechado]

Eu tenho um laptop executando o Maverick (muito feliz até ontem), com um SSD Patriot Torx; Criptografia LUKS de toda a partição; um volume físico de lvm além disso; depois home e root em volumes lógicos ext4 além disso.

Quando tentei inicializá-lo ontem, ele reclamou que não podia montar o sistema de arquivos raiz. Executando o fsck, basicamente todos os inodes parecem estar errados. Os sistemas de arquivos doméstico e raiz mostram problemas semelhantes. Verificar um superbloco de backup não ajuda.

e2fsck 1.41.12 (17-May-2010)
lithe_root was not cleanly unmounted, check forced.
Resize inode not valid.  Recreate? no

Pass 1: Checking inodes, blocks, and sizes
Root inode is not a directory.  Clear? no   
Root inode has dtime set (probably due to old mke2fs).  Fix? no
Inode 2 is in use, but has dtime set.  Fix? no
Inode 2 has a extra size (4730) which is invalid
Fix? no
Inode 2 has compression flag set on filesystem without compression support.  Clear? no
Inode 2 has INDEX_FL flag set but is not a directory.
Clear HTree index? no
HTREE directory inode 2 has an invalid root node.
Clear HTree index? no
Inode 2, i_size is 9581392125871137995, should be 0.  Fix? no
Inode 2, i_blocks is 40456527802719, should be 0.  Fix? no
Reserved inode 3 (<The ACL index inode>) has invalid mode.  Clear? no
Inode 3 has compression flag set on filesystem without compression support.  Clear? no
Inode 3 has INDEX_FL flag set but is not a directory.
Clear HTree index? no
....

Correndo stringspelos sistemas de arquivos, vejo como são os nomes de arquivos e os dados do usuário. Eu tenho backups suficientemente bons (touch wood) que não valem a pena vasculhar para recuperar arquivos individuais, embora eu possa salvar uma imagem do disco não criptografado antes da reconstrução, apenas por precaução.

smartctlnão mostra nenhum erro, nem o log do kernel. A execução de um modo de gravação badblocksno swap lv também não encontra problemas. Portanto, o disco pode estar falhando, mas não de uma maneira óbvia.

Neste ponto, basicamente, como eles dizem, fscked? Voltando à reinstalação, talvez executando badblocks no disco e restaurando a partir do backup? Nem parece haver dados suficientes para registrar um bug significativo ...

Não me lembro de que esta máquina travou da última vez que a usei.

Neste ponto, suspeito que um bug ou corrupção de memória tenha causado a gravação de lixo nos discos na última execução, ou algum tipo de modo de falha sutil no SSD.

O que você acha que teria causado isso? Há mais alguma coisa que você tentaria?

Parece que seu primeiro superbloco está corrompido. Existem muitas cópias do superbloco, pois é a parte mais crítica do sistema de arquivos. Você pode tentar e2fsckcom a -bopção de verificar se uma cópia diferente do superbloco possui as informações corretas. Verifique o e2fsck (8) para obter mais informações sobre a -bopção e como determinar a localização dos superblocos adicionais.

IIRC, existe apenas uma cópia do diretório raiz; portanto, se ele foi danificado, ele deverá ser recriado, vazio. Os diretórios originalmente no diretório raiz aparecerão em / lost + found e você precisará realocá-los a partir daí.

As tabelas de inode são espalhadas pela partição. É improvável que você perca todos eles. Os que são recuperáveis, se seus arquivos não puderem ser realocados para seus diretórios originais, eles também terminarão em / lost + found.

Eu já vi isso antes. É algo a ver com o Ubuntu 10.10. Eu procurava no rastreador de erros, pois ele foi publicado algumas vezes. Para ter certeza, tire um instantâneo do disco, limpe-o e solte-o em um sistema secundário para ver se o bug se repete (para descartar o disco - culpado improvável).

Atualização: Eventualmente, fiquei convencido de que o problema era algum tipo de falha complicada do SSD, ou suponho que possivelmente haja uma interação entre o kernel e o SSD. Substituí-o por um disco magnético e não tive problemas novamente.