Назад | Перейти на главную страницу

lvудаление снимка: «-реальные» файлы остались, какие они, безопасно удалить?

Я удалил том снимка с помощью lvremove. Он говорит, что успешно удалил его. Но я заметил, что в / dev / mapper все еще есть "-реальный" файл. Я считаю, что эти «-реальные» файлы каким-то образом связаны со снимками, потому что, когда я раньше создавал и удалял снимки, они тоже появлялись и исчезали.

Итак, мне интересно, что это за файлы, и безопасно ли их удалить?

ОБНОВЛЕНИЕ 08/06/2015: с правильными терминами Google («файлы снимков lvm / dev / mapper») я смог найти следующую страницу, которая описывает эти файлы: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Logical_Volume_Manager_Administration/device_mapper.html В настоящее время в процессе чтения страницы, чтобы узнать, что это за файлы и как с ними работать.

После прочтения вышеупомянутого документа и долгой игры в моей системе в попытке понять, что происходит, я думаю, что у меня есть ответ.

«настоящий» файл - это копия таблицы схемы устройств для исходного LV до создания каких-либо снимков. Таблица сопоставления для "реального" файла выглядит точно так же, как таблица сопоставления для исходного LV. Это линейный тип устройства, что означает, что чтение и запись происходят, как и следовало ожидать, с одинаковыми старшими и младшими номерами и одинаковыми смещениями и длиной. В моем случае основные / второстепенные номера относятся к фактическому жесткому диску / dev / sdb1.

Другими словами: перед созданием снимка:

  • исходный LV -> некоторая область на жестком диске / dev / sdb1

После создания снимка:

  • НАСТОЯЩИЙ файл -> та же область на жестком диске / dev / sdb1. линейное отображение. штатное блочное устройство. Теоретически можно установить это так же, как вы можете установить оригинальный LV, но я не пробовал.
  • оригинальный LV -> где-то еще

Теперь исходный LV имеет тип "snapshot-origin", указывающий на новое "реальное" устройство:

  • исходный LV -> major / minor для REAL файла (253 / x = массив MD, а не / dev / sdb1). Это не обычное блочное устройство.

Исходный LV теперь является типом "моментальный снимок-источник". Это означает, что чтение и запись больше не происходят в обычном режиме. Чтение происходит с НАСТОЯЩЕГО устройства обычно, но запись сначала копирует исходные данные на устройство COW, а затем на «настоящее» устройство.

Кроме того, теперь есть устройство COW и устройство / том SNAPSHOT.

  • КОРОВА -> новая область на жестком диске. линейное отображение.
  • SNAPSHOT -> НАСТОЯЩИЙ + КОРОВА. отображение снимков

Старые данные записываются в COW. это обычное блочное устройство, на которое вы можете нормально читать и писать.

SNAPSHOT не является обычным блочным устройством. Это устройство «моментального снимка». Чтение из SNAPSHOT не вернет новые данные. Будет читать либо из COW, либо из REAL в зависимости от того, где находятся старые данные.

В моем сценарии, когда я пытался lvremove снимок, это дало мне следующую ошибку: Device vol0-xxxx-real (253: 15) используется другим устройством. Не удалось возобновить xxxx. Снятие активации в критическом разделе.

том моментального снимка не был удален. Но, повторив lvremove снова, сообщил об успехе. Том снимка исчез. НО «настоящие» устройства все еще существуют в / dev / mapper. Обратное преобразование таблиц для исходных томов в "линейное", указывающее на базовое оборудование, как и должно быть.

Итак, моя оценка заключается в том, что если таблица карты для исходного тома такая же, как и до создания моментального снимка (что означает, что она должна идентично соответствовать таблице карты для «реального» устройства), это означает, что она указывает на то, где должно. Пока таблицы сопоставления на других устройствах не ссылаются на старший / младший номер «REAL» устройства, можно безопасно удалить «REAL» устройство (а), которое должно было быть автоматически удалено командой lvremove.

Что касается того, как эта ошибка возникла в первую очередь, я заметил одну вещь: - если мой исходный том содержит разделы, и я создаю моментальный снимок, «реальное» устройство создается для LV, но никакие «настоящие» устройства не создаются для перегородки в нем. В этом случае lvremove работает без ошибок.

  • однако в моей проблемной системе были «настоящие» устройства для каждого раздела в LV. Не знаю, как они туда попали. Может это были LV-внутри-LV и запутался механизм моментального снимка ??