删除文件时的问题
我目前运行的Nextcloud版本是22.1.0,External Storage总共设置了三个,第一个是自建的MinIo存储,第二个是通过rclone将Google Drive映射到本地之后通过Local选项配置成External Storage,最后是通过SFTP连接的一个大硬盘服务器。
从很久之前我就发现删除容量大的文件夹时非常慢而且经常失败,但以前都是以Google Drive作为存储,我一直以为是连接速度不够或者是API request太多的缘故,本身Google Drive提供的性能也比较一般,尤其是文件数量比较多的情况下。这次我在SFTP连接的External Storage上也遇到了同样的问题,因为两台机器都是自己手里的,传输速度我也很确定也不会有问题,实在是想不通删除文件失败的原因。论坛上大多数删除失败的情况都是filelock导致的,但我因为主力存储是S3,直接在配置里就禁用了filelock,这个原因也可以排除了。Logs里面也没有什么有用信息,总感觉像是陷入了死胡同。
问题的原因
既然如此,我就想着查看一下系统资源占用看看,CPU、内存倒是都很正常,但是两台服务器都在删除文件的时候跑了大量的流量。
Nextcloud服务端流量情况
SFTP服务端流量情况
两次尝试删除的时候都有非常明显的大流量,然后我发现Nextcloud服务端的硬盘空间也有异常:
第一次尝试删除时硬盘甚至直接被占满了,我立刻想到可能是回收站被设置在了Nextcloud服务端上,当尝试从External Storage删除文件时,Nextcloud会先把文件复制到服务端本地,然后删除External Storage中的文件。稍加搜索发现Nextcloud的行为确实如此,Trash Bin的文件位于data/<user>/files_trashbin/files
中,Nextcloud每次从External Storage删除文件都会先将文件复制到这里,导致大量流量和硬盘占用,硬盘被占满的时候自然就失败了。
解决该问题
目前似乎已经有PR试图解决这个问题,目前来讲在Nextcloud23的milestone中,可能在不久的将来就会实装。这个PR的解决方案是admin可以在设置External Storage时选择不启用Trash Bin,删除文件时将直接从External Storage中删除。
在得到更新之前,最方便的解决方案大概只有直接从存储的后端删除文件然后重新filescan了。
Comments NOTHING