Какой есть оптимальный алгоритм загрузки ассоциированного файла?

Question

[makaleks]

Пишется домашний проект, в котором есть веб-редактор текста (plaintext) с желаемой возможностью прикреплять по id-ссылке ресурсы (картинки, документы и тому подобное). Выход проекта, во избежание зоопарка - единый бинарник (rust, его стэком и ограничен).

Не выходит нагуглить алгоритм согласованного сохранения текста и ресурсов, чтобы by-design было, по приоритетам, следующее:
1. никаких битых ссылок на ресурс
2. диск не засоряется при удалении ссылки на ресурс или прерывании процесса обновления текста, содержащего ссылку
3. минимальное число записей, а лучше и чтений диска
4. текстов и ресурсов может быть много

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

картинка

Выглядит нагружено, много обращений к диску, наверняка какие-то шаги имеют подводные камни, да и подход в алгоритме может быть просто неверен

Так что нужна помощь

Спасибо

Answer 1

[Антон Шаманов]

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

Comments

[makaleks]

Ресурс, как я понимаю, грузится долго, текст быстро. Если прервать работу сервера (это далеко не 24x7 история), останутся мусорные ресурсы. А открывать и парсить каждый файл текста (или каждый список, а ведь согласованность этого списка тоже могла поломаться) плюс проверять каждый ресурс я очень не хочу

[Антон Шаманов]

Makaleks, мусор можно удалять по крону раз в пол часа - всё что не в списках можно удалять. я предполагал хранение в БД, если все на файлах, то просто сохраняй состояние страниц в js файлах, что-то вроде :

callback({
    id: "номер страницы",
    files: [{id: "хэш пути 1", path: "путь 1"}, {id: "хэш пути 2", path: "путь 2"}]
});

[makaleks]

Спасибо за вариант. Я пока надеюсь устроить транзакционность на месте, без нагрузки "потом", без других агентов

[Антон Шаманов]

Makaleks, хозяин-барин, просто ты сначала говоришь о домашнем проекте, а потом всплывает

Если прервать работу сервера

[makaleks]

Антон Шаманов, на то он и домашний, что прорабатывается, а не

просто-сделай-в-срок-что-хочет-пм

[makaleks]

Антон Шаманов, а ещё прерывание сервера входит в хотелку №2 оригинальной постановки

[Антон Шаманов]

Makaleks, сервер временами не доступен это не тоже самое что и прерывание выполнения работы скрипта, последнее обычно либо user_abort, либо срабатывание max_execution_time

Answer 2

[makaleks]

Узнал о существовании такого понятия, как журнал упреждающей записи (WAL). В результате веду файл журнала с блоками аннотацией {флаги вроде готов к удалению/готов к дампу, неубывающий идентификатор, зависимости, зависимый, ожидаемый размер и ещё что-то} и срезов данных {тот же идентификатор, N байт кусочка файла}. По ходу выгрузки строится дерево зависимостей, и как только все ноды оказались в WAL, ставлю флаги готов к дампу и начинаю запись. Случится нарушение - восстановлю недозаписанную транзакцию по WAL, истечёт актуальность - помечу блоки как готов к удалению.

Можно, конечно, вместо срезов полученных данных писать во временные файлы - тогда запись дампа будет выглядеть как просто перемещение файла, что дешевле и быстрее освобождает место - но это больше сущностей в и так непростом велосипеде (пока актуальнее добиться аккуратной обработки дерева зависимостей, с тестами). Плюс понадобится проверять актуальность на файловой системе на случай, если [все блоки получены]=>[оригинал перезаписан]=>[транзакция прервалась, а некоторых временных файлов не осталось]. В таком случае можно предложить перебраться на sqlite, но выигрыша по сравнению с уже написанным простым wal не вижу.