Если я сделаю снимок, например, в vmware / vbox, и вскоре после того, как удалю файл размером 5 ГБ ... файл дельты снимка вырастет на 5 ГБ вместе с содержимым удаленных файлов, чтобы его можно было восстановить путем восстановления снимка.
Если позже, вместо того, чтобы восстанавливать снимок, я предпочитаю удалить снимок, чтобы он объединил файл дельты с базовым диском. Насколько я понимаю, он синхронизирует базовый диск, воспроизводя / объединяя транзакции создания / изменения из моментального снимка.
Какова логика файла размером 5 ГБ, который находится в снимке? Он не будет воссоздан на базовом диске во время слияния. Как он знает, что нужно пропустить этот файл во время слияния? Он просто ищет существующий inode?
Спасибо fLo
Я не могу обязательно разговаривать с vBox, но следующее относится к VMware.
Когда вы удаляете файл с виртуальной машины с активным моментальным снимком, дельта-диск не увеличивается на размер удаленного файла.
Я могу подтвердить это, потому что после комментариев к ответу Майкла я пошел и протестировал его на своей системе vSphere 5.5.
Тест
Результаты
Дельта-диск оказался размером всего около 1 ГБ.
Объяснение
Когда вы думаете об этом, это имеет смысл, поскольку дельта-диски основаны на блоках, а не на файлах. Если один и тот же дисковый блок перезаписывается 10 раз, пока активен моментальный снимок, дельта отслеживает не ВСЕ изменения, а только текущее состояние этого блока.
Шаблон ввода-вывода для чтения начинается с поиска запрошенных блоков в самом последнем моментальном снимке (так называемых дельта-дисках) текущей ветки, затем продвигается вверх по ветке, пока не достигнет базового диска, пока не найдет его.
Как правило, удаление файла не приводит к обнулению потребляемых блоков, а скорее обновляет указатели, которые позволяют файловой системе находить удаляемые блоки. Вероятно, из этого правила есть исключения, но давайте оставим это в общих чертах.
Теперь, когда вы удаляете снимок, вы фактически говорите Мне нравятся эти блоки и я хочу сделать их "постоянными". При этом блоки из рассматриваемого снимка будут применены к родительскому объекту.
С другой стороны, возврат к снимку эффективно говорит о том, что я не как эти блоки и желаю, чтобы их никогда не было. Это изменяет указатели дисков виртуальной машины на использование родителя, игнорируя содержимое дельты и оставляя их в покое.
Кроме того, возврат! = Удаление. Вы можете возвращаться без удаления, и вы можете возвращаться к снимку столько раз, сколько захотите.
И последнее, что касается блоков в VMDK.
Если вы используете диски с тонкой подготовкой, то ни один из блоков фактически не существует в VMDK, пока ОС не запросит их запись. В этот момент они обнуляются, а затем передают ОС. Предположительно, чтение блока, который никогда не использовался, просто приводит к тому, что гипервизор просто возвращает нули.
Это дает преимущество в использовании меньшего пространства, когда вы начинаете и со временем растете. Тем не мение, VMDK никогда не сжимаются. Во всяком случае, не без особых усилий со стороны виртуального админа.
Ладно, я здесь достаточно долго, и я уверен, что мог бы сформулировать и организовать этот ответ намного лучше, но я думаю, что это все есть ...
Получилось ровно наоборот:
если ты возвращаться в ваш снимок, то все, что в нем, воспроизводится (в обратном порядке) и объединяется с томом, с которого был сделан снимок. Это делает том идентичным снимку, и снимок уничтожается.
если ты Удалить снимок, вообще ничего не сливается; моментальный снимок просто уничтожается, а ваш том, на котором уже есть текущее состояние вашей файловой системы, не изменяется.