查到一个在 2015年提的issue,目前看没有任何改善
opened 09:40PM - 08 Jul 15 UTC
closed 07:29AM - 13 Aug 15 UTC
After finding I ran out of available inodes on my virtual machine, I found out s… eafile is using up most of them (using `find / -xdev -printf '%h\n' | sort | uniq -c | sort -k 1 -n`).
I had one large-ish (6GB) library which I just almost completely emptied (for debugging purposes), I set the history setting to **Don't keep history** and ran `seaf-gc.sh run` multiple times on the server.
This is the output for this library:
`[07/08/15 23:31:30] gc-core.c(350): GC finished. 9 blocks total, about 9 reachable blocks, 0 blocks are removed.`
Which is satisfying, I came from ~90.000 blocks when the library was still full-size.
Still, the `seafile-data/storage/fs/{LIBRARY_ID}/{XX}` directories (258 of them) take up some 1.6GB and ~400.000 inodes (count using `ls -Ria | sed -e 's/^ *//' -e 's/ .*//' -e '/^$/d' -e '/^\./d' | sort -u | wc -l`).
This is an absurd amount of files for an empty library, is there any way to clean this up?
**EDIT:** Also, the seaf-cli client has the same problem for the same library.
明显是出BUG了,blocks 对象没有正确处理,他一直在增长,不会被清理,短短几天内,文件数增加了几个图片,几十文件数量,我的 inode 增长了几十万,如图:
,并且issue里面已经有人指出了,里面的,回答 “The fs directory contains file system metadata for library. The number of
metadata is roughly the same as you’ll have if you store the files in ext4
etc. So I don’t think it’s a real problem. Do you have a way to enlarge
your file system?” 十分不赞同,如果真是文件系统的元数据,把数据等量的迁出seafile,以 seafile 资料库里面的原始目录层次存放到实际的ext4文件系统上面,绝对不可能是回答的这个情况,两者 inode 占用会是一样的,1.5万个文件数量吃掉千万 inode?
3天前的到现在增加了 16 个小图片文件,blocks 目录的 inode 增加 7万
希望尽快修复此类问题,服务器已重启,已关闭所有 历史版本,已清空所有回收站,已清空所有已删除的资料库,已重启 seafile,已进行 CG、FSCK 清理、检查,并重启服务器、seafile
无任何效果