> Наихудший режим - это много мелких перезаписей, а не дозаписей.

Для кого? Для CoW? Возможно. Для классики - не факт. Если файл остается contiguous - вполне сносно. Только сравнивать два напрочь разных дизайна в допущении что у них одинаковые свойства - странно.

> Типовой workload базы данных.

Может, именно потому в btrfs и предусмотрели отключку СoW в случае когда это надо. Да, не все ворклоады на CoW хорошо ложатся. Как впрочем и на любой иной дизайн ФС.

> достаточно большой файл уже можно дозаписать только с фрагментацией.

...так поэтому в btrfs и сделали дефрагер. В отличие от саней они предпочитают решать технические проблемы а не затыкать их маркетингом.

> Т.е. у CoW самое плохое - это wearing - по мере эксплуатации (в
> традиционных FS - только по мере заполнения диска)

Уточним: у CoW ФС где почему-то не совместили garbage collection с дефрагингом. В моем понимании в btrfs сделали это казалось бы очевидное улучшение, но до них почему-то никто не допер так делать.

> параметры системы сильно ухудшаются. А по мере заполнения диска на CoW FS
> вообще наступает ступор.

Ну вот у изена он и наступил - 6Мб/сек на блин это круто. Да, хреново когда в CoW файловой системе нет дефрагера.

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

Если уж на то пошло, могу себе представить асинхронный аналог memcpy на основе DMA, который вообще не грузит проц. В ядре наверное даже реально такое сделать.

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

...потому что недожурналирующие и нежурналирующие ФС не могут это обеспечить :)

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

Я согласен что у любого дизайна есть сильные и слабые стороны. Несомненно, можно найти ворклоад и требования неудобные для CoW. Как впрочем и для классики всех сортов.

> Не совсем. Журналы БД нyжны еще для поддержания транзакционности.

Так вообще-то по задумке, журнал файловой системе тоже нужен для транзакционности. А то что это в классике адски тормозит и начали лепить всякую читерскую упрощенку - так не от хорошей жизни.

> Как бы там FS не журналила, транзакция в БД != транзакция на FS.

Мотивацией к появлению журналирующих ФС было именно желание иметь семантику в духе транзакций. И сисколы типа (f)sync из той же области. Поскольку не все ФС умеют честно делать транзакции - да, всем приходится по 100500 раз перереализовывать ту же самую логику на уровне апликух. Иногда это оправдано, а иногда - нет. В целом программам и пользователям было бы удобнее если бы ФС сама реализовывала принцип "все или ничего". На данный момент в программах приходится дико костылировать там где нyжна надежная запись. Я считаю что реализация такой логики ближе к системной епархии чем к апликушной кроме ряда спецслучаев (типа БД где это может дать какие-то плюшки типа более хорошей оптимизации).

> Статические данные на CoW, БД без CoW.

Ну да, хорошо же когда можно подогнать по условиям.

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

Это при SELECT * и прочих которые всю базу по чем зря лопатят? Так это вопрос к тем кто такой код пишет :P.

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

Да, по сути БД реализует бОльшую часть логики ФС еще раз. В принципе можно считать ФС частным случаем БД вообще - больно много похожих кусков логики.

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

Так в сабже его вроде нет? :)

> Лучше традиционок не будет в любом случае

Будет. Как минимум при интенсивной записи с требованием полного журналирования. Читерство где только метаданные журналятся а что будет с данными всем наплевать вообще рассматривать малоинтенресно. Ну разве что для совсем уж не ценных данных. Собственно такой сценарий и является EPIC WIN-ом файловых систем на основе CoW. И это вполне себе один из типовых сценариев.

> - даже тех же самых метаданных больше участвует в процессе.

А при честном журналировании в классике данные вообще пишутся на диск дважды. И в общем случае данных больше чем метаданных. По поводу чего классика настолько тупит в режиме полного журналинга что этот режим вообще не реализуют в части таких ФС. В ext4 его реализовали, но вот скоростью работы он не блещет.

> Т.е. с традиционками - правда ваша, сравнивать бессмысленно.

У них просто разные сильные и слабые стороны. CoW - это улучшение полной журнальной логики на другой манер, с избавлением от многих недостатков оригинала. Но чудес не бывает и поэтому появляется и ряд специфичных для нового дизайна проблем. Совсем иных. Другому дизайну - другие свойства.