>> Не вижу, как это напрямую к sparse файлам и аллокации-деаллокации относится.
> Мы не обсуждаем сферических коней в вакууме - пофиг как оно там внутри работает ...

В данном случае не пофиг, имхо. Одно дело если 100500Мб файл занимает по факту 10Мб потому что в него только 10Мб записали и совсем другая картина если под него честно выкроены 100500Мб. Очень разные ситуации получатся.

>> нагрузка на способности ФС интенсивно работать с метаданными, тогда как аллокатору
>> особо не на чем надрываться.
> Да и интересны оба.

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

> Реальный бенч, реальные файлы ничего в вакууме ...

Реальный бенч пытается быть похожим на какие-то нагрузки встречающиеся в реальном мире. Случай когда скорость ФС упала до минимально возможной мало кого устраивает и в таком виде ФС мало кто эксплуатирует. Ну то-есть я знаю пока целого 1 кадра которого устраивает 6Мб/сек со шпинделя. Это наверное еще не минимум. Но вполне удачная попытка к нему приблизиться :)

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

Просто у разных дизайнов заведомо разные свойства. У самолетов одни проблемы, у автомобилей другие. Недостатком автомобилей и самолетов это не является.

>> ИМХО логичнее скармливать ФС одинаковый набор операций. И посмотреть как ФС с
>> ним справится. А то сравнивать неодинаковый набор операций - это сравнение
>> ежа с ужом. Из такого результата никаких особых выводов сделать не получится.
> Месье не на выборах, подтасовать результаты на этапе поставновки задачи не получится.

Так это не подтасовка. Это попытка имитировать реальную эксплуатацию. Чудаков типа изена в природе немного, остальные предпочитают получать от ФСов более разумные параметры по ходу эксплуатации ;). Краевые ситуации в принципе тоже могут представлять интерес, но как некий отдельный случай. С изучением насколько сложно в него попасть и прочая.

>> а другая за 2 дня издевательств.
> Проблемы индейцев.

Не индейцев а пользователей ФС. Задача бенча - не полить кого-то грязью или выпятить вперед/назад, а смоделировать типовые варианты эксплуатации, чтобы по результатам бенча можно было хотя-бы грубо прикинуть как ФС себя поведет в вот этом вот случае и надо ли ее такую хорошую брать под эту задачу или лучше обойти сторонкой в пользу чего-нибудь еще.

> Ну мы та после изучения форумов знаем что для правильной эксплуотации ZFS
> нужно не первышать 65% заполнения. Имеет ли смысл тестировать вариант безбашенного
> админа ... сомневаюсь.

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

>> дописав в хвост. Просто потому что как обычным файловым системам было
>> бы очень напряжно как-либо оформить "раздвигание" файла.
> Шел 2012 год, большинство фс по прежнему неумело "раздвигание" файла.

Како-то так вышло что почти все легковые автомобили как правило 4-колесные. Хотя могли бы быть и с другим количеством колес. Ну вот такой вот дизайн устоялся. А могли бы и турбореактивный двигатель привинтить. И крылья. Было бы круче. Но видимо столько счастья ALLу не надо было и спрос на фичу не сформировался.

> Из за этого реализовать вариант с фрагментацией одного файла можно только
> следующим путем - забить диск множеством мелких файлов и начать писать большой файл

Мсье как обычно забыл что для CoW и обычных ФС все будет по разному.

Hint1: на очень сильно фрагментированной ФС скорость доступа будет близка к тому что дает "random seeking" с мелкими блоками. Результат будет сильнее всего зависеть от seek time накопителя и размера запрашиваемого блока: чем хуже соотношение чтения блока к перемещению голов, тем хреновее результат. Этот эффект можно понаблюдать вообще без ФС - просто доступ к накопителю как RAW девайсу и чтение секторов там и тут даст то же самое. По поводу чего не очень понятно что даст указанный тест. Он будет не столько параметры ФС тестировать сколько свойства накопителя. Вот у изена с его ноутбучным винчом все особенно плохо: seek time у ноутбучных накопителей паршивый. На десктопном и шустром - было бы порезвее немного.

Хинт2: для "классики" совершенно нормально прилагать максимум усилий для раскладывания файла как можно более линейно (успешность этого начинания зависит от реализации аллокатора). CoW так не может из-за принципа работы. Если запись в середину файла в классике не создаст новый фрагмент и дозапись по возможности будет отращивать хвост дальше без фрагментации (покуда там свободное место есть) то CoW при записи в середину файла неизбежно сделает выносок-фрагмент в сторону.

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

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

>> эпохи когда POSIX только формировался.
> Красота реализации POSIX удручает.

Другие API (например WinAPI) похожи в этом плане. Ну как почти все автомобили с 4 колесами, рулем и так далее, так и эти API все более-менее похожи.

>>> Назовите функции которые позволят это реализовать ?
>> Ой, до мсье кажется начинает доходить что в posix нет таких сисколлов.
> В Linux fallocate() и splice() насчет второго неуверен ... тоже самое насчет
> sendfile() будет время опробую.

Не совсем понял при чем тут splice и sendfile. Они конечно хороши тем что меньше грузят систему т.к. нет копирования памяти между юзермодом и ядром, но принципы работы с файлами они не меняют. А fallocate интересен только тем что там сделали операцию обратную превращению sparse файла в обычный. Хоть это и не входит в posix (который о sparse файлах вообще не в курсе) и довольно нишевая хрень.

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

Я не о том. Чтобы уменьшить размер файла базы мне известна буквально пара вариантов. Первый - это расчистить хвост, затолкав данные оттуда в свободные страницы в начале файла. Т.е. обычная дефрагментация "объединение свободного места в хвост" + стандартное откусывание хвоста. Второй вариант - полная перестройка нового файла на основе старого но без прорех + стирание старого файла с прорехами. По смыслу одно и то же, только по разному. В случае fallocate() с возможностью разреживания - сделали хитрый финт ушами и прикрутили возможность метить регионы файла как "опять пустые".

>> по мере скачки. Для классики так лучше. CoW - скорее даже ухучшит картину.
> В винде торрент так и делает - выделяет место на порлный размер.

Внезапно, торрент-клиенты так делают не только в винде. Например у того же transmission (который сложно отнести к виндовым) есть 2 режима преаллокации файлов, быстрый и полный. Первый лишь декларирует в сторону ФС что у нас дескать есть намерения получить файл такого размера (sparse как раз об этом). Дальше ФС сама по мере возможности пхает скачанные блоки как получится и как позволяет ситуация. В идеальном случае - может разложить хорошо. Но если качается 100500 файлов параллельно и прочая - может выйти и не совсем оптимально. Второй режим реально заполняет файл по всему объему при его создании и потом по мере скачки блоков просто переписывает регионы файла. На классике это приводит к тому что блоки кладутся в заранее подготовленное "русло" и лежат так, по поводу чего оно максимально линейно насколько ФС в принципе могла это сделать в той ситуации. На CoW такое однако имхо ни к чему хорошему не приведет. Это оптимизация которая хороша для классических дизайнов.

> Голь на выдумки хитра.

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