скользящее окно JPG из тысяч файлов

У моей машины есть камера, которая может принимать тысячи jpg в день. Я ищу способ отдаленно посмотреть последние 30-60 минут видеоматериалов через облачный центр хранения, такой как box.com .

Я думал, что копирование последних 5 минут файлов на подключенный удаленный диск (davfs2) каждый мин, а затем удаление файлов каждые 10 минут, которые были старше часа, было бы хорошим решением; но это вызвало большие проблемы! Это привело к тому, что моя машина не могла подключаться через SSH; требуя от меня отключить его.

Теперь, даже если я пытаюсь удалить файлы, он по-прежнему повторно копирует их на смонтированный диск. Мне пришлось отключить накопитель, но, похоже, не удалось очистить кеш davfs2.

Есть ли принципиальная проблема с моим подходом?

Я положил это в свой кронтаб:

 */1 * * * * sudo find /mnt/ -type f -cmin -5 -exec cp -pn '{}' /home/pi/box/street_pictures/ \; */10 * * * * sudo find /home/pi/box/street_pictures -cmin +60 -type f -exec rm '{}' \; 

/nmt – это папка с тысячами изображений. /home/pi/box/street_pictures – мой подключенный диск.

Почему sudo ? Если он все равно работает как root, поместите его в корневой каталог crontab?

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

Чтобы избежать одновременных заданий cron, вы можете использовать какой-то механизм блокировки, или, поскольку он будет работать без остановок, вы могли бы поместить его в скрипт службы:

 while [ 1 ] do sleep 60 & cp jpg stuff wait # for sleep in case 60 seconds have not yet passed done 

Возможно, вы могли бы переименовать уже скопированные файлы в игнорируемый subdir?

-exec {} \; также не очень эффективен (запускает новый процесс cp для каждого файла). Попробуйте -exec cp --target-directory=/home/pi/... {} + вместо этого, если ваши программы поддерживают такую ​​опцию.

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