Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Виртуальная файловая система. Прогресс.
GAMEINATOR forums > Общие разделы > Создание и модификация игр. Геймдев.
jamakasi
В общем был у меня один любопытный проект(забесплатно) в котором была необходимость сделать некую систему для доставки контента при этом не имеющая за собой активного бэкенда но имеющая версионность, легкий разворот на nginx, дедубликацию. По ходу дела получилась такая штука. Лично мне она понравилась и появилась пара дополнительных идей.
Итак что хотелось(некое ТЗ):
1) Дедубликация файлов. Идеально подойдет для большого числа мелких файлов. Т.е. вместо двух одинаковых файлов /some_dir/fileA и /some_dir/long_long_path_toFile/fileZ физически храниться будет только 1 экземпляр, причем независимо от названия файла и то где он расположен в разных версиях или пределах одной.
2) Названия файлов для раздачи(т.е. url в будущем) должен быть предельно коротким без спецсимволов.
3) Некоторая примитивная защита некоторых файлов. Т.е. тупо уникальное имя файла при загрузке которое сложно будет подобрать.
4) Некий список файлов по которому их нужно загружать.
5) Какая либо стандартизация служебных файлов.
6) Примитивный контроль целостности файла. Используется как для проверки целостности контента на сервере в ФС, так и у клиента для возможности сравнения его текущего контента с серверным и осуществлять выборочную загрузку только измененных файлов а так же проверки целостности локального контента.
7) Возможность сжатия файлов для еще большей экономии места на сервере и меньшего размера при передачи клиенту.
8) Отсутсвие активных фремворков\демонов\сервисов на сервере, только чистый nginx или cifs для возможности своей обвязки из вне при необходимости.
9) Работа софтинки которая все это проворачивает на linux\win и возможностью переноса данных между ними.

Решение:
1) При заливке файла на хранение считается его sha1 и переименовывается в саму сумму.
2 и 3) Грубо говоря .../storage/первые_2_символа_хэша/хэш. Т.е. для примера /storage/65/65586BD072DD6DEF8DADCDEB66C110390C41B4C7. Прослойка в виде папки с названием первых 2х символов лишь для того чтобы избежать возможных коллизий или багов хостовой ФС(ntfs\fat\extX) т.е. просто перестраховка.
4 и 5) При заливке файла создается json файлик со структурой в которой хранится полное название файла вместе с его путем и его хэш сумма.
6) Алгоритм sha1 которым можно проверить целый ли файл и соответсвует нужной сборке\билду.
7) Тут все просто , любые свободные алгоритмы lzop, gzip, bzip2, xz и т.д. Но об этом позже.
8) Тут вытекающее решение было в п2.
9) Java.

Что есть прям сейчас? п1-2-3-4-5-6-8-9.
п7 пока отложил банально потому что есть идея обернуть все это добро в fuse(виртуальная файловая система в слое пользователя) и для начала надо будет проверить быстродействие таких решений да и вообще надо ли оно кому либо?

Какие варианты применений:
1) С чего все и началось, а именно тупо доставка контента через сеть малыми порциями с контролем целостности и вариантов апгрейда\даунгрейда.
2) Лютая экономия места на винтах при условии что контент от версии к версии меняется и самих файлы небольших размеров.
3) Если прикрутить через FUSE то можно и локально неплохо экономить.

Как живой пример:
Берем кучи билдов сталкера, обязательно распаковываем игровые архивы и все пушим в эту виртуальную ФС, на выходе получаем экономию места равную числу одинаковых файлов.
Другой пример если вы делаете какойто мод, то можно доставлять патчи наживую автоматически всем клиентам.
Если же прикрутить fuse то люто сэкономив место на диске можно запускать любой билд =)

Сейчас есть полностью готовая альфа софтинки которая умеет, разворачивать такой репо, принимать новый контент, удалять(не повреждая другие снимки) другой контент, вытаскивать контент обратно в обычный вид. Пока не готов универсальный лоадер этого добра но это не так сложно.

Утилита консольная со своим cli. Пара скринов с примером работы и небольшим описанием команд.
Скрины

?l вывести все доступные команды.
dir -без аргументов показать путь до рабочего каталога(собственно там где все барахло будет храниться)
dir путь_до_каталога - с аргументом, указать новый рабочий каталог.


make название_снимка путь_до_директории - 2 аргумента, внести новый снимок с заданным именем(имя служит частью уникальности но может повторяться, полная уникальность происходит за счет имени и даты снимка)


list - вывести список всех снимков. (name)название (date)дата и самое важное (fullname)уникальное название под которым софт видит и работает со снимком.


