At least @BrightSilence is using the SSD cache I believe. Not sure about pinning though.
Trash dir 2024-08-25 still “kk” on deletion. Seems really slow on ext4 nodes (zfs nodes was fast)
drwx------ 2 root root 3747840 Sep 9 12:53 kk
drwx------ 2 root root 3661824 Sep 9 13:16 kl
drwx------ 2 root root 3665920 Aug 27 08:33 km
Total of 6/7tb of data to delete. Filestat cache enabled but seems not working great as filewalkers
I read it. Too many nodes, too risky and this is a temp patch.
I think we need a long term fix for basic ext4 config without cache that personally think is the core of this project. Basic small decentralized users that using the most used filesystem without extra tuning.
1 Like
I don’t expect this amount of trash accumulating again. It was caused by a bug with the TTL database and the bloomfilter not catching this data. This should be fixed now.
1 Like
I agree that this much probably won’t be going through regular garbage collection bloom filter, BUT, I do think that we are approaching a soft limit on the size of a node that can be supported by a regular file system (ext4, btrfs, ntfs) with no special caching.
A single TTL delete is probalby (?) just as slow as a trash empty delete. So this soft limit will vary depending on the amount of ingress and the amount of deletes.
but if it’s like during test that means that around 8TB disk is the max that can keep up, without extra measures (SSDs, badgers, etc).
1 Like
This is the closest I cared and had opportunity to do: Ext4 + LVMcache, some numbers
1 Like