Причины внезапного массивного повреждения файловой системы? («Корневой индекс не является каталогом») [закрыто]

У меня есть ноутбук под управлением Maverick (очень радостно до вчерашнего дня) с SSD Patriot Torx; LUKS шифрование всего раздела; один физический том lvm поверх этого; затем home и root в ext4 логических томах.

Когда я пытался загрузить его вчера, он жаловался, что не может смонтировать корневую файловую систему. Запуск fsck, в основном, каждый инод кажется неправильным. И домашняя, и корневая файловые системы имеют схожие проблемы. Проверка резервного суперблока не помогает.

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

Работая stringsс файловыми системами, я вижу, что там есть имена файлов и пользовательские данные. У меня есть достаточно хорошие резервные копии (touch wood), поэтому не стоит разбираться, чтобы извлекать отдельные файлы, хотя я могу на всякий случай сохранить образ незашифрованного диска до восстановления.

smartctlне показывает никаких ошибок, также как и журнал ядра. Запуск режима записи badblocksчерез swap lv также не вызывает проблем. Таким образом, диск может выходить из строя, но не очевидным образом.

На данный момент я в основном, как говорится, fscked? Вернемся к переустановке, возможно, запустим блокировку диска и восстановим из резервной копии? Кажется, даже данных недостаточно, чтобы подать значимую ошибку ...

Я не помню, чтобы эта машина разбилась в последний раз, когда я ее использовал.

На данный момент я подозреваю, что ошибка или повреждение памяти приводили к тому, что он записывал мусор на диски при его последнем запуске, или к какому-то неуловимому режиму сбоя для SSD.

Как вы думаете, что вызвало бы это? Есть ли что-нибудь еще, что вы бы попробовали?

Кажется, ваш первый суперблок поврежден. Существует много копий суперблока, поскольку он является наиболее важной частью файловой системы. Вы можете попробовать e2fsckс -bопцией , чтобы проверить , если другая копия суперблоке имеет правильную информацию. Проверьте e2fsck (8) для получения дополнительной информации о -bпараметре и о том , как определить местоположение дополнительных суперблоков.

IIRC, существует только одна копия корневого каталога, поэтому, если он был поврежден, его придется создать заново, пустым. Каталоги, изначально находящиеся в корневом каталоге, появятся в / lost + found, и вам придется переместить их оттуда.

Таблицы Inode распространяются через раздел. Вряд ли вы потеряете их всех. Те, которые можно восстановить, если их файлы не могут быть перемещены в их исходные каталоги, они также заканчиваются на / lost + found.

Я видел это раньше. Это как-то связано с Ubuntu 10.10. Я бы посмотрел на трекер ошибок, так как он был опубликован несколько раз. Чтобы быть уверенным, сделайте снимок диска, вытрите его, затем поместите его во вторичную систему, чтобы увидеть, повторяется ли ошибка (исключить диск - маловероятный виновник).

Обновление: В конце концов, я убедился, что проблема была в каком-то сложном сбое SSD, или я полагаю, что возможно взаимодействие между ядром и SSD. Я заменил его магнитным диском, и у меня больше не было проблем.