restore название снимка путь_куда_развернуть - 2 аргумента, вытягивание снимка контента в указанный каталог. Название может быть только как имя (secondPush) или даты (20-09--23-01-2018) или полного названия (20-09--23-01-2018-secondPush). В случае если вы укажите только название к примеру (secondPush) но окажется что под таким именем их несколько то она скажет что их несколько и необходимо полное уникальное имя


delete название_снимка - 1 аргумент, безопасно удалить снимок с заданным именем. Название может быть только как имя (secondPush) или даты (20-09--23-01-2018) или полного названия (20-09--23-01-2018-secondPush). В случае если вы укажите только название к примеру (secondPush) но окажется что под таким именем их несколько то она скажет что их несколько и необходимо полное уникальное имя.
*Тут немного мусора в выводе, потом уберу.



Пример файла с описанием снимка.

Т.е. url будет для скачивания будет вида http://example/some/73/737bdc7ac561d642ce3...cf9c668ae1dd001 , хэш для проверки 737bdc7ac561d642ce3a4d715cf9c668ae1dd001 путь куда сохранить после загрузки ...\logs\fml-junk-earlystartup.log . Символ | служит разделителем путей для независимости ОС, ведь как многие знают на вин системах это "\" а в линуксах "/"
CODE
{
"vfs_version": "01",
"name": "secondPush",
"date": "Jan 23, 2018 8:09:08 PM",
"files": [
...
{
"path": "|logs|fml-junk-earlystartup.log",
"hash": "737bdc7ac561d642ce3a4d715cf9c668ae1dd001"
},
{
"path": "|logs|latest.log",
"hash": "c156f981e913bfcec5b00edc4d8ae51eba8898c2"
},
{
"path": "|logs|shadersmod.log",
"hash": "6fb36bd7d14093ac9eb329b31145830182a6f6e8"
},
{
"path": "|test_net.exe",
"hash": "d1a6a930d69cf6ae3c4ad14db40c49a3120bb347"
}
...
}



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

Что хочу узнать:
1) Оно комунибудь нужно еще кроме меня?, т.к. я своей цели достиг для другого проекта.
2) Посоветуйте нормальные названия команд для cli =)
3) Нужен ли gui?
4) Нужен ли командный режим аля софт.exe -команда -команда5 -командаN
5) Нужен ли какой то простой универсальный лоадер\апдейтер клиентский. Что то типа указал json ,указал URL откуда, указал куда качать. Типа для удобства или кому надо проще написать самому т.к. json схватить везде можно и в общемто ничего сложного тянуть по http нет?

Ну и ссылка на софтинку https://drive.google.com/file/d/13F1kLUK8wf...iew?usp=sharing . Для работы нужна ява 8(работает как на OpenJDK так и oracle JRE в т.ч. на виндах и пингвинах). В дальнейшем можно делать сборки сразу в нативку если надо.

PS по идее ничего плохого наломать не сможете, по крайней мере проверял все много раз но на всякий случай я не виноват rolleyes.gif
autistic
Цитата(jamakasi @ 23.01.2018, 21:51) *
Оно комунибудь нужно еще кроме меня?,

Для того чтобы ответить на этот вопрос нужно хорошо понимать какую функциональность предоставляет данный инструмент и существуют ли реальные кейсы в которых она могла бы быть полезна, из описания выше не очевидно, что это за инструмент, для чего и что делает. Я бы на твоем месте начал с подробного описания основного назначения, возможностей и вариантов применения.
Мне вот непонятно, для какой конечной цели эта штука задумывалась? Сама по себе дедупликация файлов может представлять интерес только в контексте чего-либо, например при передаче большого числа файлов по сети.

Молния в вакууме
Цитата(refuse @ 23.01.2018, 22:27) *
Цитата(jamakasi @ 23.01.2018, 21:51) *
Оно комунибудь нужно еще кроме меня?,

Для того чтобы ответить на этот вопрос нужно хорошо понимать какую функциональность предоставляет данный инструмент и существуют ли реальные кейсы в которых она могла бы быть полезна, из описания выше не очевидно, что это за инструмент, для чего и что делает. Я бы на твоем месте начал с подробного описания основного назначения, возможностей и вариантов применения.
Мне вот непонятно, для какой конечной цели эта штука задумывалась? Сама по себе дедупликация файлов может представлять интерес только в контексте чего-либо, например при передаче большого числа файлов по сети.

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

jamakasi, Прогресс - это название проекта?
jamakasi
refuse, постараюсь на днях демку или синтетику было\стало\скорость на примере чего то сделать. Может пару десятков билдов например.
autistic
Цитата(saas @ 24.01.2018, 00:39) *
Ну он же написал, этот инструмент подходит для продвинутого хранения билдов с экономией места на диске.

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

