> Всё дело в фрагментацыи, ведь линейная запись/чтение всегда быстрее (конешно всё
> отностительно).

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

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

> Разве главная цель COW это не борьба з фрагментацыей?

Самым ключевым достоинством CoW я бы назвал все же
1) Некий эквивалент полного журналирования без двойной записи.
2) Неразрушающую запись.
3) "Халявные" снапшоты.

Насколько оно (не) фрагментируется под той или иной нагрузкой, как это соотнесется с классическими ФС и проч - зависит от дохрена факторов. Забитость тома, характер нагрузки и проч. Универсальных серебряных пуль нет.

Под некоторые нагрузки CoW ложится хорошо. Под некоторые - плохо. Скажем БД делает много мелких записей, журналит сама, и делалась под in-place патчинг если не raw разделы (оптимальнее, но неудобно). Если БД и журнал как есть вывалить на cow, модификации будут кучей дозаписей в сторону. Это может и не было бы хуже иных вариантов, но это как минимум создаст множество метаданных для описания "хвостов" и фрагментирует свободное место. По поводу чего в btrfs и оставили на такие случаи возможность CoW отклчить. Если БД хочет вот так - пусть будет так. При этом btrfs не сможет это "журналить", снапшотить и проч - но БД этим сами заведуют, а снапшотирование баз вообще чревато, особенно реплицируемых по сети, потуги так делать требуют отличного знания своей БД, ФС и как оно используется.

На забитом томе опять же будут проблемы с тем что выкроить непрерывный экстент для записи может не выйти. Это проблемя для любой ФС, но для CoW особенно чувствительно из-за того что он in-place ничего не меняет. Если этот процесс долговременно предоставить себе, на сильно забитом томе и то и другое придет к состоянию вермишели, но cow имхо дойдет туда раньше. На такие случаи, если это механические винчи и все совсем плохо стало, сейчас и у btrfs и у ext4 один фиг дефрагеры есть. Реально дефрагер ессно нужен только если совсем уж идиотничать, как iZEN, забивший до отказа торентами свой ZFS, так что тот забился фрагментами как черти что и красавец понтовался аж 18 мегов в секунду. С трех дисков, хоть и ноутбучных (у него, кстати, дефрагера в zfs таки еще и нет, хаха).

В конечном итоге CoW и классические ФС ... довольно разные по свойствам. Из-за довольно разной механики. Впрочем, если не хардкорить, забивая все под завязку или гоняя БД, и не заметить особых отличий. На каком-нить системном ssd в крейсерском режиме btrfs и ext4 по ощущениям будут однохренствены и вообще узнать что там за ФС можно только если специально это позырить.