@julyclyde 有道理，我 test 下

@chroming 有可能是这个逻辑导致的，之前其他的 python 程序并没有发生这种情况，这样说 docker 的 volume 是要绑定 inode 的？

@Puteulanus 这个算解压吧

@SkywalkerJi 感谢。 有几个 NAS 的评测，如钱韦德，司波图之类的，还有硬件类的 AK ，这几个咋样？

@EricFuture 谢谢，我喜欢油管

@villivateur 展开讲讲？

@chroming 有文件的拆分动作，比如一个大文件拆成 10 个小文件，但是大文件一直有新增，这个也会导致 inode 变化？

@julyclyde 对的

@chroming 这个应该没有，就是新增文件

@Honkaiteio 里面就是个 while True 循环，然后每次循环都会重新去 list mount point 里的文件，按理说没啥问题啊

@julyclyde 容器部署维护简单。最终通过多线程+多路代理搞定了并发处理的需求。

@julyclyde docker-compose.yaml 文件

version: "3"
services:
pro:
build: .
container_name: subtitles_translator
restart: always
volumes:
- /usr/share/zoneinfo/Asia/Shanghai:/etc/localtime
- ./translator.py:/app/translator.py
- ./logs:/app/logs
- "/truenas_pool/video:/video"

备份用 unraid 默认的 VM backup ，还可以

谢谢各位，我用单线程和多线程来试试。

@lianyue 1 每个文件处理时间大概 10 都 60 分钟不等，看文件大小
2 ，对 cpu 占用有一定的开销，是 cpu 计算型应用
3 ，每天新增 10-50 个文件
4 ，是本地文件，在一个目录下

@shendaowu 反复确认的肯定能记住，就怕灵感稍纵即逝想不起来了，总会有 xx%的遗忘，这部分也许是最宝贵的

@libook 我的 cache 已经被两块 nvme 组的硬 raid 占用了，zfs 是 unraid 上的硬盘（没有组 array ，性能太拉，且容灾不行）组的 raidz2

@libook 我看看，个人觉得 unraid 还是作为基础系统吧，其他的都通过 VM 直通来解决，我目前有点混用。unraid 上有 zfs ，VM 里建 truenas 也有 zfs ，然后 unraid 上有跑容器，VM 里也有跑容器。

@Licsber 我有一些脚本在 unraid start 的时候自动执行，特别是 zfs 的 mounti point 自动设置