Нужно хранить данные, постоянно перезаписывая. Размер варьируется в неизвестных пределах. Как
А) хранить информацию о доступных кусках(как выделять для нового объекта)?
Б) наименее болезненно дефрагментировать чуть?

Много записей разного размера в одном файле

т.е. кусок в середине может быть перезаписан с другим размером?

Сделай как я предложил: цепочками равных буфферов. И предложи использовать ssd, тогда дефрагментировать не нужно будет.

Буду не оригинален :)
Делай не один файл, а много. Пусть об их хранении думает файловая система. Если один файл - это критичное требование, то зипуй.

У Rouse была статья
https://habrahabr.ru/post/254541/

Если изобретать свой велосипед. то вам нужно воспроизвести FAT или ext2.
Второй лучше так как основан на B+ деревьях.
Она экономично по памяти, работает быстрее, оптимизирована для работы с HDD. Рассчитан на произвольный размер так как набирается из нодев  нужного размера. Дефрагментацию на первых парах можно упростить до супернодов. Практически безболезненно расширяется прибавлением нового пространства.

> stas ©   (08.02.17 07:48) [2]
> т.е. кусок в середине может быть перезаписан с другим размером?

Да.

Спасибо, но нет, не подходит.
Нужны менеджер памяти и дефрагментатор.

> DayGaykin ©   (08.02.17 09:51) [3]
>  И предложи использовать ssd

Если файл фрагментирован, то без разницы ssd или нет.


> картман ©   (08.02.17 11:31) [6]


Использовать маркеры начала части,конца части и удаленной части, если перезаписывается часть, то записываем ее в конец файла, а старую помечаем как удаленную. Потом дефрагментатор убирает удаленные части и все смещает.

> stas ©   (08.02.17 11:53) [7]

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

картман ©   (08.02.17 12:10) [8]
Дефрагментация потом. т.е. файл будет расти до какого-то придела потом дефрагментация.

> stas ©   (08.02.17 11:53) [7]


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

СУБД.
кстати, возможно, использование готовой СУБД лучший вариант.

> stas ©   (08.02.17 11:53) [7]
> > DayGaykin ©   (08.02.17 09:51) [3]
> >  И предложи использовать ssd
> Если файл фрагментирован, то без разницы ssd или нет.

Почему? Очевидно, что SSD не нужно тратить время на перемещение головок и ожидание позиции диска.

Определится с минимальным размером блока и (A) битмап на блоки для контроля их занятости.

> вопрос в том, как это делать максимально быстро:
ну, не быстрее железа, да?

> сотня читающих потоков,
у тебя Intel Phi?  ))

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

> задержки должны быть минимальны.
отдельный поток по поиску/учету/составлению списка свободных участков
( алгоритмы можно поискать )

> Б) наименее болезненно дефрагментировать чуть?
не нужно, или offline
( или начинать писать все записи в новый файл/носитель до утраты актуальности старого )

Вопрос хранения позиции/индекса записи не озвучен - думаю там всё понятно ))

> DayGaykin ©   (08.02.17 13:04) [11]

Я так понимаю имелась ввиду фрагментация в виде не используемых данных, которые можно удалить и уменьшить размер файла.

> NoUser ©   (08.02.17 15:35) [12]


ну да, спасибо.

Я для клевого авто нужно четыре колеса, мотор и руль; для шикарности можно добавить кондиционер и дверья))

С СУБД хорошая идея.

> картман ©   (08.02.17 16:30) [14]


пожалуйста.

???

Ваша проблема из разряда "вырезать гланды через задний проход"
Если у вас изменяющиеся в размере блоки в файле
1. вынесите их за пределы файла в отдельные файлы
2. если 1 не возможно, то выделяйте под каждый блок максимальный размер буфера что бы все данные наверняка уместились с запасом их изменения
3. если размер записи блока незначителен т.е. не рационален для создания отдельного файла то вариант использовать БД или СУБД