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

find -mtime +7 -delete уже не модно?

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

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

Тут вместо ФС просится что-то вроде s3

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

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

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

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

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

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

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

Наивная реализация удаления одного файла по таймеру через структуру данных типа priority_queue

А поддержка этой priority_queue бесплатная что ли?

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

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

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

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

Ну да, все зависит от загруженности сервера, количества файлов, частоты их «обращения». Кому-то и крона с find раз в неделю хватит за глаза.

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

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

Старый-добрый tmpwatch или аналоги.

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

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

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

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

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

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

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

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

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

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

А в S3 есть такой функционал?

Ну например https://min.io/docs/minio/linux/administration/object-management/object-lifecycle-management.html#object-expiration

cron + find