Причины внезапного массивного повреждения файловой системы? («Корневой индексный дескриптор не является каталогом») [закрыто]
У меня есть ноутбук с 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
....
Запустив строки в файловых системах, я вижу, что там есть то, что похоже на имена файлов и пользовательские данные. У меня достаточно хороших резервных копий (прикоснитесь к дереву), поэтому не стоит копаться, чтобы извлечь отдельные файлы, хотя на всякий случай я могу сохранить образ незашифрованного диска перед восстановлением.
smartctl не показывает ошибок, как и журнал ядра.Запуск режима записи badblocks через lv подкачки также не обнаруживает проблем. Так что диск может выйти из строя, но не очевидным образом.
Тут я в основном, как говорится, fscked? Вернемся к переустановке, возможно, запуску плохих блоков на диске, а затем восстановлению из резервной копии? Кажется, не хватает даже данных, чтобы зарегистрировать значимую ошибку ...
Я не помню, чтобы эта машина давала сбой в прошлый раз, когда я ее использовал.
На этом этапе я подозреваю, что ошибка или повреждение памяти привели к записи мусора на диски при последнем запуске, или какой-то режим скрытого сбоя для SSD.
Как вы думаете, что могло вызвать это? Вы бы что-нибудь еще попробовали?
Обновление: В конечном счете я стал убежденным, проблемой был некоторый сложный отказ SSD, или я предполагаю возможно взаимодействие между ядром и SSD. Я заменил его магнитным диском, и я не испытал затруднения снова.
Кажется, что Ваш первый суперблок поврежден. Существует много копий суперблока, так как это - самая критическая часть файловой системы. Можно попробовать e2fsck с -b опция проверить, имеет ли другая копия суперблока корректную информацию. Проверьте e2fsck (8) для получения дополнительной информации о -b опция, и как определить местоположение дополнительных суперблоков.
IIRC, существует только одна копия корневого каталога, поэтому если это было повреждено, это должно будет быть воссоздано, пустое. Каталоги первоначально под корневым каталогом появятся в/lost+found, и необходимо будет переместить их оттуда.
Таблицы Inode распространены через раздел. Маловероятно, что Вы потеряли бы всех их. Те, которые являются восстанавливаемыми, если их файлы не могут быть перемещены к их исходным каталогам, они также закончат в/lost+found.
Я видел это прежде. Это - что-то, чтобы сделать с Ubuntu 10.10. Я озирался бы на средстве отслеживания ошибки как его, отправленный несколько раз. Безусловно, возьмите снимок диска, вытрите его, затем отбрасывают его во вторичной системе, чтобы видеть, повторяется ли ошибка (для исключения диска - маловероятный преступник).