> под черепушкой водится. :)

И таки временами нехило тормозит и глючит. Достаточно на опеннет посмотреть! Да и мувики хранит очень своеобразно и с жутким коэффициентом сжатия.

> Да, COW лучше работает со "статичными" даными, по этому у меня /home
> c No_COW с этих же соображений (к стати, блин, нада каталогу steam включить COW).

Если весь home так сделать то и снапшоты на нем не получатся. Насколько это плохо - кому как. Я туда адские терабайты мелкими фрагментами не пишу, поэтому оставил и юзаю там снапшоты. Грубо говоря, есть 2 subvolume - "system" и "userdata". Идея изначально стырена у убунт, вроде логично придумали. И "один уровень вверх" который в нормальной ситуации не видно - начало иерархии btrfs никуда не замонтировано, только пара subvolumes с него как / и /home.

> Поправочка: снапшотить в btrfs можна и с No_COW, так сказать одиночный акт COW.

А вот это кстати интересно. А дальше какая участь постигнет эти экстенты по мере накопления отличий? И будет ли аплаится CoW к кому-то из копий далее? oO Чисто теоретически это как бы 2 как бы nocow файла, которые должны быть независимы. Но я искренне сомневаюсь что в этот момент их полностью разделят в отдельные блоки которые можно патчить in-place.

> Если выборочный No_COW есть то ФС становится универсальой в умелых руках, по
> моему, в сpавнении з "класическим" EXT4.

Собссно systemd например своим бинарным логам пытается +C на диру сделать. Вот как раз чтобы быстрее работало и не фрагментилось. И какой-то пойнт в этом есть. Да и мысль именно снапшотить именно логи 50/50, то что админ хотел при откате и логи профукать - не факт.