> Для быстрого создания условий тестирования быстродейтсвия файловой системы в условиях
> максимальной фрагментации возможны два варианта -

Не вижу, как это напрямую к sparse файлам и аллокации-деаллокации относится.

> с одним файлом большим файлом и множеством мелких.

Это весьма разные варианты. В первом случае основная нагрузка - на поведение аллокатора и его способность выруливать в сложных ситуациях. Во втором - нагрузка на способности ФС интенсивно работать с метаданными, тогда как аллокатору особо не на чем надрываться.

> Итак если с одним большим - осуществляем операции записи и чтения на тестируемый
> диск от 0% заполненности файлами до 100% и вычисляем средние скорости чтения и записи.

В принципе это - вполне валидный бенч. Хоть и сферический в вакууме, но он может показать умения аллокатора ФС работать в сложных условиях. Кроме этого однако есть еще разница какими порциями и как файл дописывался. Влияет на объем метаданных описывающих размещение файла, etc.

И стоит учесть что разные ФС имеют разные свойства и CoW - based будут себя вести

> Как только скорости чтения и записи перестануть падать, считаем фрагментацию
> максимальной а скорости результирующими для данной фс.

ИМХО логичнее скармливать ФС одинаковый набор операций. И посмотреть как ФС с ним справится. А то сравнивать неодинаковый набор операций - это сравнение ежа с ужом. Из такого результата никаких особых выводов сделать не получится. Потому что в этом случае никак не учитывается способность ФС бороться с фрагментацией. Может, одна ФС чертовски фрагментируется за 5 минут, а другая за 2 дня издевательств. В реальном мире фрагментация ФС редко достигает максимума когда "хуже уже не будет", т.к. для этого нужны совсем запредельные условия и безбашенный админ. Бенч все-таки должен иметь какую-то практическую ценность.

> На самом деле сложнее: Если пишем то пишем вставляя в середину файла
> с произвольным смещением от начала и произвольной длины блок.

IIRC, в семантике POSIX )и большинстве иных похожих по смыслу), файлы умеют расти только с хвоста. Запись в середину перезаписывает то что там было, не раздвигая файл а переписывая содержимое. Увеличить размер можно лишь дописав в хвост. Просто потому что как обычным файловым системам было бы очень напряжно как-либо оформить "раздвигание" файла.

Для классики перезапись файла в середине - вообще ни о чем: оно от этого фрашментироваться не станет. Для CoW это может заставить ФС сорить фрагментами-выносками. В том числе и по этой причине CoW в чистом виде не ахти для баз данных. По поводу чего можно предсказать что на подобном тесте классики будут лучше себя ощущать. В этом месте приходит понимание нафига оракловый архитект предусмотрел возможное отключение CoW в btrfs. Оно сможет стать "как бы классикой" если это реально приспичило ;). Да, это лишает плюшек CoW но базам данных эти плюшки скорее вредны чем полезны, т.к. активно клещатся с их журналом и идеей атомарных транзакций.

> Если удаляем блок то не удаляем его совсем а вырезаем из середины с произвольным
> смещением и произвольной длиной и потом добавляем ео в конец.

Мсье, в posix-овской семантике (как и в большинстве иных) такое не предусмотрено. Там урезать размер файла можно только отбрасыванием его хвоста. Потому что операция "сдвигания" файлов не особо проста в реализации. Особенно в ФС эпохи когда POSIX только формировался.

> Назовите функции которые позволят это реализовать ?

Ой, до мсье кажется начинает доходить что в posix нет таких сисколлов.

> Это нужно как минимум в бд и торрентах ...

Там это делается не совсем так как вы описали. И кстати по этому поводу есть ряд ограничений. Например, файл базы данных при активной работе с БД растет со временем (если не преаллоцирован заранее с запасом, конечно). И даже если удалить половину записей в таблице - это еще совсем не означает что файл можно будет взять и уменьшить.

...в этом месте мы до кучи начинаем догадываться нафига в базах данных есть операция дефрагментации/vacuum/кто там как еще это действо у себя обзывает и почему БД уменьшаются только после этой операции как правило :). А торренты - они предмет простой. Получили блок - запись в файл по нужному смещению. А преаллокация - по сути выбор между тем что хвост будет отрастать "как получится" или файл заранее будет заказан на полный размер. при том quick преаллокация - это мягкий хинт для ФС что "а вот мы собираемся сделать файл такого размера", а full - фактическая запись файла и потом перезапись блоков по мере скачки. Для классики так лучше. CoW - скорее даже ухучшит картину.