Вопрос или проблема
Я использую LVM RAID 1 на двух дисках. Вот что lvs сообщает мне о моем VG:
root@picard:~# lvs -a -o +devices,lv_health_status,raid_sync_action,raid_mismatch_count
/run/lvm/lvmetad.socket: подключение не удалось: Нет такого файла или каталога
WARNING: Не удалось подключиться к lvmetad. Переход на внутреннее сканирование.
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert Devices Health SyncAction Mismatches
lv-data vg-data rwi-aor-r- 2.70t 100.00 lv-data_rimage_0(0),lv-data_rimage_1(0) refresh needed idle 0
[lv-data_rimage_0] vg-data iwi-aor-r- 2.70t /dev/sda(0) refresh needed
[lv-data_rimage_1] vg-data iwi-aor--- 2.70t /dev/sdb(1)
[lv-data_rmeta_0] vg-data ewi-aor-r- 4.00m /dev/sda(708235) refresh needed
[lv-data_rmeta_1] vg-data ewi-aor--- 4.00m /dev/sdb(0)
Похоже, что-то пошло не так на /dev/sda. SMART-журнал этого диска выглядит хорошо, поэтому я надеюсь, что это просто временная проблема, и я хотел бы обновить / ресинхронизировать мой RAID. Вот что я делаю:
root@picard:~# lvchange --refresh vg-data/lv-data
/run/lvm/lvmetad.socket: подключение не удалось: Нет такого файла или каталога
WARNING: Не удалось подключиться к lvmetad. Переход на внутреннее сканирование.
(…ждем несколько минут…)
root@picard:~# lvs -a -o +devices,lv_health_status,raid_sync_action,raid_mismatch_count
/run/lvm/lvmetad.socket: подключение не удалось: Нет такого файла или каталога
WARNING: Не удалось подключиться к lvmetad. Переход на внутреннее сканирование.
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert Devices Health SyncAction Mismatches
lv-data vg-data rwi-aor-r- 2.70t 100.00 lv-data_rimage_0(0),lv-data_rimage_1(0) refresh needed idle 0
[lv-data_rimage_0] vg-data iwi-aor-r- 2.70t /dev/sda(0) refresh needed
[lv-data_rimage_1] vg-data iwi-aor--- 2.70t /dev/sdb(1)
[lv-data_rmeta_0] vg-data ewi-aor-r- 4.00m /dev/sda(708235) refresh needed
[lv-data_rmeta_1] vg-data ewi-aor--- 4.00m /dev/sdb(0)
Итак, ничего не произошло? Мой dmesg показывает, что он пытался восстановить RAID:
[150522.459416] device-mapper: raid: Неисправное устройство raid1 #0 имеет читаемый суперблок. Пытаемся оживить его.
Ну, хорошо, может быть, проверка данных (scrubbing) поможет? Давайте попробуем это:
root@picard:~# lvchange --syncaction repair vg-data/lv-data
/run/lvm/lvmetad.socket: подключение не удалось: Нет такого файла или каталога
WARNING: Не удалось подключиться к lvmetad. Переход на внутреннее сканирование.
root@picard:~# lvs -a -o +devices,lv_health_status,raid_sync_action,raid_mismatch_count
/run/lvm/lvmetad.socket: подключение не удалось: Нет такого файла или каталога
WARNING: Не удалось подключиться к lvmetad. Переход на внутреннее сканирование.
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert Devices Health SyncAction Mismatches
lv-data vg-data rwi-aor-r- 2.70t 100.00 lv-data_rimage_0(0),lv-data_rimage_1(0) refresh needed idle 0
[lv-data_rimage_0] vg-data iwi-aor-r- 2.70t /dev/sda(0) refresh needed
[lv-data_rimage_1] vg-data iwi-aor--- 2.70t /dev/sdb(1)
[lv-data_rmeta_0] vg-data ewi-aor-r- 4.00m /dev/sda(708235) refresh needed
[lv-data_rmeta_1] vg-data ewi-aor--- 4.00m /dev/sdb(0)
Здесь несколько странных моментов:
SyncActionравенidle, то есть, похоже, что проверка данных завершилась мгновенно?- Если проверка данных завершена, и массив все еще нуждается в обновлении, как может считаться, что несовпадения равны 0? Разве проверка данных не должна обнаруживать несовпадения и либо исправлять их (то есть очищать статус “необходима перезагрузка”) либо увеличивать счетчик несовпадений?
dmesg говорит:
[150695.091180] md: выполнена повторная синхронизация массива RAID mdX
[150695.092285] md: mdX: выполнена повторная синхронизация.
Это также выглядит так, как будто проверка данных ничего не сделала.
Вопросы
- Как вызвать реальную проверку данных?
- Предположим, что диск не неисправен – как обновить массив?
- Если диск был неисправен (т.е. обновление наткнулось на ошибку сразу) – как бы я это заметил? Я предполагаю, dmesg должен показать некоторые ошибки ввода-вывода? (Я их не вижу…)
Информация о системе
Я использую Armbian на основе Ubuntu 16.04.4 LTS. Версия LVM:
root@picard:~# lvm version
Версия LVM: 2.02.133(2) (2015-10-30)
Версия библиотеки: 1.02.110 (2015-10-30)
Название драйвера: 4.37.0
Вот несколько полезных команд:
lvchange --refresh VG/lvol0lvconvert --repair VG/lvol0lvs --all --options +devices,seg_size_pe,seg_size,copy_percent --segments
PS: Я знаю, что это довольно старый вопрос, но он оказался первым, когда я искал информацию, чтобы освежить память…
Ответ или решение
Концепция объединения нескольких дисков в RAID-массивы давно используется для обеспечения надежности и отказоустойчивости данных. В вашем случае речь идет о LVM RAID 1, в котором данные дублируются на двух дисках, что обеспечивает устойчивость к сбоям одного из них. Однако, даже такой надежный механизм может дать сбой, как в вашем случае, когда состояние "needs refresh" не уходит и не удается запустить сканирование или синхронизацию.
Теория
Прежде всего, нужно понять, что означает маркировка "needs refresh" и почему RAID-массив может оказаться в таком состоянии. В частности, для RAID 1 в LVM такое предупреждение может быть связано с:
- Нарушением синхронности данных между дисками.
- Ошибками в метаданных, ответственными за отражение актуального состояния зеркал.
- Потенциальным сбой оборудования, хотя в вашем случае SMART информация не указывает на проблему с дисками.
Система логически разделяет объемы на сегменты, управляя ими через устройства, включенные в группу томов (Volume Group). LVM RAID использует метаданные для отслеживания состояния и обеспечения целостности данных, поэтому, если метаданные повреждены или не обновлены, это может повлиять на весь массив.
Пример
Ваш случай демонстрирует типичную проблему: LVM сообщает о необходимости обновления массивов, однако несмотря на попытки ресинхронизации и сканирования (scrubbing), проблемы не разрешаются. Команды lvchange --refresh и lvchange --syncaction repair служат для инициирования процессов восстановления, но без заметного эффекта. Может быть несколько причин для этого:
- Отказ в физическом доступе или ошибка ввода-вывода может не быть явной, но повлиять на работу.
- Конфигурационные ошибки или несовместимость версии LVM могут также препятствовать правильному обновлению информации.
Вы видите, что команды не дают результата, а dmesg показывает мгновенное завершение операции и отсутствуют несоответствия (mismatch count равен 0), это может указывать на отсутствие реальных проблем с дисками, однако плохая работа функции восстановления.
Применение
Что можно сделать в такой ситуации:
-
Проверка логов и диагностика:
- Повторно проверьте dmesg на наличие всех сообщений, связанных с I/O — иногда ошибки могут появляться в неожиданных местах или сформулированы так, что их легко спутать с обычной диагностикой.
- Используйте
journalctlили аналогичные средства, чтобы убедиться, что нигде не упущено сообщение об ошибке.
-
Версионный контроль и обновление:
- Вы используете устаревшую версию LVM и ядра для вашего дистрибутива. Если возможно, обновитесь до более актуальной версии. В современных системах устранены многие баги и улучшена поддержка операций.
-
Ручное вмешательство:
- Попробуйте перезагрузить систему, затем попытайтесь повторно инициировать процесс восстановления или обновления.
- Если LVM все ещё сообщает о необходимости обновления, возможно, нужно вручную очистить состояние или метаданные, что может включать в себя временное отключение и повторное добавление проблемного диска.
-
Комплексная проверка устройств:
- Кроме SMART, используйте другие утилиты, такие как
badblocks, для проверки физических секторов диска.
- Кроме SMART, используйте другие утилиты, такие как
-
Резервное копирование данных:
- Обязательно сделайте резервное копирование всего важного перед проведением любых злоёных операций. Даже в случае RAID 1 есть риск утери данных при неудачных восстановительных операциях.
Замыкая всё вместе, твердое понимание состояния LVM RAID и тесная работа с системными логами и диагностическими инструментами в арсенале администратора помогут минимизировать риски и обеспечить сохранность данных. Каждый случай уникален, однако общие стратегии остаются применимыми и упрощают управление сложными системами.