No it would not. It would start at 0 every month and slowly build up towards the total average amount of storage at the end of the month. Just like a 100w device would have used 0Kwh at the start of the hour, 50Kwh after 30 minutes and 100Kwh at the end of the hour. So that would only match average storage over the month at the last second of the month.
You can expect payout data to match closely to the Average Disk Space Used This Month graph though as both of those are based on satellite data.
I think this is incorrect. I believe this is also based on satellite reporting. Just the Total Disk Space used graph is based on local node data. But the node only tracks the current amount of storage locally, not historic storage, which is what would be required to calculate the TBm.
Now that would only be true if youâd know for sure that it is calculated exactly the last second that month. But how would you know that it is not calculated before on that day?
Anyways⌠Itâs Sept. 1st now. So that line for August looks like this:
Which⌠surprisingly, still not above 3,85TB (which can be explained by databases screwup if and only if that number really comes from the local stat, and will be updated later at payout)
The satellite reports this back in time windows of usually around 12 hours. I donât know how those time windows are assigned to months exactly, but I believe they use the start of the time window to determine what month it belongs to. Meaning itâs probably even hours after the month is over that this number is final for the month.
And it wonât be. This number will approach the number listed in the Average Disk Space used graph, which is seems like it has in your case now. This is based on all paid data stored and excludes trash and garbage that hasnât been caught by garbage collection yet. I am a little surprised that you have 0B of trash and Iâm wondering if something is preventing your node to run garbage collection correctly. I havenât seen 0B trash on my nodes, basically ever. Thereâs always at least something in there.
That 3,85TB number is definitely local stats. But it might be correct, since local stats canât differentiate between paid pieces and garbage that hasnât been collected yet.
Yeah, this part is true. Unfortunately I have issues with the GC. My node is slow, and although there are times when the GC can run through its course, but there are more times when it canât.
The issue happens when thereâs a big spike in customer downloads and at the same the GC wants to run. At these times the storagenode binary becomes a zombie process without actually becoming a zombie process. Meaning it cannot even respond to SIGTERM signals. For this I had to write a small script that kicks the binary in the ass, restarting it. That also means the GC is interrupted and will try to run at a later time restarting the cycle.
(Iâll update the node to a faster one at around end of the year hopefully)
That would fully explain the difference in numbers. GC isnât able to fish out data your node should no longer hold. So there is unpaid data remaining on your node. The satellite doesnât count that, but your local node does (because it doesnât know which pieces are unpaid).
Now thatâs unfortunate.
Payment is closed, storagenode restarted, and for August it still shows 3.67TBm.
I still canât believe that this huge difference is only because of the GC. I had like 300GB deleted a week ago, so GC sometimes can run fully. (it only drowns when it takes more than a day to run)
Iâll recheck and see AFTER I was able to upgrade my node to a faster one that the numbers are checking out or not.
The GC performance is usually limited by the disk, not the compute. However, if you have more RAM, the OS can use it for the cache and increase speed of GC evaluating.
Hi
Its been two more weeks now, and I still have a 5TB of old satelites data that doesnât delete.
I think there is a problem with the disk because I have to run chkdsk every month. I condiser making a graceful exit and restart with a new disk. I think it will be very long to copy 15TB of data, 5 of which are useless.
In that case, can I keep the identity keys or do I have to start over ?
If you would finish the graceful exit, this identity cannot join satellites anymore, so you would need to start over (generate a new identity, sign it with a new authorization token and start with a clean storage).
