Cause di danni improvvisi al filesystem? ("L'inode root non è una directory") [chiuso]

Ho un laptop con Maverick (molto felicemente fino a ieri), con un SSD Patriot Torx; Crittografia LUKS dell'intera partizione; un volume fisico lvm sopra a quello; quindi home e root nei volumi logici ext4.

Quando ho provato ad avviarlo ieri, mi sono lamentato che non poteva montare il filesystem di root. Eseguendo fsck, praticamente ogni inode sembra essere sbagliato. Sia i filesystem home che quelli root mostrano problemi simili. Controllare un superblocco di backup non aiuta.

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

Scorrendo stringsi filesystem, vedo che ci sono quelli che sembrano nomi di file e dati utente lì. Ho dei backup sufficientemente buoni (touch wood) che non vale la pena andare in giro per recuperare i singoli file, anche se potrei salvare un'immagine del disco non crittografato prima di ricostruire, per ogni evenienza.

smartctlnon mostra alcun errore, né il registro del kernel. Anche l'esecuzione di una modalità di scrittura badblockssu swap lv non trova problemi. Quindi il disco potrebbe non funzionare, ma non in modo ovvio.

A questo punto sono praticamente, come si suol dire, fottuto? Torna alla reinstallazione, magari eseguendo i badblock sul disco, quindi ripristinando dal backup? Non sembrano nemmeno esserci dati sufficienti per presentare un bug significativo ...

Non ricordo che questa macchina si è schiantata l'ultima volta che l'ho usata.

A questo punto sospetto che un bug o un danneggiamento della memoria abbia causato la scrittura di immondizia sui dischi quando è stata eseguita l'ultima volta, o una sorta di sottile modalità di errore per l'SSD.

Cosa pensi che avrebbe causato questo? C'è qualcos'altro che vorresti provare?

Sembra che il tuo primo superblocco sia corrotto. Esistono molte copie del superblocco, poiché è il pezzo più critico del filesystem. Puoi provare e2fsckcon l' -bopzione per verificare se una diversa copia del superblocco ha le informazioni corrette. Controllare e2fsck (8) per ulteriori informazioni -bsull'opzione e su come determinare la posizione dei superblocchi aggiuntivi.

IIRC, esiste solo una copia della directory principale, quindi se è stata danneggiata, dovrà essere ricreata, vuota. Le directory originariamente nella directory principale appariranno in / lost + found e dovrai trasferirle da lì.

Le tabelle Inode sono distribuite attraverso la partizione. È improbabile che tu li perda tutti. Quelli che sono recuperabili, se i loro file non possono essere trasferiti nelle loro directory originali, finiranno anche in / lost + found.

L'ho già visto prima. Ha a che fare con Ubuntu 10.10. Mi guarderei in giro sul bug tracker perché è stato pubblicato alcune volte. A dire il vero, scatta un'istantanea del disco, puliscilo e rilascialo in un sistema secondario per vedere se il bug si ripete (per escludere il disco - improbabile colpevole).

Aggiornamento: Alla fine, mi sono convinto che il problema fosse una sorta di complicato fallimento dell'SSD, o suppongo che forse un'interazione tra il kernel e l'SSD. L'ho sostituito con un disco magnetico e non ho più avuto problemi.