Цитата(jamakasi @ 24.01.2018, 00:39) *
постараюсь на днях демку или синтетику было\стало\скорость на примере чего то сделать.

Было бы неплохо, на результаты тестов любопытно взглянуть.
jamakasi
Фух, собрал минимально базовую реализацию fuse, на лине пашит, на форточке дома проверю. Скорость чтения естественно пока так себе из за кучи костылей и затычек, режим только чтение(запись так и так делать не думаю ибо самой логике фс противоречит, хотя чем черт не шутит мож и сделаю потом). Но по крайней мере реально первый опыт получил при работе с прослойкой "fs хоста <- fuse <- JNR <- java <- fs хоста".
autistic
Цитата(jamakasi @ 24.01.2018, 17:42) *
собрал минимально базовую реализацию fuse, на лине пашит, на форточке дома проверю.

FUSE это некая прослойка между ядром Linux и юзерспейсом. На форточках, само собой, совсем другое ядро.
jamakasi
Цитата(refuse @ 24.01.2018, 21:23) *
FUSE это некая прослойка между ядром Linux и юзерспейсом. На форточках, само собой, совсем другое ядро.

Так порт есть под окна winfsp, вполне сносно работает хоть и не до конца совместим с самим fuse api.
autistic
Цитата(jamakasi @ 24.01.2018, 23:39) *
Так порт есть под окна winfsp

Зачем тогда FUSE? Делай под одну платформу, все сталкеры форточками пользуются smile.gif
jamakasi
Фух, немного тестирования. Были взяты 3 билда сталкера(2215, 2590, 2939). Каждый билд извлечен. Игровые архивы(dbX,xpX) распакованы и удалены. Далее просто скришот на котором слева направо
папка с 3мя билдами \ папка с 3мя билдами в vfs \ папка с 3мя билдами в vfs и сжатием в XZ пофайлово
ниже тупо сжатая с помощью 7z на ультрах.



Выводы:
1) на еще большем числе билдов разница будет увеличиваться в пользу vfs. (дедубликация в действии)
2) однопоточка уже жмет, можно распараллелить но не критично т.к. заворот в vfs идет единожды.
3) лично для меня открытие но xz хорош для пофайловых сжатия, а на другие он собственно и не может =)

Цитата(refuse @ 25.01.2018, 10:16) *
Зачем тогда FUSE? Делай под одну платформу, все сталкеры форточками пользуются smile.gif

Смысл не в сталкере, а в принципах работы концепта фс. Сам fuse скорее эксперемент и проба пера а вот то для чего изначально задумывалось еще предстоит опробовать т.к. всетаки как минимум либу для высасывания всего этого с хостинга напишу а к ней и минимальную софтину через которую, опять же оформив и если найду хостинг размещу для примера билды сталкера. А дальше уже можно будет сравнить скорость скачивания и распаковки классически торрентом или по ссылке архива игры и его распаковки и этакий онлайн инсталлер.
abramcumner
Цитата(jamakasi @ 25.01.2018, 21:25) *
1) на еще большем числе билдов разница будет увеличиваться в пользу vfs. (дедубликация в действии)

С чего бы? Ты же сам показал, что 7z прекрасно находит и сжимает дубликаты: первые две колонки сжаты считай до одного и того же значения. Есть подозрение, что разработчики архиваторов тоже догадались считать хеши для файлов и не хранить дубликаты в архивах.

А что кстати с датами создания/модификации файлов? У тебя они сохраняются? Билдоману это крайне важно.
autistic
jamakasi, Ну ладно, тебе виднее Но если бы я нечто подобное затаскивал, то в первой итерации все бы максимально упростил.

Цитата(jamakasi @ 23.01.2018, 21:51) *
При заливке файла на хранение считается его sha1 и переименовывается в саму сумму.

Вот это еще настораживает, есть по крайней мере несколько неочевидных для меня моментов:
1) Как предполагается обрабатывать коллизии? Для двух (и даже более) неодинаковых файлов вполне может быть получен один и тот же хеш.
2) Как потом накатывать изменения на разные файлы, если они ссылаются на одни и те же данные (если конечно хранилище не предполагается сделать рид онли)?
3) Не проще ли посмотреть в сторону готовых решений для ценрализованного хранения больших объемов информации? PostgreSQL, на мой взгляд, прекрасно подходит для выбранной задачи (если я правильно ее понял). Там тебе и кэширование, и максимально эффективная работа с физическими носителями - все это уже заимплеменчено.
Modera
Цитата(abramcumner @ 25.01.2018, 21:47) *
А что кстати с датами создания/модификации файлов? У тебя они сохраняются? Билдоману это крайне важно.

