Как восстановить файловую систему XFS с ошибкой чтения суперблока

Приведенные выше ответы не помогли мне, когда у меня была эта проблема сегодня (около 9,5 часов назад). Я представлю здесь решение, которое сработало для меня, а также причины, по которым предыдущий ответ не помог.

Симптомы

1. Из ниоткуда любой файл в /home не может быть сохранен / отредактирован и т. д. или какой-либо каталог в списке.
2. dmesg где-то показал xfs_do_force_shutdown called вокруг нескольких других сообщений xfs.
3. xfs_repair не удалось на этапе 1 с superblock read failed с последующим fatal error -- Input/output error
4. Остальная часть моего диска работала безупречно (включая /, т.е. только /home не работал).
5. Пытаться mount приведет к superblock cannot be found (или аналогичная) ошибка, но нет подсказки, что делать дальше.

Решение

Решение основано на эта почта Найджел Смит, главный автор XFS (если я правильно понял). Я повторно опубликую шаги здесь, если предыдущая ссылка устареет. Все следующие операции должны выполняться как root (очевидно).

1. Запустите длительную самопроверку диска: smartctl -t long /dev/sda. Это может занять некоторое время. Вы также можете запустить короткий тест с помощью smartctl -t short /dev/sda если есть относительно недавний длительный тест (как было в моем случае).
2. Изучите тест с помощью: smartctl -l selftest /dev/sda или smartctl -a /dev/sda (последний все отображает, но нужная информация находится почти в самом конце).
3. Последний столбец отчета об испытаниях называется LBA_of_first_error. Это позиция первой ошибки на диске. Из последнего теста (который будет пронумерован "# 1" и будет находиться в верхней части списка) возьмите отображаемое число, разделите его на восемь и усеките до целого числа (см. Исходный пост о том, почему).
4. Затем вы обнулите этот конкретный блок. Это приведет к повреждению конкретного файла в этой позиции. (Но если вы исчерпали все остальные методы, несколько поврежденных файлов - не такая уж большая проблема.) Для этого выполните следующую команду: # dd if=/dev/zero of=/dev/sda conv=sync bs=4096 count=1 seek=*NUMBER_COMPUTED_EARLIER*
5. Проведите небольшой тест и подождите минуту или две до результата. Повторяйте это до тех пор, пока короткий тест не покажет никаких ошибок. Или вы можете проверить приблизительное количество ошибочных блоков с помощью smartctl -A /dev/hda | egrep 'Reallocated|Pending|Uncorrectable' В моем случае я повторял шаги с 1 по 4, пока не уменьшил число ошибок до 24.
6. Бегать xfs_repair /dev/sda (без в -L флаг). Вероятно, это сообщит, что вам следует попытаться смонтировать файловую систему из-за ошибок журнала журнала.
7. Попытайтесь смонтировать эту систему. В моем случае это не удалось, поэтому мне пришлось бежать xfs_repair -L /dev/sda который удаляет журнал журнала (что может привести к удалению данных).
8. Смонтируйте файловую систему и сделайте последнюю резервную копию!

Почему вышеуказанные решения больше не работают

• Первоначальному посту несколько лет. Между тем, в XFS внесено достаточно изменений, чтобы команда SuSE сочла ее достаточно стабильной для использования в качестве основной FS для /home.
• xfs_check было устаревшим в пользу xfs_repair -n.
• Решение Debian было ужасной проблемой и пустой тратой времени. На данный момент Debian не поддержка загрузки UEFI, и эта информация не является на их странице загрузки или на их главной странице часто задаваемых вопросов (это на их Wiki). Итак, чтобы загрузиться с этим, вам нужно отключить UEFI Secureboot в вашем BIOS, а затем загрузиться с помощью ключа. После вы заметите, что там нет xfs инструменты установлены по умолчанию. Так ты сделаешь apt-get install xfsprogs только чтобы понять, что это Debian, их «стабильные» пакеты буквально на годы отстают. Короче говоря, xfs_repair /dev/sda просто висел навсегда. Процесс не удалось убить (даже с помощью sigterm).
• UFS Explorer - это платное программное обеспечение.
• photorec поддерживает только определенные типы файлов (скажем, до свидания с вашими ключами GPG) и восстанавливает все файлы с произвольными именами в одной папке. Удачи вам в прохождении всего этого и поиске нужной информации.

После ошибки воспроизведения XFS попробуйте снова СМОНТИРОВАТЬ раздел, как указано в сообщении об ошибке.

Если все станет слишком запутанным, настоятельно рекомендую скачать UFS Explorer чтобы помочь с глубоким восстановлением файлов из другой системы.

У меня есть раздел XFS на "sda6". В Lubuntu это исправлено, не исправляется и не монтирует раздел XFS на 13.10. При загрузке Lubuntu он говорит, что нужно исправить и попробовать при загрузке исправить файловую систему XFS. Когда я пошел на первую установку Lubuntu, в разделе написано Неизвестно.

Lubuntu не исправил. Используя команду xfs_check для меня не решено.

Я наконец решил вернуться к Debian 7 и переустановите. Это обнаружен все файловые системы и нормально смонтированный XFS раздел.

Я читал много пользователей о файловых системах XFS, поэтому я думаю, что это проблема с изменениями версий ядра, потому что Debian 7 использует версию 3.2 и монтирует XFS обычно без ошибок, но на Ubuntu с последним ядром 3.11 не решает файловую систему XFS.

Я пробовал с CentOS 6.5, но CentOS продолжить работу с RedHat и со старым "стабильным" ядром. Это не будет обнаружен XFS автоматически.

Наконец-то я на Debian 7 делает резервную копию всех данных на разделе XFS и воссоздайте разделы на EXT4.

Из-за того, что RedHat не исправит раздел чтения XFS и некоторые проблемы с XFS (погуглите, сколько пользователей не решило разделы чтения XFS), я обычно выбираю Debian для резервного копирования и перехода на новый, совместимый с ядром 3.11, на EXT4 / btrfs ... файловые системы.

Надеюсь, это кому-то поможет.

Я исправил свой раздел XFS, используя новый загруженный Debian 8.7.1 поверх реального сервера, просто поместил диск поверх этой системы, и он автоматически исправился. Centos 5 и 6 не могут отремонтировать