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?