> даже XFS, который на более простые методы фрагментации не особо то
> и покупается.

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

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

Вам же сказали "Реальный бенч, реальные файлы" а вы опять со своимы конями в вакуме.

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

Тесты покажут у кого какие проблемы.

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

Друг мой вы случайно не из партіi ВО "Батьківщина" ? Еще раз - вы не на выборах подтасовать условия тестирования не получится.

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

В двух словах индейцы в панике.

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

Наш большой файл в сумме с мелкими не будет занимать более 65% фс.

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

Вы явно не в теме, если бы не сомнительные личности из нефтегазового сектора мы бы на стат поясах летали бы ...

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

Вот имеено этот тест хочется проделать на диске в памяти :))

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

Я вижу вы неравнодушны к Изену :))

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

Прежде всего я ожидаю увидеть как не все участники тестирования придут к финишу :)) вероятно завалит тест btrfs :))

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

Копипаст во всей красе :)) Последствия bsd лицензии :)))

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

Так есть возможность реализовать или таки нет :))) Напоминаю шел 2012 год ...

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

И какой из этих вариантов рабочий при условии что начальный и конечный файлы занимают больше чем 50% диска ? :)))