оверкилл в данном случае в человекочасах для настройки всего этого вместо примитивной фифо очереди

Тогда уже оверкилл - это пилить файлопомойку самому, когда есть готовые реализации

Тогда уже оверкилл - это пилить файлопомойку самому, когда есть готовые реализации

есть готовые реализации файлопомоек, чистящих всё что старше суток? :)

А с БД у тебя будет возможность гибко настраивать политики и т.д.

id можно хеш от имени

да? странно, я часто использую как раз для этого. ты я думаю не так меня понял. в одном системном, а не логическом потоке

прицепить луа, сделать гуишку....

Можно поднять https://github.com/minio/minio и прицепить к нему какую угодно вебморду

Лучше сразу купить сервис в Амазоне за 100$ в месяц. Ладно чуваки, я отойду в Java чат, там как то разумнее чем здесь сейчас.

А ТЗ и нет, я чисто для себя файлопомойку делаю с расчётом на то, что им также будут пользоваться знакомые и не очень люди. Хрен знает, может внезапно и нагрузка пойти либо засчёт веса файлов, либо засчёт их количества.

А гонору то было.. "надо вот так и всё" Еще раз. При попытке чтения файла или папки проверяешь что из этого устарело и ставишь в очередь на удаление или удаляешь сразу. Показываешь только не устаревшее. Так инвалидируют в этом мире подобные вещи все вменяемые люди.

find /opt/files/ -mtime +1|xargs rm -f - не благодари!

А гонору то было.. "надо вот так и всё" Еще раз. При попытке чтения файла или папки проверяешь что из этого устарело и ставишь в очередь на удаление или удаляешь сразу. Показываешь только не устаревшее. Так инвалидируют в этом мире подобные вещи все вменяемые люди.

Я так и планировал. Вопрос только в том - через БД это всё, вручную или как-то иначе. БД не сработал, вручную не уверен, по другому - хер знает.

При чем тут бд? У файла есть время создания же

И добавляем раз в сутки/час принудительное удаление старого говна, к которому не обращались.

чтобы можно было без лишнего геморроя сделать разное время жизни файлов

чтобы можно было без лишнего геморроя сделать разное время жизни файлов

Это лишнее

тогда да, вариант без бд тоже ничего.

Я ж примерно то же самое предлагал

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

Надо где то хранить связку id - имя файла. Или id должен быть именем файла.

Размеры этого fifo могут быть ужасающими. И что делать при краше процесса?

Размеры этого fifo могут быть ужасающими. И что делать при краше процесса?

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

Чистить только on demand - плохая идея. Я тебе насыплю десяток миллионов файлов и никогда не буду обращаться к ним.

Чистить только on demand - плохая идея. Я тебе насыплю десяток миллионов файлов и никогда не буду обращаться к ним.

Я вот пока не вижу почему бы не рассчитывать на свойства файла

Совместо с find по крону

Совместо с find по крону

А нахрена тогда on demand?

А нахрена тогда on demand?

find /opt/files/ -mtime +1|xargs rm -f - не благодари!

Рома, нам пора с тобой что-то вместе уже сделать:)

А дальше два врианта - либо удаляем сразу ненужное, либо по крону чистим. Но по крону чистить нужно всегда, потому что будут файлы к которым никто не обращается. Значит удалять по запросу - не нужно.

А что будет, если крон захочет удалить файл, который начали скачивать?

id можно хеш от имени

А что будет, если крон захочет удалить файл, который начали скачивать?

Ничего

Так нельзя делать.

От балды вбил golang nosql и вот что нашёл. Ваши оценки, господа? https://github.com/HouzuoGuo/tiedot

От балды вбил golang nosql и вот что нашёл. Ваши оценки, господа? https://github.com/HouzuoGuo/tiedot

Ну есть же продакшн реди! https://github.com/boltdb/bolt

Файл скачают и занимаемые им блоки будут помечены как свободные

Ну есть же продакшн реди! https://github.com/boltdb/bolt

Ну есть же продакшн реди! https://github.com/boltdb/bolt

не так но суть верная, ничего страшного не будет

А как?

файл удаляется файловой системой если на него нет хард линков и нет открытых дескрипторов если удалить файл это убьёт линк, но пока дескриптор открыт все ок

Стоит брать для своих нынешних нужд сейчас?

Он помечается удаленным. Дальше помечаются его блоки данных

Если у тебя появлялась необходимость Memcache, Redis, Tarantool то лучше LevelDB/BoltDB. Потому что у тебя будет законченый код встроенный в приложение, который работает напрямую с памятью без оверхеда на протокол взаимодействия.

Если у тебя появлялась необходимость Memcache, Redis, Tarantool то лучше LevelDB/BoltDB. Потому что у тебя будет законченый код встроенный в приложение, который работает напрямую с памятью без оверхеда на протокол взаимодействия.

Тарантул не прижился, потому что он был баганутый и тяжёлый в понимании. RethinkDB уже покруче и он мне очень нравится.

опять же нет удивляется inode, а блоки лежат как лежали но на них больше нет ссылок

читай выше, пока есть открытые fd все живет

Ну так что происходит при удалении и наличии открытого fd?

удаляется хард линк

Он с каким объектом в vfs ассоциирован?

Размеры этого fifo могут быть ужасающими. И что делать при краше процесса?