> Но если вовсю пользоваться версионированием, то тогда unshare выжрет всё место и
> перед дедупом надо будет удалить снапшоты во избежание.

Ну, у меня для версионирования проектов GIT есть, там еще коменты, мерж, "мультиплеер", и проч. А спамить себя пачками мало изменяющихся снапшотов на уровне глобального менеджмента систем - оно надо?

Но если надо, у btrfs при сильно большом числе снапшотов скорость работы с метаданными IIRC может просесть. Кент же если не ошибаюсь догнался до миллиарда, чтоли, снапшотов. Возможно это самый заснапшоченый капитан звездного крейсера с машиной времени. Не то чтобы мне
это надо, но технически может быть названо преимуществом дизайна сабжа. Лично меня больше интересует заявляемая "компактность метаданных" и "скорость", имхо. А возможно и хитроджепый кеш с учетом избыточности, до кучи несколько продвинутых хранилок забацать - почему бы и нет, раз уж оно так умеет? Не основной сценарий для меня но на правах приятного бонуса - вполне.

>> С другой стороны снапшоты - НЕ бэкапы
> Конечно, достаточно того, с ними меньше проблем с консистентностью бэкапа.

С другой стороны, 1 бэд под shared экстентом может сильно испортить настроение. Ведь не прочтется то вся пачка. Конечно если избыточность была это хорошо, но возможны и иные варианты. Скажем dd в блочные устройства, ошибка менеджмента снапшотов, пых питальника унесший все диски, системный сбой RAM/CPU/... вынесший метаданные ФС, или еще какой грубый факап который снапшотом не откатывается.

> И раз для бэкапа нужен только один временный снапшот, то больших наворотов не
> требуется.

Снапшоты удобны с точки зрения бэкапирования что они не будут меняться под бэкапалкой. Приветы, видимо, VSS, только тот - капец тормоз и ресурсожор. А в этих дизайнах снапшоты по сути халява. Однако понимание консистентности состояния файлов "in flight" это все же весьма отдельный топик.

Кстати в btrfs можно в ряде случаев и рефлинками это обыграть. Да и в сабже, вероятно, тоже. Я так скажем виртуалки зацеплял: делаю рефлинк диска прямо c запущеной VM, и цепляю рефлинка. Внутрях тоже btrfs обычно. Это как бы неправильно ("некорректный шатдаун"), но cow похрен, там лишь чуть более старое состояние будет. И кстати cow-на-cow таки тоже не рекомендуется. Но я c этими гипердвигателями возился столько что мне таки можно, если осторожно. Ибо я очень хорошо понимаю какой у меня размер дельт, что я собираюсь сделать, и вообще.

> Самый большой требуемый наворот - чтобы пользователь мог не думать
> о том, куда будет писаться diff ("the shadow copy storage area
> can be on the same volume" - мелкософт).

Я терпеть не могу их shadow copy, дико тормозное и контринтуитивное нечто. Юзеры не понимают как это работает, технари обычно не оценивают тупняки и жор места в контринтуитивном виде, и кому оно в таком виде надо я ХЗ.

Однако у лично меня - снапшоты в btrfs идут "на 1 уровень выше /" и его при нормальной работе системы таки не видно. Но при желании поменеджить это просто новое измерение, в котором живет некий ансамбль миров. Можно выбрать в который из них хочется попасть. Технически делается монтированием "full view" в любую точку иерархии. Но вот тут я понимаю как это работает. Саму структуру с subvolumes вот так - придумали убунтуи. Нормально придумали как по мне.

>> Ext4 страшно далек от таких проблем
> Да, это всё не имеет отношения к "платности" CoW'а, неудачно сформулировал.

Ext4 вообще нифига не умеет по сути и потомок намного более архаичных дизайнов. Его некорректно сравнивать с cow. Записи деструктивны (in place), полный журнал тормозной как черти что или если на это забить то структуры ФС конечно консистентны будут но вот файл из наполовину новой головы и старого хвоста - сомнительная радость. А без журнала данных это вообще никак не обыгрывается же.

> Платить ведь приходится:
> - большим write amplification (WAF) на SSD

Я помониторил статистику, сделал commit time побольше (200 секунд), врубил SSD + spread, да и пришел к выводу что если системный SSD за 5 лет протерся на аж 3%, не выглядит большой проблемой. Конечно, если бы это была нагруженная БД это другой разговор. Но я не DBA, мне пофиг, а для DB придумали NOCOW.

> - большей фрагментацией

1) SSD пофиг.
2) У btrfs дефрагер есть. Не идеальный но все же. ZFSники... ну, это их проблемы. Сабж - waiting for -rc1, тогда понятнее будет.
3) С другой стороны cow может писать выноски с полной скоростью куда там удобно.

В целом - ну да, чуть медленнее. Но не критично. И в сумме для меня оно того стоило учитывая новые возможности. А на одноплатниках где DUP парирует редкие единичные бэды это вообще EPIC WIN. Один с EXT4 у клиента рассыпался и было совсем не круто: бэд libc6 накрыл, девайс резко и без предупреждения стал тыквой. Возможность такой тыквы - хреновое свойство, DUP улучшает теорвер в другую сторону. Системные образа у меня мелкие - ополовинивание места не парит.

> - производительностью
>> получится вообще кошмар

В моих сценариях - не получается никаких кошмаров. Так на глаз от ext4 вообще малореально отличить в большинстве случаев. Кстати btrfs'ники с своим bg_tree новомодным - сделали ext4 и xfs по скорости монтирования, я получил приятный бонус к скорости загрузки систем в ряде случаев. Кент вообще сразу на перфоманс ориентировался, premature optimizations сыграли с ним дурную шутку, типа FTBFS на ряде архитектур, терок с майнтайнерами, W^X viol и проч.

> У близости к земле бывают свои плюсы (хоть они и касаются не
> снапшпотов, а других фич, имеющихся в btrfs/zfs) - некоторые держат MergerFS
> + SnapRAID - получается недо-RAID5/6, не теряющий данные на живых дисках
> после смерти массива (из-за отсутствия striping'а) и не разваливающийся (из-за объединения
> не на блочном уровне; файлы всегда целиком лежат на одном диске).

Для меня 1 из ключевых плюсов btrfs это простой понятный и логичный менеджмент файлухи, минимум возни с ней, self heal/малообслуживаемость, ненужность fsck и проч. Чего и Кенту желаю. И снапшоты для меня это такой способ сделать менеджмент bare metal удобным, в стиле виртуалок почти.

Заниматься всякой многоэтажной камасутрой с супер-решениями хз зачем, черти-чьими технологиями хз где и трехэтажными наслоениями костылей - не мое, мне удобно когда все-в-одном в майнлайне, я доверяю этим господам, ряду команд из, а не кому попало. Бонусом я так то data recovery немного балуюсь. Btrfs я уже понимаю достаточно для того чтобы в пиковой ситуации иметь шансы, особенно с их офлайн читалкой прямо в штатных тулсах, да и btrfs'ники - полезные и эффективные господа оказались, когда я баги встретил. Интересно этот опыт с Кентом сравнить будет.

... кстати Кент время зря не терял и пока окно приема открыто, он только что забомбил большой "довесок", который догоняет bcachefs в кернеле до master. Как-то так выглядят сверхновые^W переход на интеграцию с майнлайном, видимо, комит c9d01179e185f72b20af7e37aa4308f4c7ca7eeb