So I was cleaning my server a bit, and noticed that the ZFS tank is using around 2TB more then reported. df -h reports: Filesystem Size Used Avail Use% Mounted on storage/STORJ 8.8T 4.8T 4.1T 55% /storage/STORJ Exporter Data: Total: 4.000 TB Used: 2.811 TB Trash:…

If my guess is correct (that the record size is involved), and you cannot force compress on already stored data, then you can only try to migrate it to the other folder, using this guide: How do I migrate my node to a new device? - Storj Docs It should store compressed data in a new location. But …

Hi again! Thanks for greeting and Your reply. @mattventura - that was comprehensive explanation. Interesting. I’ve had compression enabled from the very beginning (LZ4 is the default option in TrueNas Scale 24.10) - at the moment STORJ node shows 670GB filled space, but actually place taken is 77…

regarding the initial topic, I also enable compression on my zfs disks. the compression ratio on a storj drive is only 1.08 ,so % isn’t too exciting but it’s nice to know space isn’t being wasted. @foegra there are a variety of ways that the storj dashboard, both by design or bugs . a go - to …

Will see how it goes. In any case - 1.08 is better then 1 :slight_smile: Is there an option to force the node to go through the files check it’s content, integrity etc…?

No. But the restart would calculate the usage and update the databases. The satellites are auditing your node. So, if something corrupted or missing, your audits score would go down.

Does it remove unnecessary files as well? After restart my node size went down from 630gb to 580gb, but actual used space on hard drive did not become smaller.

In my case probably problem started when I’ve moved existing STORJ node while running from one disk to another by replacing disks from TrueNas Scale menu. I have restarted the node from scratch, otherwise every time i restarted the node, node size went back to 580GB.

This is a known issue. Still not recognized as a bug but, we will see…

Do You mean known issue - breaking Storj node by replacing pool disk while node itself is running?

No. After rebooting, data lost until last reboot.

All right, i see. Then i should not have recreated the whole node from scratch. I confirm - rebooted the node and used space went down to the value it was before previous reboot. Question - is this only UI issue or it affects the payment calculation as well?

Node using a lot of extra diskspace (ZFS)

Node Operators troubleshooting

arrogantrabbit November 29, 2024, 4:46pm 45