Я по ошибке перезапустил свой сервер до завершения изменения размера файловой системы. Вот команда, которая успешно выполнилась перед перезапуском:
lvresize -L -400GB /dev/mapper/vg_yavin-lv_home
При загрузке я получаю эту ошибку
/dev/mapper/vg_yavin-lv_home: UNEXPECTED INCONSITENCY run fsck MANUALLY
Когда я пытаюсь fsck -y /dev/mapper/vg_yavin-lv_home, Я получаю это:
e2fsck 1.41.12 (17-May-2010)
Error reading block 63471616 (Invalid argument). Ignore error? yes
Force rewrite? yes
Error writing block 63471616 (Invalid argument). Ignore error? yes
Superblock has an invalid journal (inode 8).
Clear? yes
*** ext3 journal has been deleted - filesystem is now ext2 only ***
Superblock has_journal flag is clear, but a journal inode is present.
Clear? yes
The filesystem size (according to the superblock) is 127047680 blocks
The physical size of the device is 22190080 blocks
Either the superblock or the partition table is likely to be corrupt!
Abort? yes
Error writing block 63471616 (Invalid argument). Ignore error? yes
Если я закомментирую эту файловую систему в fstab, я могу загрузиться, но есть ли способ восстановить эту файловую систему?
Обратите внимание, что следующий метод не вернет ваши данные. Это может восстановить метаданные вашей группы томов. Вы всегда можете прочитать документацию lvm в руководстве по продукту. В нем есть подробное объяснение команд, которые я собираюсь рассказать.
Закомментируйте fs в fstab, а затем загрузитесь. Теперь найдите VG, на котором вы запустили lvresize. Думаю, это вг_явин.
Запустить это
vgcfgrestore --list <VG-NAME>
Это даст список точек останова на VG до того, как будет выполнена какая-либо существенная операция. Вы должны найти файл, соответствующий вашей операции lvresize. Теоретически он должен быть самым последним.
В этом файле запустите
vgcfgrestore --file /etc/lvm/archive/<file-name> <VG-NAME>
Это восстановит метаданные VG до lvresize.
Загрузитесь нормально и посмотрите, работает ли он.
В сообщении об ошибке ваш суперблок по умолчанию для fs поврежден. Попробуйте загрузиться с резервными суперблоками, которые должны присутствовать, если у вас есть рабочий вывод dumpe2fs. затем
e2fsck -b <backup_sb> <disk-name>
Но в зависимости от коррупции и того, насколько сейчас плохо с фс, все это вероятность.
ProTip: Когда говорится
Бегать
fsckвручную
На самом деле это означает
Бегать
fsckв интерактивном режиме и оцените результат, чтобы решить, что вы хотите сделать
НЕ "слепо использовать -y потому что, похоже, так поступают все остальные, и это ничему не повредит ».
fsck -y может быть разрушительным. Вот почему это не поведение по умолчанию.
Похоже, у вас довольно серьезное повреждение (бит «Ошибка чтения блока 63471616» заставляет меня думать, что возможно физическое повреждение диска), и, честно говоря, fsck могло усугубить ситуацию.
Если у вас есть резервные копии, сейчас самое время их использовать. Если нет, и данные важны, я бы создал образ раздела (вы можете попробовать запустить такие инструменты восстановления, как debugfs на изображении).
В конечном итоге вы, вероятно, захотите просто newfs (или mkextfs, независимо от эквивалента Linux) раздел - если вы уверены, что это не из-за отказа физического диска.
Учитывая ваш последний вопрос, вам, вероятно, просто нужно запустить resize2fs как указано. В настоящее время объем вашего тома уменьшился, но файловая система не уменьшилась, чтобы соответствовать этому. Сделай это, беги fsck снова, и, надеюсь, с вами все будет в порядке.
Вот что я в итоге сделал, и, похоже, теперь он работает нормально
1. закомментировать строку в / etc / fstab
#/dev/mapper/vg_yavin-lv_home /home ext4 defaults 1 2
2. перезапустить
3. воссоздать / перемонтировать
mkfs -c /dev/mapper/vg_yavin-lv_home
fsck /dev/mapper/vg_yavin-lv_home
mount /dev/mapper/vg_yavin-lv_home /home
4.Строка раскомментирования в / etc / fstab
/dev/mapper/vg_yavin-lv_home /home ext4 defaults 1 2
5. перезапустить
Конечно, мы потеряли все наши файлы, но нам действительно не о чем было беспокоиться.