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

Да, я про CoW. Классика - вполне себе отлично справится, не размазав файл по диску :)

>> Типовой workload базы данных.
> Может, именно потому в btrfs и предусмотрели отключку СoW в случае когда
> это надо.

Так оно и есть. Народ понимает, что CoW - не вселенское бобро, и применимо не везде.

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

+1

>> Т.е. у CoW самое плохое - это wearing - по мере эксплуатации (в
>> традиционных FS - только по мере заполнения диска)
> Уточним: у CoW ФС где почему-то не совместили garbage collection с дефрагингом.

Потому что нагрузка в реальном времени при этом убьёт все плюсы полностью. Честно говоря - удобнее всего оффлайн дефрагер. Онлайн - это для десктопов, где полклика мышкой в час, и нет тяжелых фоновых задач.

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

Оно-то так оно и есть. Вот только данные надо и в кеш записать, и пользователю отдать. Два раза гонять DMA - слегка накладно по сравнению с mapping'ом страниц :)

> Мотивацией к появлению журналирующих ФС было именно желание иметь семантику в духе
> транзакций.

Только семантику в духе. В БД есть еще такое понятие, как изоляция транзакций. И никакая логика транзакционности ФС её не повторит без усложнения ФС до уровня БД :) Но нафига оно тогда - проще сразу вкрутить DBE на RAW, и хранить всё в блобах.

>> Статические данные на CoW, БД без CoW.
> Ну да, хорошо же когда можно подогнать по условиям.

Именно.

> Да, по сути БД реализует бОльшую часть логики ФС еще раз.

Нихт. В БД логика совершенно иная. Можно, конечно, БД в виде FS соорудить, но это давно уже пройденный и похеренный этап (dbf+ntx).