> И что вы посоветуете делать, например, PostgreSQL? Закладываться на свойства FS?

Честно говоря я не смотрел как он работает внутри. Не требовался он мне. Но если окажется, что его механика дерется с btrfs'овым CoW, в btrfs есть рукоятка на этот случай. Можно сказать btrfs-у волшебное слово - NODATACOW. Получится нечто похожее на классику, позволяющее in-place перезаписи с пофигизмом на данные (раз БД сама этим занимается) и корректностью только метаданных (чтобы не fsck-ть многотерабайтные тома). Хорошо когда это можно, правда? То что при этом не получится снапшотить БД - так там большой вопрос, а хотелось ли это делать. Если так развлекаться, DBA может очень преждевременно поседеть.

> более) важны не свойства и настроаиваемость именно ФС, а ОС вообще
> - префетчи, advise-ы, и прочая внутренняя семантика.

CoW в каком-то роде все-таки "целиком журналирует данные". Поэтому есть некий потенциал для того чтобы его логика начала клещиться с другой техникой журналирования, завалив все в очень неоптимальные режимы работы. То-есть как-то работать конечно будет, но когда некто хотел пару inplace-перезаписей, сам сделав журналинг, а CoW по этому поводу нагородил кучу выносков и вообще много дергался и все тормознул - это плохо. Не вижу смысла дергать CoW логику на запись выносков "файл журнала поменялся!" и "файл базы поменялся!" при том что у них своя логика журнала была и на услуги ФС они не полагались. Ценность этих дерганий равна нулю (а какая ценность у пачки версий файла журнала и файла бд?) а вот тормозило от лишней работы - очень даже. По каким-то таким соображениям NODATACOW и сделали. Как раз для тех кто хотел просто in-place перезаписи по типу классики, с кастомной логикой журналирования. И да, эта логика никогда не делалась под CoW файловые системы, скорее под классику или вообще безжурнальные. Но софта который так делает - навалом. И совсем не считаться с ним - не получится. Хоть такое поведение и не оптимально для удачной дружбы с логикой CoW.

> Вы всё время какую-то конкретную рукоятку-проблему в ZFS имеете в виду? Если
> да, то назовите её, пожалуйста.

NODATACOW разумеется. Только в ZFS как раз ее нет. А вот в btrfs архитект работавший в оракле видимо был в курсе проблемы (наверное потому что оракл базами данных занимается). И как-то вот сразу на фазе дизайна подстелил соломки. Предусмотрев возможность закосить под нечто типа классики, если лыжи встали на асфальт. А в ZFS это не было предусмотрено. И то что ZFS не лучший выбор для баз - достаточно общеизвестно. Почему - я более-менее объяснил на пальцах вроде.