> Ничего что запись файлов графита - этот тот самый случай, где cow
> мог бы проявить себя с лучшей стороны?

CoW склонен к фрагментации, если ворклоад выглядит как множество частых мелких записей в файлы, особенно если файл патчится in place и/или часто дописывается. Работает CoW так. Любое изменение = выносок в сторону, старые данные не разрушаются и по прежнему доступны, что и позволяет просто и естественно ворочать множественными состояниями. Если выносков много, последовательное чтение будет тормозить. Куча выносков размазанных по всему диску -  не айс, особенно на механике. Фрагментация подскочит до небес, а GC будет весьма неспешно работать.

Наверное в клиническом случае может так выйти что GC вообще не будет успевать вытирать устаревший крап и место закончится. Но в этом случае проще CoW для проблемного файла или диры отключить, раз ворклоад настолько недружественный и интенсивный. Или вы просто положили btrfs на диск мизерного размера, на что он не оптимизирован по дефолту. Я не в курсе что за графит такой, но у вас скорее всего что-то из того что в https://btrfs.wiki.kernel.org/index.php/FAQ#Help.21_Btrfs_cl...

> Не говоря уже о том, что без Cow - BTRFS вообще все свои навороты теряет
> (контрольные суммы, компрессия...).

Базы данных и диски VM обычно сами реализуют некислые схемы журналирования и т.п.. Относится ли это к этому вашему графиту - я честно говоря не знаю.

> Кстати, мне удалось добиться от BTRFS работы с графитом, отформатировал в mixed mode.

А у вас что, совсем мелкий стораж? (я спрашивал про размер, но ответа не увидел). Это ж обычно актуально для сторажей в считанные гигабайты, IIRC.

> Но там другие засады.

Например какие? Я так сходу знаю 1: любители btrfs должны любить свежие ядра. Свежие - это последняя версия (по мнению kernel.org). Даже в 3.17 например будет починен 1 редкий но меткий баг - зависон при активной работе с компрессоваными данными, посажен в районе 3.14, при переводе фоновых работ на ядерные очереди с местечкового велосипеда.