>> Любой CoW при 50/50 r/w без немеряного кеша - слоупок, за счёт гиперфрагментации.
> Хочу послушать научное обоснование столь громкого заявления. Ну насчет слоупока для любого дизайна CoW. Вообще, имхо наихучший режим будет если много мелких дозаписей.

Наихудший режим - это много мелких перезаписей, а не дозаписей. Типовой workload базы данных. Ну и CoW всё-таки гораздо более интенсивно расходует дисковое пространство, так, что в итоге диск превращается в "решето", куда новый достаточно большой файл уже можно дозаписать только с фрагментацией. Т.е. у CoW самое плохое - это wearing - по мере эксплуатации (в традиционных FS - только по мере заполнения диска) параметры системы сильно ухудшаются. А по мере заполнения диска на CoW FS вообще наступает ступор.

> Некоторые моменты дизайна этого пепелаца от саней - за гранью моего понимания.

+1

> Справедливости ради, обычно файловая система в диск упирается все-таки. Копирование страниц

Во что бы она не упиралась, отсутствие zero copy - лишняя бесполезная нагрузка на проц.

> Вот только:
> 1) Старое состояние - угробится. Совсем. Вернуть будет нельзя. Как раз именно

В случае БД не актуально - она сама ведет журналы.

> 2) Все это подразумевает что файл не растет, что как-то неверно.

Файлы БД на самом деле обычно преаллоцируются, и растут, ну, достаточно редко, по сравнению с перезаписью.

> БД куда-то журнальную логику должна реализовать.
> Как раз потому что не может надеяться на то что произвольная ФС честно отжурналит.

Не совсем. Журналы БД нужны еще для поддержания транзакционности. Как бы там FS не журналила, транзакция в БД != транзакция на FS.

> 3) Вообще, для вот такого вот файла в btrfs cow можно взять
> и ... отключить. При том можно выборочно разуть на это только

А вот это очень здорово, в этом плане BTRFS будет очень удобной FS. Статические данные на CoW, БД без CoW.

> Вот только странный какой-то ворклоад получается, когда запись мелкими кусочками а чтение огромным блоком.

Типовой ворклоад БД. Пишется как попало, а при поисках читается сравнительно большими блоками.

> Ага, а если на середине записи вдруг случится факап, у нас получится
> наполовину старый и наполовину новый файл.

БД пишут данные страницами, и имеют собственную структуру. Наполовину старый-новый файл нормально разгребается при recovery благодаря меткам.

> Особенно если TRIM нет

Ну это уже прошлый век.

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

Лучше традиционок не будет в любом случае - даже тех же самых метаданных больше участвует в процессе. Т.е. с традиционками - правда ваша, сравнивать бессмысленно.

В остальном согласен.