怎么每回你都要出问题？
删除文件时的问题
我目前运行的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