> zfs: snapshot+clone ?
> и будет у вас 10 ВМ, которые будут занимать как один больщой + 10 diff'ов.

Лепить по снапшоту на каждый инстанс виртуалки? А я не устану эту плеяду снапшотов менеджить? Особенно если захочу еще и какие-то состояния VM заснпшотить? Reflinks вообще никакого менеджмента не требует. Это такой убер-дедуп, когда мы явно просим ФС сделать "изначально полностью дедупнутую копию файла". Просится 1 раз за жизнь виртуалки, дальше это обычный файл и никакого внимания не требует. Поработали, когда разнадобился - стерли. Блоки файла которые никто не использует файлуха сама уберет. Знаете, я так то GC называю "неизбежное зло". А чтоб самому в его роли пахать? Хм!

Кстати если мы об этом, в btrfs таки сделали удаление subvolumes как обычных дир. Поскольку снапшоты тоже subvolumes, теперь можно снапшоты выпиливать прямо по F8 в миднайте (или кто там что лю). А в zfs так можно?

В общем если мы об удобном менеджменте - btrfs умеет в это. И довольно хорошо.

> или aufs - тогда вообще без разницы на какой fs находится каталог.

И как в этом случае выглядит эквивалент reflink? Ну и следующий логичный вопрос - а мануально дедупнуть файл X относительно Y на этом можно будет? Ну вон какой-нибудь jdupes в офлайне btrfs'а довольно лихо дедупает. Наверное и xfs'а уже так может. А aufs вывешивает программный интерфейс, понимаемый софтом? Вручную закатывать солнца вместо операционки я не хочу. Нет, так то я могу и хексэдитором байты разложить как надо, но предпочитаю юзать этот скилл редко и по делу.

> и да, фича reflink как таковая есть не у многих, но может
> быть потому что она мало кому нужна?

Тот факт что шапка подорвалась такое кодить аж в xfs и ряд системных тулсов это заимплементили как-то не подтверждает эту идею.

> - при желании можно найти способы как добиться того же иными механизмами (см. выше).

...но это не будет оформлено программным интерфейсом, который понимают например вон те проги дедубликаторов, etc...