Кстати да! Люди со stalker-wiki.ru любят в статьях писать что-то вроде "8 сентября 2004 года было изменено то в модели бармена таким-то разработчиком, 9 января было изменено это таким-то разработчиком, и наконец 32 июля 2005 года был измеменем такой-то параметр в модели бармена таким-то разработчиком, модель в таком видео попала в релиз." Всё очень подробно. Жалко ещё точно время изменения не указывают.
jamakasi
Цитата(abramcumner @ 25.01.2018, 21:47) *
С чего бы? Ты же сам показал, что 7z прекрасно находит и сжимает дубликаты: первые две колонки сжаты считай до одного и того же значения. Есть подозрение, что разработчики архиваторов тоже догадались считать хеши для файлов и не хранить дубликаты в архивах.

Сильно вероятно что догадались но есть одно кардинальное различие, у меня все файлы доступны в каждый момент времени и не зависят от целостности всего архива. Т.е. можно моментально получить доступ к файлу из середины, в архиве такое не проканает.
Цитата(abramcumner @ 25.01.2018, 21:47) *
А что кстати с датами создания/модификации файлов? У тебя они сохраняются? Билдоману это крайне важно.

Скажем так, что добавить это всего пара строк кода, причем отлепленно от самой фс.

Цитата(refuse @ 25.01.2018, 22:09) *
Вот это еще настораживает, есть по крайней мере несколько неочевидных для меня моментов:
1) Как предполагается обрабатывать коллизии? Для двух (и даже более) неодинаковых файлов вполне может быть получен один и тот же хеш.
2) Как потом накатывать изменения на разные файлы, если они ссылаются на одни и те же данные (если конечно хранилище не предполагается сделать рид онли)?
3) Не проще ли посмотреть в сторону готовых решений для ценрализованного хранения больших объемов информации? PostgreSQL, на мой взгляд, прекрасно подходит для выбранной задачи (если я правильно ее понял). Там тебе и кэширование, и максимально эффективная работа с физическими носителями - все это уже заимплеменчено.

1)
Удачи =)

https://habrahabr.ru/post/322478/
Затем они использовали инфраструктуру Google, чтобы произвести вычисления и проверить теоретические выкладки. Разработчики говорят, что это было одно из самых крупных вычислений, которые когда-либо проводила компания Google. В общей сложности было произведено девять квинтиллионов вычислений SHA-1 (9 223 372 036 854 775 808), что потребовало 6500 процессорных лет на первой фазе и 110 лет GPU на второй фазе атаки.

На крайний случай, буквально парой строк кода можно хоть sha512 задействовать.
2) Изменения накатываются только новым слоем, при необходимости любой(именно любой!) слой безболезненно удаляется не трогая предыдущие\последующие слои. Т.е. в целом да это рид онли но не совсем.
3) Смысл в том чтобы сэкономить место(естественно вечно зеленые ибо много место стоит много фантиков), сэкономить на бэкинде(никаких монстров типа sql, только чистый веб т.е. только веб сервер без sql\php\node\...еще кучи технологий), смысл в том чтобы ты мог при необходимости тупо взять и стянуть некий файл к примеру модель сидрыч.ogf за любой год с любого билда не качая архив билда и не распаковывая его а затем не распаковывая игровой архив. Другой вариант что ты можешь делать мод и хранить изменения на сервере в таком виде и тогда старые пользователи будут получать только те файлы которые изменились независимо от того сколько патчей они пропустили а новые пользователи будут получать сразу последнюю версию всех файлов. В общем ты сразу экономишь на размерах хостинга , не заморачиваешься вообще никак с патчами т.к. все происходит автоматом, не пересобираешь свежий билд т.к. это происходит само, легко вычищаешь любой старый билд и контент который уже точно ненужен.

Цитата(Modera @ 25.01.2018, 22:10) *
Кстати да! Люди со stalker-wiki.ru любят в статьях писать что-то вроде "8 сентября 2004 года было изменено то в модели бармена таким-то разработчиком, 9 января было изменено это таким-то разработчиком, и наконец 32 июля 2005 года был измеменем такой-то параметр в модели бармена таким-то разработчиком, модель в таком видео попала в релиз." Всё очень подробно. Жалко ещё точно время изменения не указывают.

В мета инфе можно хранить что угодно, хоть целые статьи. Кроме того можно запросто сделать этакий diff файлов с их вытягиванием в отдельную папку между любым слоем .
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Форум IP.Board © 2001-2020 IPS, Inc.