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

Мы не обсуждаем сферических коней в вакууме - пофиг как оно там внутри работает ...

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

Да и интересны оба.

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

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

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

Проблемы индейцев нас не волнуют.

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

Месье не на выборах, подтасовать результаты на этапе поставновки задачи не получится.

>Потому что в этом случае никак не учитывается способность ФС
> бороться с фрагментацией. Может, одна ФС чертовски фрагментируется за 5 минут,
> а другая за 2 дня издевательств.

Проблемы индейцев.

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

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

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

Шел 2012 год, большинство фс по прежнему неумело "раздвигание" файла. Из за этого реализовать вариант с фрагментацией одного файла можно только следующим путем - забить диск множеством мелких файлов и начать писать большой файл освобождая место путем стирания произвольного колличества мелких файлов. В результате большой файл будет фрагментирован и на его чтении можно будет хоть что то измерить ...

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

Красота реализации POSIX удручает.

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

В Linux fallocate() и splice() насчет второго неуверен ... тоже самое насчет sendfile() будет время опробую.

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

Оптимизация таблиц блокирует эти самые таблицы ? На плохо предсказуемое время ?

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

В винде торрент так и делает - выделяет место на порлный размер. Голь на выдумки хитра.