Файловая система удаленной системы исчезла после "mdadm --grow 2 /dev/md0"?
Вчера я добавил в систему второй жесткий диск емкостью 500 ГБ. Эта система была установлена как система RAID-1 только с одним диском, потому что у меня не было другого под рукой.
Наконец, добавив второй диск, я запустил "sfdisk -d /dev/sda | sfdisk --force /dev/sdb", как я делал очень часто.
Затем я запустил "mdadm --add /dev/md0 /dev/sdb1", и RAID начал синхронизироваться.
После того, как он был закончен, оказалось, что новые разделы были добавлены как запасные, а не как активные устройства. Похоже, это произошло потому, что устройство RAID 1 считало, что на нем есть место только для одного активного устройства из-за странной установки, которую я сделал.
Итак, сегодня я запустил "mdadm --grow --raid-devices 2 /dev/md0" (заметьте, я не ставил "=" перед "2").
Сразу же вся моя файловая система исчезла!
Я все еще вошел в сессию ssh, но я ограничен встроенными командами bash, что довольно болезненно.
Я составил команду bash-builtin-cat и все еще могу загружать некоторые файлы. /proc/mdstat выглядит хорошо и прекрасно, и указывает, что новый диск теперь действительно активен.
/ var / log / messages (который, как ни странно, все еще доступен, хотя все остальные файлы не доступны), дает мне тысячи:
попытка получить доступ через конец устройства md0: rw = 0, want = 868055984, limit = 4
(число после "хочу" меняется). Все сообщения были сгенерированы через пару секунд после запуска mdadm --grow, а затем остановлены.
Как уже упоминалось, это удаленная машина.
- что, черт возьми, здесь произошло?
- Есть ли способ отменить то, что сделал этот - Гроу?
- Могу ли я удалить новый диск с устройства RAID, просто отображая его в скрытых / proc файлах (поскольку mdadm больше не найден)?
- я должен вызвать перезагрузку SysRq и надеяться на лучшее?
1 ответ
Ну, странная перезагрузка все же исправила проблему.
После перезагрузки компьютер загрузился нормально, и теперь он снова перестраивает массив RAID 1, и дополнительный диск снова помечается как резервный.
Таким образом, кажется, что команда grow мгновенно заставила файловую систему и доступ к диску исчезнуть - настолько быстро, что даже эффекты команды grow не были записаны на диск.
Странный.
РЕДАКТИРОВАТЬ: Оказывается, диск, на котором были данные, имел поврежденные сектора, поэтому первая первоначальная синхронизация не удалась, и mdadm перевел новый (не полностью синхронизированный) диск в "резервный" режим. Мое временное решение состояло в том, чтобы записать нули в поврежденные сектора (что вы не должны делать!), Используя hdparm (google "hdparm write bad сектора"). По какой-то странной причине это сработало (хотя немного данных было потеряно), и массив сумел завершить свою первоначальную синхронизацию. Теперь я могу извлечь неисправный диск и синхронизировать новый диск с еще более новым.