> Насколько оно (не) фрагментируется под той или иной нагрузкой, как это соотнесется
> с классическими ФС и проч - зависит от дохрена факторов. Забитость
> тома, характер нагрузки и проч. Универсальных серебряных пуль нет.

Есть — 3D структура памяти без ячеистой привязки, правда она пока токо под черепушкой водится. :)

> Под некоторые нагрузки CoW ложится хорошо. Под некоторые - плохо. Скажем БД
> делает много мелких записей, журналит сама, и делалась под in-place патчинг
> если не raw разделы (оптимальнее, но неудобно). Если БД и журнал
> как есть вывалить на cow, модификации будут кучей дозаписей в сторону.

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

> Это может и не было бы хуже иных вариантов, но это
> как минимум создаст множество метаданных для описания "хвостов" и фрагментирует свободное
> место. По поводу чего в btrfs и оставили на такие случаи
> возможность CoW отклчить. Если БД хочет вот так - пусть будет
> так. При этом btrfs не сможет это "журналить", снапшотить и проч
> - но БД этим сами заведуют, а снапшотирование баз вообще чревато,
> особенно реплицируемых по сети, потуги так делать требуют отличного знания своей
> БД, ФС и как оно используется.

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

> Реально дефрагер ессно нужен только если
> совсем уж идиотничать, как iZEN, забивший до отказа торентами свой ZFS,
> так что тот забился фрагментами как черти что и красавец понтовался
> аж 18 мегов в секунду. С трех дисков, хоть и ноутбучных
> (у него, кстати, дефрагера в zfs таки еще и нет, хаха).

:D

> В конечном итоге CoW и классические ФС ... довольно разные по свойствам.

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