LINUX.ORG.RU
Форум — Admin  

TTL для временных файлов. Автоудаление файлов после некоторого времени.

 , ,


1

1

Это как продолжение темы: Распределенная файловая система для картинок. Желательно что бы в системе монтировалась как обычная. (комментарий)

Идея в том что в очередь на обработку будут загружаться файлы в некоторое временное хранилище - скажем NFS или возможно glusterFS или что то в этом роде.

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

Какой есть самый разумный способ поставить TTL на файлы средствами Linux/NFS скажем в несоколько часов. Если файлы старше то он удаляется.

И какие в этом плане представлют возможности MinIO, glusterFS, Ceph?

Ответ на: комментарий от glorsh66

ну ты блин даешь, с чего бы финду подвисать ??
этож не граф.интерфейс с дизигн-красотами :)
чистил финдом архив тмс-тайликов: сотня, мож две, тысяч мелких файликов - норм. только жевал много времени.

pfg ★★★★★
()
Ответ на: комментарий от glorsh66

А если там тысячи файлов оно не подвиснет?

А почему ты думаешь, что если фича будет в файловой системе, то оно будет как-то быстрее и защищено от «подвиснет»? Никакой магии нет. Подвиснет, или нет это другой вопрос.

no-such-file ★★★★★
()
Последнее исправление: no-such-file (всего исправлений: 1)
Ответ на: комментарий от no-such-file

если фича будет в файловой системе, то оно будет как-то быстрее

Конечно же будет быстрее. Для ФС с N файлов у find минимальная сложность O(N), ему нужно перебрать все файлы из ФС. Наивная реализация удаления одного файла по таймеру через структуру данных типа priority_queue или даже простого упорядоченного вектора - O(log(N)).

annulen ★★★★★
()
Ответ на: комментарий от pfg

Присоединяюсь и чуть дополню. 2ТС find работает по принципу: нашли файлик - удалили, нашли файлик - удалили, никакой магии, ему побарабану где эти тысячи у вас расположены, в одной директории или в тысяче директорий.

этож не граф.интерфейс с дизигн-красотами

find не только у «дизигн-красотами» выигрывает, у rf * тоже (собстно у чего угодно использующего *), ибо звездочка разворачивается в список файликов и если их много-много, то оно не очень-то и сработает уткнувшись в ограничение длинны самой строки команды :)

anc ★★★★★
()
Последнее исправление: anc (всего исправлений: 1)
Ответ на: комментарий от no-such-file

На поддержку очереди и идет логарифм, само удаление за О(1).

И это, повторяю, наивная реализация. Реальная ФС или object storage может и не содержать никаких очередей и таймеров, а просто после истечения TTL считать блоки, соответствующие файлу, свободными (в момент записи другого файла), или делать еще какие-то хитрости.

annulen ★★★★★
()
Последнее исправление: annulen (всего исправлений: 1)
Ответ на: комментарий от annulen

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

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

pfg ★★★★★
()
Последнее исправление: pfg (всего исправлений: 1)
Ответ на: комментарий от annulen

после истечения TTL считать блоки, соответствующие файлу, свободными

Ну ладно, я готов согласится, что такая реализация будет заметно эффективнее чем просто find.

no-such-file ★★★★★
()
Ответ на: комментарий от no-such-file

Да любая реализация, не делающая полный перебор файлов, будет эффективнее find. «Заметность» зависит только от количества файлов. Вариант с find проще всего в реализации, и этого его единственное достоинство.

annulen ★★★★★
()
Ответ на: комментарий от annulen

для это «любой реализации» нужен индекс по дате файла в данном случае :)
в обычной фс это никому нахрен не нужно, потому и нет.
тогда скорость поиска необходимых файлов будет агроменна (пардон в O(n) не смыслю) :)
минус: индекс надо собирать и специально держать. и как следствие под него писать код и отлаживать работу.

pfg ★★★★★
()
Ответ на: комментарий от pfg

для это «любой реализации» нужен индекс по дате файла в данном случае

Да, без индекса возможен только полный перебор файлов - readdir() и поехали. Вышеупомянутый tmpwatch так и делает, по сути тот же самый find

в обычной фс это никому нахрен не нужно, потому и нет.

Конечно, индекс - это оверхед при записи и/или модификации, и у всех вкусы разные, кому-то по ctime надо сортировать, кому-то по mtime, а кому-то вообще по atime.

тогда скорость поиска необходимых файлов будет агроменна (пардон в O(n) не смыслю) :)

скорость поиска в отсортированном массиве чисел (timestamp’ов в данном случае) - O(log(N)). Что при больших N намного быстрее, чем O(N) от readdir(). Ну и обращений к диску может быть больше: индекс можно хранить в одном файле, а при переборе нужно для каждого файла отдельно stat() дергать.

минус: индекс надо собирать и специально держать. и как следствие под него писать код и отлаживать работу.

Или использовать готовое решение: какой-то индексатор, или заменить фс на object storage вроде minio.

annulen ★★★★★
()
9 марта 2023 г.
Admin