Программирование игр, создание игрового движка, OpenGL, DirectX, физика, форум
GameDev.ru / Программирование / Форум / Разыскивается либа single file vfs [c/c++]

Разыскивается либа single file vfs [c/c++]

Поделиться
Blew_zcПостоялецwww23 авг. 201720:54#0
Нужна библиотека, реализующая single file virtual file system под C/C++, нацеленная на обновление многих мелких файлов с изменением их размера с минимальной фрагментацией в древовидной структуре.
В принципе, хранить это на диске в сыром виде проблем нет, но копирование в этом случае занимает очень много времени (сейчас файлов порядка 92к, директорий около 3к).
Хотелось бы иметь все хранилище в одном файле наподобие loopback в unix-like, но кроссплатформенное.
Под MIT/Apache/BSD.
Наверняка что-то готовое есть. Лисапед писать нет никакого желания.

Зы. zip не предлагать)

Che@terПостоялецwww23 авг. 201721:19#1
Для подобного использую враппер над LiteSQL. Производительность относительно работы с нативной файловой системой на андроиде стала в разы выше.
Из плюсов - транзакционность(отключаемая), поддержка в рабочем виде при внезапном падении программы.
Из минусов - отстутствие всяких fstream, FILE* и так далее для совместимости с другими либками. Хотя я думаю это не особая проблема накатать и под это врапперы из памяти если файлы мелкие.

Blew_zcПостоялецwww23 авг. 201722:18#2
Che@ter
Почему LiteSQL?
Да, я уже присматриваюсь тупо к SQLite и блобам. Один индекс повесить на группу столбцов для поиска блоба.
Блобы небольшие, порядка 20кб самый большой. В документации говорится, что до 100кб быстрей, чем файлы на диске.
Но вопрос в том, что будет происходить с файлом при частом update с различным размером. Как в сторону уменьшения, так и увеличения размера.

> на андроиде
У меня Win/nix на SSD :)

ADD: а, туплю, это орм под sqlite в том числе %)

Правка: 23 авг. 2017 22:27

Che@terПостоялецwww25 авг. 201716:25#3
Blew_zc
> Почему LiteSQL?
Да, я их путаю. Конкретно на проекте используется sqlite (sqlitecpp).

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

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

Думаю там что-либо в виде кеша есть. Тем более там даже поднастроить можно. А оверхед по итоговому размеру не превышает пары процентов после "массивного" переобновления файлов.

Blew_zcПостоялецwww25 авг. 201717:41#4
Che@ter
Прикрутил. Во времени выполнения не потерял. Размер стал меньше. Пути у меня числовые, поэтому сделал 3 столбца с индексом.
Пришлось поковыряться с многопоточкой.
Единственное что мне не нравится - что пришлось ждать step, пока busy или locked. Не знаю как решить этот момент. Но такой пример даже на самом sqlite.org приведен. Выглядит как костыль.

Еще момент - бывает подтупливает надолго, будто что-то делает, но проц загружен на 0%. Не понятно, с чем это связано. Возможно, ОСь сбрасывает свои кеши на диск.
Соединение у меня открывается с флагами OPEN_SHAREDCACHE и OPEN_NOMUTEX.
Затем устанавливаются такие прагмы:

busy_timeout = 5000
cache_size = -32768
read_uncommitted = true
synchronous = OFF
journal_mode = WAL

Add: Ах, это норма для WAL:

+ journal_mode = WAL

Правка: 25 авг. 2017 18:10

Blew_zcПостоялецwww12 окт. 201720:31#5
Che@ter
Мде. Что-то я разочарован. БД в итоге вышла в 435Гб...
Жутко фрагментирована, посему решил выполнить vacuum & reindex.
Идут третьи сутки, а конца не видать.
Сначала операция завершалась неудачно по причине нехватки места в tmp (починил через sqlite3_temp_directory), установил progress callback. Он уже 2е сутки молчит, время модификации файла журнала периодически обновляется.
Разрабы пишут, что в худшем случае требуется 3х объем на диске для выполнения операции (включая размер самой бд, временной бд и журнала)
Никуда не годится. Нужно что-то придумать. Не пилить же свой лисапед?
AndreyПостоялецwww12 окт. 201722:46#6
У меня в SQL для таких задач сомнения были, может sqlite в качестве удобства полезен.
Che@terПостоялецwww13 окт. 20171:21#7
Blew_zc
> БД в итоге вышла в 435Гб...
Немало... явно не игровой у тебя проект.

> Жутко фрагментирована
В чем это проявляется?

> Он уже 2е сутки молчит
Может все изза

synchronous = OFF
Может база где-то испортилась и либка теперь мучается?

Может быть уменьшить размер страницы? Тогда данные будут лежать более плотно.

Blew_zcПостоялецwww13 окт. 20178:41#8
Che@ter
> В чем это проявляется?
select по индексу жутко медленный.
К тому же, обновления по одному индексу с постоянно возрастающим объемом.

> Может база где-то испортилась и либка теперь мучается?
Может быть. Я теперь боюсь прерывать операцию. Процесс замер в таком состоянии, когда данные уже лежат во временной бд, файл журнала 300+ метров, и что-то периодически пишется .shm. Хотя сам файл бд, вроде, еще ни разу не обновился.

Адд:
> Может быть уменьшить размер страницы?
Уменьшить? Я думал наоборот увеличить, примерно, под худший случай размера записи, чтобы запись не билась на несколько страниц, которые могут быть по файлу разбросаны где угодно.

Правка: 13 окт. 2017 10:10

Blew_zcПостоялецwww13 окт. 201711:39#9
Хе, оно проснулось. Временный файл грохнулся, журнал вырос до объема, немного превышающего объем бд. Походу фаза vacuum закончилась, и сейчас он делает reindex.

3 дня, Карл!

Blew_zcПостоялецwww13 окт. 201717:16#10
Я вот тут посмотрел в сторону lwext4...
Выглядит весьма недурно. Смущает отсутствие изменения размера и доступ из одного процесса...

/ Форум / Программирование игр / Общее

2001—2017 © GameDev.ru — Разработка игр