Causes de dommages soudains massifs au système de fichiers? («L'inode racine n'est pas un répertoire») [fermé]

J'ai un ordinateur portable exécutant Maverick (très heureusement jusqu'à hier), avec un SSD Patriot Torx; Cryptage LUKS de toute la partition; un volume physique lvm en plus de cela; puis home et root dans les volumes logiques ext4 en plus de cela.

Hier, lorsque j'ai essayé de le démarrer, il s'est plaint de ne pas pouvoir monter le système de fichiers racine. En exécutant fsck, chaque inode semble fondamentalement avoir tort. Les systèmes de fichiers home et root présentent des problèmes similaires. La vérification d'un superbloc de sauvegarde n'aide pas.

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
....

En stringsparcourant les systèmes de fichiers, je peux voir qu'il y a des noms de fichiers et des données utilisateur. J'ai suffisamment de bonnes sauvegardes (toucher du bois) pour que cela ne vaille pas la peine de récupérer des fichiers individuels, bien que je puisse enregistrer une image du disque non chiffré avant de reconstruire, au cas où.

smartctln'affiche aucune erreur, pas plus que le journal du noyau. L'exécution d'un mode d'écriture badblockssur le swap lv ne trouve pas non plus de problèmes. Le disque peut donc échouer, mais pas de manière évidente.

À ce stade, je suis fondamentalement, comme on dit, fscked? Retour à la réinstallation, peut-être exécuter des badblocks sur le disque, puis restaurer à partir de la sauvegarde? Il ne semble même pas y avoir suffisamment de données pour signaler un bug significatif ...

Je ne me souviens pas que cette machine soit tombée en panne la dernière fois que je l'ai utilisée.

À ce stade, je soupçonne qu'un bogue ou une corruption de mémoire l'ont fait écrire des ordures sur les disques lors de sa dernière exécution, ou une sorte de mode d'échec subtil pour le SSD.

Selon vous, qu'est-ce qui aurait causé cela? Y a-t-il autre chose que vous voudriez essayer?

Il semble que votre premier superbloc soit corrompu. Il existe de nombreuses copies du superbloc, car il s'agit de la partie la plus critique du système de fichiers. Vous pouvez essayer e2fsckavec l' -boption de vérifier si une copie différente du superbloc contient les informations correctes. Consultez e2fsck (8) pour plus d'informations sur l' -boption et comment déterminer l'emplacement des superblocs supplémentaires.

IIRC, il n'y a qu'une seule copie du répertoire racine, donc s'il a été endommagé, il devra être recréé, vide. Les répertoires initialement sous le répertoire racine apparaîtront dans / lost + found et vous devrez les déplacer à partir de là.

Les tables d'inode sont réparties sur la partition. Il est peu probable que vous les perdiez tous. Ceux qui sont récupérables, si leurs fichiers ne peuvent pas être déplacés vers leurs répertoires d'origine, ils se termineront également par / lost + found.

Je l'ai déjà vu auparavant. C'est quelque chose à voir avec Ubuntu 10.10. Je regarderais autour du bug tracker car il a été posté plusieurs fois. Pour être sûr, prenez un instantané du disque, essuyez-le puis déposez-le dans un système secondaire pour voir si le bogue se répète (pour exclure le disque - coupable improbable).

Mise à jour: Finalement, je suis devenu convaincu que le problème était une sorte de panne compliquée du SSD, ou je suppose peut-être une interaction entre le noyau et le SSD. Je l'ai remplacé par un disque magnétique et je n'ai plus eu de problème.