Я использовал все устройство в качестве физического раздела LVM, так что
sudo pvcreate /dev/xvdg
К сожалению, пока это использовалось, я случайно перезаписал некоторые данные (как мне кажется), написав новую таблицу разделов:
sudo fdisk /dev/xvdg, добавить новый раздел, записать таблицу разделов, удалить раздел, записать пустую таблицу разделов
Вот где я сейчас нахожусь. Кажется, что все работает, но я боюсь перезапуска, отключения и т. Д.
Спасибо!
Предполагая, что вы использовали весь диск в качестве lvm pv, а не отдельный раздел внутри него, обычно все должно быть в порядке, поскольку заголовок LVM находится не в первом секторе, где находится таблица разделов, особенно при использовании 512-байтовых секторов .
Таблица разделов находится в первом секторе: см. Например Вот: Жесткие диски можно разделить на один или несколько логических дисков, называемых разделами. Это разделение записывается в таблицу разделов, находящуюся в секторе 0 диска.
Заголовок LVM по умолчанию находится во втором секторе: см. Например Вот: По умолчанию метка LVM размещается во втором 512-байтовом секторе. Вы можете перезаписать это значение по умолчанию, поместив метку в любой из первых 4 секторов. Это позволяет томам LVM при необходимости сосуществовать с другими пользователями этих секторов.
Осторожно: я не уверен, что произойдет, если размер сектора, который использует fdisk, больше, скажем, 1024 байта - LVM все еще может находиться во втором 512-байтовом секторе, а fdisk может перезаписать весь 1024-байтовый сектор?
В качестве отступления: если вы не уверены и имеете доступ к дополнительному пространству (например, на Amazon EC2), вы всегда можете создать том идентичного размера, выполнить на нем pvcreate, добавить его в группу томов, использовать pvmove для перемещения данных на новый том, а затем vgreduce, чтобы удалить затронутый том.
Да, в 99,99% случаев он сломан. Причина в том, что вы перезаписали таблицу разделов. Метаданные lvm находятся во втором 512-байтовом секторе PV. Итак, при создании нового раздела, если вы коснулись этих секторов, ваши метаданные были стерты. По сути, перезапуск, umount все испортит.
Есть два возможных (но, возможно, неосуществимых) взлома.
1) Если вы знаете точную таблицу разделов последней удачной файловой системы, вы можете запустить fdisk и попытаться создать ее в том же точном порядке. Вы должны знать, в каких секторах старые fs начинались и заканчивались. Создайте раздел, как раньше, и это может сработать.
2) Если что-то не работает, тогда есть другой способ обхода pvcreate. Ваша последняя известная резервная копия lvm будет храниться в /etc/lvm/archive/volume_group_name_XXXX.vg файл. Вам нужно получить оттуда UUID PV. Затем, если вам удобнее, вы можете это сделать.
pvcreate --uuid <put_uuid_here> /etc/lvm/archive/volume_group_name_XXXX.vg <physical-volume name>
Но если вы можете, пожалуйста, сначала сделайте резервную копию ваших данных. pvcreate не затрагивает пользовательские данные, он имеет дело только с метаданными, но если во время загрузки fsck обнаружит любую несогласованность, она может выбросить вас с ошибками fs и потенциально невосстановимым диском.