飘在云端

啊!那蓝真天,白真云!

· seafile · · 202次浏览

Seafile seafile-data/storage/fs inodes 索引量占用太多

更新: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的 系统配置不合理?

评论 (1条)
  1. 量子涨落 博主

    尝试抢救下,打算备份数据之后,发工单给 IDC,让他改,结果回复......

    Sorry, while it's possible to change the inode count while formatting the disk of a physical server, I'm afraid it will not be possible in this case since these are cloud servers created using templates.

    机翻:

    抱歉,虽然可以在格式化物理服务器的磁盘时更改 inode 计数,但恐怕在这种情况下不可能,因为这些是使用模板创建的云服务器。

    回复