更新：2022-09-22，已解决该问题，方法如下

相关讨论：

https://bbs.seafile.com/t/topic/15833
https://github.com/haiwen/seafile/issues/1309

解决办法：

a> 先看是不是使用了 Go 前端

确保它为 false，如果没有，直接添加相关配置项，手动定义为 false 以便覆盖默认行为避免某个更新版本后默认行为变更导致潜在风险
b> seafile 某个 python 模块依赖出现破坏
c> seafile 某个资料库出现某个文件损坏、索引丢失，无法被 seafile 正确处理，反而生成更多，产生巨量(千万级别) 几 B 的小文件

针对 a，按文章说法改回去默认前端，并且使用 ./seaf-gc.sh --rm-fs 尝试手动清理 fs 对象，如果无效，按针对 b 和 c 的方法处理，针对 b 和 c，可以尝试先使用2个工具， fsck 和 fscg，分别用于检测资料库数据完整性和清理垃圾

这 2 个工具 只要有任意一个无法运行，或者运行时报错退出（python类的），或者 fsck 检测到损坏的资料库，并且修复后继续报同样的 ID 资料库损坏
不用再考虑了，使用 seafile 的 fsck 工具导出所有元数据到本地文件系统

然后备份相关原先 seafile 配置，直接重装 seafile，删除原来的 seafile，恢复配置文件，使用 https://cloud.seafile.com/published/seafile-manual-cn/deploy_pro/seaf-import.md
导入本地文件系统的 seafile 数据

最后应该能解决了，简单验证方法：运行fsck fscg 这2个工具，检查能否运行，且有无报错
特别是 ./seaf-gc.sh --rm-fs，能否运行成功，能运行成功说明 可以正确处理 fs 对象了

观察几天，BUG 消失

find . -xdev -type f | cut -d"/" -f 2 | sort | uniq -c | sort -n

更新：2022-8-26 02:38:20 可以确认是 seafile 的新的前端服务 Go fileserver 有 BUG，产生了巨量巨量（千万级别）的几 B 的小文件，并且任意大于 几十 MiB 的文件，会上传失败，没任何报错，没任何预兆的在上传的某个时间会卡进度条，实际上已经没有产生上传流量了，即使碰运气上传完毕，也会卡在最后的 建立索引/保存文件 的进度提示

为了清空这些千万级别的 inodes 占用小文件，我用 rsync --delete-before -d /tmp/blank/ /home/seafile/seafile/seafile-data/ 清空目录删了1个小时（服务端还是 raid10 SSD）
rm：？？？饶了我吧，删不动

所以去 seafile.conf 把这项改回去，一堆 BUG......，没事不要乱用新的前端，按照seafile官方说法：

提供了一个用 Go 语言重新实现的 fileserver 程序。默认依然使用原先 seaf-server 程序中提供的 fileserver 模块，可以通过选项切换到 Go fileserver。相比原有的 fileserver 模块，Go fileserver 有以下优势：
在高并发的环境下性能更好，避免由于部分请求处理时间过长而导致无法处理其他请求。
支持目录打包下载的 chunked 传输，无需等待整个目录打包完成再下载，而是打包和下载同时进行。这意味着不存在打包下载目录的大小上限。
支持对文件上传、下载进行限速。

[fileserver]

use_go_fileserver = false

可惜我只是踩到了一堆永远填不完的大坑

---

更新：2022-08-02 14:30

已向 seafile 反馈：https://bbs.seafile.com/t/topic/15833
类似 GitHub issue： https://github.com/haiwen/seafile/issues/1309

为了调试，目前准备导出资料库，再删除所有数据，再检查 inodes 占用。

更新：2022-8-7 18:37:52，经过备份导出数据后，再彻底删除 原来数据库，重新安装导入之前备份的文件，才恢复正常，目前还在观察该问题是否复现，
更新：一个星期不到，又来了，inodes 从 7% → 28%，几十万到 200 万 +，这几天的文件上传数量 ＜ 5 个，新增文件大小 ＜ 0.5 GiB，我也很绝望啊......

之前的多次测试，我有个推测，可能是 python3 的某个模块依赖更新导致不支持，或者 python3 版本太高，seafile 因为运行环境问题，没能正确处理 blocks ，事实上我的观察是，有巨量的 1 KiB 以下的、几十 B 的小文件存在，并且永远不会被清理，删光所有数据都不会被清理掉，跟 CG、清空回收站之类的低级失误无关，完全就是 BUG

---

个人自用部署的 Seafile Pro v9.0.7 ，搭在一台 6c8g 160G SSD 的云服务器上面
df -i 显示

/dev/vda1      10485760 9261449 1224311      89% /

可以看到 IDC 还算厚道的给了千万级别的 inode，即使个人较多的小文件备份，一般也是够的，谁知道翻车了

个人使用了 35 GB 的空间，8 个资料库和 共计 15408 的文件数量（来自 seafile 的报告）

问题是，这点文件数量，并且文件历史没多少，seafile 回收站也没什么文件，就能用掉 860 万 + 的inode

标记一下这个问题，看看怎么解决，还是说 seafile的 系统配置不合理？