развернуть несколко копий «виртуалки» с максимальной экономией места

Копаю в сторону data deduplication и writable snapshots. Что-то пока не очень.

Посмотрим что nilfs умеет, а то уже лет 5 руки до него не доходят...

zfs нативный под линупс недавно стабильный объявлен. У меня работал дома на файлопомойке уже пару лет «нестабильный» безо всяких косяков. Так что рекомендую. Врубаешь там дедупликацию и вперед.

Складывается впечатление, что с дедупликацией не так всё в шоколаде.

т.к. в процессе работы данные будут меняться

Данные пусть меняются, а 2.5Г там чего? бинарники и либы? Их то зачем дублировать?

Просто так хардлинками не сделать т.к. в процессе работы данные будут меняться (там mysql и postgres крутятся).

Данные не сделаешь, так хоть код сделай (ИМХО, делать дедупликацию БД всё равно затея гиблая).

а 2.5Г там чего?

система

Их то зачем дублировать?

Просто влом возиться с разделением. Хотя, возможно, можно тупо /usr расшарить, из 2.5гиг на него 1.5 приходится. Остальное это всякая лабуда, в том числе /var/lib/postgres на 350метров.

Надо было флешку побольше брать, но у них на emmc цены конские, я пожадничал.

У меня дедупликация включена на массиве 4х3Tb RAID-Z, падений не видел. Ядро самопальное с PREEMPT. Ссылку прочитал по диагонали, по моему опыту проблем там нет.

а 2.5Г там чего?

конкретно арчик и всякие бенчмарки итп. Апач, nginx, wordpress, postgres....

Не знаю, как это сделать с lxc. Но если есть аппаратная виртуализация, можно задействовать QEMU/KVM. Там это делается с помощью qcow2 backing file.

Данные не сделаешь, так хоть код сделай

проблема в том что я подготавливаю образ вместе с данными. В процессе работы часто приходится что-то подправить в данных. Если у меня будет 4 контейнера то придётся отдельно править каждый.

В общем, пока ничего умнее чем монтировать какой-нить qcow2 я не придумал. nilfs2 слился с монтированием снапшота в rw: multiple rw-mount is not allowed.

если есть аппаратная виртуализация

Нету, в этом загвоздка :(

Следующая попытка - btrfs. Правда, доверия к нему никакого. Потом можно и zfs попробовать, чего уж там :)

проблема в том что я подготавливаю образ вместе с данными

Образ? Для lxc? Впрочем, всё равно непонятно, что мешает тебе вынести код в отдельный «образ» или ФС.

В процессе работы часто приходится что-то подправить в данных. Если у меня будет 4 контейнера то придётся отдельно править каждый.

*пожимая плечами* Не вижу, как в этом случае поможет дедупликация или writable snapshots.

что мешает тебе вынести код в отдельный «образ» или ФС.

Неблагодарная ручная работа. Но, если btrfs зафейлит то так и сделаю. Возможно, я переоцениваю трудозатраты.

Не вижу, как в этом случае поможет дедупликация или writable snapshots.

подготовил образ, сделал снапшот. потом этот снапшот в четырёх местах подмонтировал и готово.

что мешает тебе вынести код в отдельный «образ» или ФС.

Неблагодарная ручная работа.

Ну, если ты вручную генерируешь «образы», тогда да.

подготовил образ, сделал снапшот. потом этот снапшот в четырёх местах подмонтировал и готово.

Если тебе не нужно откатываться на промежуточные версии, это не лучше, чем «подготовил ФС, поправил ее, примонтировал в 4-х местах».

overlayfs?

подготовил ФС, поправил ее, примонтировал в 4-х местах

так при этом все четыре мускля будут обращаться к одним и тем же файлам, не?

Хотя, возможно, можно тупо /usr расшарить, из 2.5гиг на него 1.5 приходится.

так и делай, 3 виртуалки - 3 гига экономии. у соляры один вариант зон так и работает.

подготовил ФС, поправил ее, примонтировал в 4-х местах

так при этом все четыре мускля будут обращаться к одним и тем же файлам, не?

Ты чего-то не договариваешь - то «поправил во всех 4-х виртуалках», то «четыре мускуля будут обращаться к одним данным». Что тебе мешает снабдить каждый контейнер отдельным /var (или /var/mysql), но общими /etc и /usr?

Что тебе мешает снабдить каждый контейнер отдельным /var (или /var/mysql)

исключительно то что если надо поправить базу то придётся это делать в четырёх местах.

Я рассуждаю так: если задача может быть решена парой комманд в btrfs то лучше так и сделать, а не городить колхоз-скрипты которые ещё отладить нужно. На первый взгляд снапшоты btrfs решают проблему, щас буду тестить....

с максимальной экономией места

Btrfs 83% дискового пространства берёт под «метаданные». Я бы не назвал это экономией места...

Btrfs 83% дискового пространства берёт под «метаданные»

Ты что-то серьёзно путаешь. Я скажу конкретные цифры завтра.

overlayfs?

ммм, пока попробую обойти btrfs :)