.seafile-data/storage on client takes all inodes (normal or bug?)

Seafile Client
#1

I have a seafile server on a raspberry pi4 and I have the client (installed the seafile-gui package) on my desktop PC running Trisquel GNU/Linux (derivative of Ubuntu with exclusively free software).

On my desktop, I had automatic synchronization of my .mozilla directory (~/.mozilla) to a seafile library created just for that (that library keeps no history). It just uploaded to the server everything that Firefox (actually, abrowser, a rebranded variant) puts there.

At some point, I had errors and found out that I could not write anymore to the disk of my PC because the ext4 filesystem had run out of inodes (df -i said 100%, about 13 million inodes).

I looked at .seafile-data on my PC, it took 48G (not a problem) but around 13 millions inodes. More precisely, I looked into .seafile-data/storage/commits and the directory whose name corresponded to the ID of the above mentioned library (as visible from seafile-cli status).

I stopped the synchronization of that library, then I noticed that the corresponding directory in .seafile-data/storage/commits had been removed. Also, df -i showed that inodes were gradually freed. I did that yesterday and my desktop is still freeing inodes (most likely because it does it slowly in the background in order not to affect any activity).

Now, .seafile-data/storage is about 10G, so the subdirectory of commits for the libray for .mozilla had 38G data, while .mozilla - that it is supposed to be for - has only 218M and 2009 inodes.

Why is it so that, on the client, .seafile-data/storage/commits/ID can make more than 10^4 times the number of inodes than the actual library it corresponds to and take about 200 times the disk space?

#2

We had a sync issue with a MacOs that does not handle the case correctly : a bunch a files where renamed in loop for some days across 5 clients.

Consequence is a huge increase of inodes use on the server side

Tried to set history down and run seaf-gc/fsck : some space was reclamed, but not the inodes

I guess that the commits are not cleaned up, and eat up them

Is there a way to merge those commits without rebuilding the library in order to free the inodes ?

#3

As the title says “.seafile-data/storage on client takes all inodes” and I also tagged my message with “Seafile Client”.

To avoid confusion in discussions, I’d suggest using a different thread for your issue.

#4

I’m having the same problem on both my laptop and desktop. On my laptop .seafile-data/storage uses 1.6GB and over 100k of inodes in use in at least two subfolders of .seafile-data/storage/fs (I think it’s over 14 million but I’m not super sure how that works, but I noticed the inode usage is contributing to higher usage than expected). On my laptop it’s even worse. My libraries are quite small, 20-30GB in total depending on whether it’s my laptop or desktop, so I don’t understand why the Seafile client is wasting so much space and using so many inodes.

It feels like either accidental leftovers from older client versions (from long ago) or a bug in the client that causes this behaviour, but I’m not sure how I could know which of the two it is.

#5

Sorry for misunderstanding,

I was saying that to point to a usage that lead us to an “inode bomb” for potentially the same reasons, maybe on the client side, some files may need to be ignored to avoid renaming or sync of very small files (that was our main issue).

Or the client could use some of other tools/logic from the server as I am not aware of like seaf-gc, from version 9.0.4 CE has a flag --rm-fs that does exactly that

Regards,

#6

Hi,

I was running into a problem that I could no longer open some tools such as VS Code. I ran a script found on https://github.com/fatso83/dotfiles/blob/master/utils/scripts/inotify-consumers

the result:
Inotify watches count | instances per process | PID | User | COMMAND

36871 | 2 | 322291 | user | /usr/bin/seaf-daemon -c /home/user/.ccnet -d /home/user/Seafile/.seafile-data -w /home/user/Seafile

I don’t find any solution posted above but let me know if I’m misinterpreting the answers provided