Посыпался жесткий диск в массиве LVM. ЧЕМ ПРОВЕРИТЬ ЦЕЛОСТНОСТЬ ФС?

[RuMan662]

Добрый день,

Имеется Ubuntu Server и массив LVM2 на трех HDD: 2.0, 1.5, 0.5 ТБ. На каждом из них файловая система XFS. Посыпался один из жестких дисков (тот что на 2.0ТБ). Доступ к массиву еще есть, но примерно 10%-15% файлов уже недоступны. Чтение 80% файлов, существенно медленнее чем ранее (килобайты в секунду), оставшиеся читаются на прежней скорости. Запустить ни long ни short тесты через SMART уже не могу, тесты завершаются с ошибкой не запустившись.

Судя по информации от SMART, диск находится в предсмертном состоянии (1265 bad-блоков на текущий момент).

У меня вопросы:
1) Как можно проверить логическую целостность самого LVM2 массива? Есть утилиты типа fsck для него? vgch не работает, тут же завершается без каких-либо ошибок. xfs_check, xfs_repair тоже выдали что-то несуразное и проверять не стали.
2) Как проверить целостность файловых систем входящих в массив? Для облегчения процесса я купил hdd объемом 4ТБ и сделал pvmove
для дисков 1.5ТБ и 0.5ТБ. Процесс прошел без ошибок. Делать тоже самое для битого опсаюсь-чтобы не отказало все окончательно.
3) Можно ли проверить на бэдблоки в моем случае и купировать такие файлы? Объясняю процесс копирования через mc выглядит так: копируется до проблемного файла: выводит сообщение от ОС об ошибке, если нажать "Пропустить все" - то LVM массив размонтируется, и обратно монтировать приходится вручную. Если нажать "Пропустить" то это приходиться делать для каждого из скольки-то миллионов файлов. Вкупе с крайне медленным чтением- это уже заняло у меня несколько дней. Обычный файловый проводник при открытии папки долго думает, потом вылетает с ошибкой ввода-вывода, после чего массив размонтируется.
4) Безопасно ли сделать pvmove не слетит ли операция при первом же встреченном бэдблоке, оставив массив в промежуточном состоянии?

У меня есть подозрение что посыпавшиеся участки пришлись на область метаданных диска, и исправив эту проблему я исправлю проблему доступа к файлам хотя-бы для того чтобы забрать все необходимое с него. Полагаю что выполнять pvmove c носителя, расположение bad-блоков которого уже заранее известно -будет безопаснее, чем на читая прямо по битым участкам.

sudo xfs_check /dev/Storage/StorageDrive
ERROR: The filesystem has valuable metadata changes in a log which needs to
be replayed.  Mount the filesystem to replay the log, and unmount it before
re-running xfs_check.  If you are unable to mount the filesystem, then use
the xfs_repair -L option to destroy the log and attempt a repair.
Note that destroying the log may cause corruption -- please attempt a mount
of the filesystem before doing this.
localroot@localroot-System-Product-Name:~$
-------------------------------------------------------------------------------------------
localroot@localroot-System-Product-Name:~$ sudo xfs_repair /dev/Storage/StorageDrive
Phase 1 - find and verify superblock...
Фаза 2 - использование внутреннего журнала
        - zero log...
ERROR: The filesystem has valuable metadata changes in a log which needs to
be replayed.  Mount the filesystem to replay the log, and unmount it before
re-running xfs_repair.  If you are unable to mount the filesystem, then use
the -L option to destroy the log and attempt a repair.
Note that destroying the log may cause corruption -- please attempt a mount
of the filesystem before doing this.
localroot@localroot-System-Product-Name:~$

[_angus_]

Первым делом!! при помощи ddrescue делаем образ посыпанного на исправный пустой диск

Код: [Выделить]

sudo ddrescue -d -f --sector-size=<размер сектора битого диска в байтах> /dev/sd<битый> /dev/sd<исправный> <логфайл> Потом метим битое на живом диске:

Код: [Выделить]

echo -n "BAD!BAD!BAD!BAD!" > /удобный\ путь/badd
sudo ddrescue -d -f --fill=- /удобный\ путь/badd /dev/sd<исправный_уже_с_образом> <логфайл>
При этом сектора, которые не прочлись, будут записаны сигнатурой.

Потом меняем в LVM битый диск на живой, монтируем на чтение, потом делаем что угодно. что побилось в файлах -- видно по grep BAD\!BAD\! или как-то так. файловую систему проверить штатными средствами. что там нынче для xfs, не помню.

[RuMan662]

Спасибо за ответ,

Я решил пойти по пути создания дампа файловой системы и последующей проверке самого дампа (посредством xfs_metadump, метод описан тут http://geekblood.com/2014/08/13/filesystem-corruption-xfs-and-rhelv7/). Дамп создавался часов 5 выдав по ходу исполнения неимоверное  число ошибок чтения. Ночью запустил проверку на badblock и за ночь сдвинулось только на 1.18%. Число битых блоков -уже перевалило за миллион. После того как будет ясна картина по поверхности, потрачу несколько дней для копирования оставшегося ценного и попробую сделать pvmove.

ddrescue  делать не стал, потому-что образ с 2ТБ винта потребует столько же места и х.з. сколько времени.

P.S. Странно как-то, все было нормально 3 года. Потом сбойнуло но очнулось, а потом сбойнуло и не очнулось. Несколько миллионов битых блоков за два дня, возможно дело вовсе не в поверхности...