Audit and Suspension Score Warning
In the last release, we introduced an audit and suspension score overview on the storage node dashboard. The yellow warning sign will now be shown for any score lower than 95%. Special thanks to @BrightSilence
The storage node payout dashboard is now showing held returned for previous payouts. It will display the 50% held returned in month 16 as well as 100% held returned after graceful exit.
Dashboard Used Space Fix
After reducing allocated space below used space the storage node dashboard was showing incorrect numbers. The dashboard was assuming that a negative free space value must be a bug and was showing (allocated space - free disk space) instead. That adjustment was a workaround from the old days. In the meantime, we had a few fixes on the backend side. I believe the workaround is not needed anymore. The dashboard should show the correct used space values now. Please let us know if you still see wrong numbers on the storage node dashboard.
Windows Updater Fix
The windows updater v1.12.3 and v1.13.1 are able to download a new version but they will fail to restart the storage node and more important they will fail to restart themself. Even after a manual storage node update when the dashboard is showing the latest version the storage node updater might still fail to update itself. Please check the logfile for the storage node updaterC:\Program Files\Storj\Storage Node\storagenode-updater.log. Make sure to look into the updater log and not the storage node log. In the logfile search for the last Running on version. v1.13.3 or v1.14.1 is good. If you are running an old storage node updater please restart the updater. If that still doesn’t fix it please replace the updater with the version from github https://github.com/storj/storj/releases/download/v1.13.3/storagenode-updater_windows_amd64.exe.zip and restart the updater one last time.
Linux vs Windows Updater
We did some progress on the Linux updater. We still have a few more issues to fix before we can release it. One problem was the file extension on our github page. The windows binaries ended with .exe.zip but the linux binaries don’t. To unify the windows and linux updater we renamed all files on our github page into .zip . The file names inside the zip archive haven’t changed. We don’t expect any issues on the storage node side but this change might break identity and uplink download links. If you notice a wrong link please let us know.
Multiple Project Support
Each project comes with 50 GB storage space and 50 GB download traffic limit. Each project also comes with its own separate API keys. And last but not least projects will be listed in the invoice.
Please contact support if you need more than 10 projects.
There was a lot of discussion and feedback on the loading screen when it was introduced, the general concensus was people didn’t like it and wanted the previous method without any loading screen.
The new screen loading introduced an additional delay in actually showing the data on screen compared to taking a split second to see the data.
Actually in the current/latest version of StorJ my dashboard node takes a good 15~ seconds sitting on the loading screen to show the main dashboard page. This used to take half a second before loading screen was introduced and with the loading screen introduction originally it took 2 to 3 seconds. Unsure why it’s now taking 15~ seconds.
Even though I understand it is low priority compared to other problems, it is a rather poor choice to tell SNOs “we’re going to change it in the nearest future. Please wait for changes, your feedbacks are really important to us.” when the nearest future doesn’t even have a date and might not even be anytime soon. Doesn’t make SNOs feel like the feedback was very important. (Of course adding the loading screen in the first place was due to feedback from the SNOs and a rather low priority feature as well. I’m just exaggerating a bit. Not every SNO reads everything or has been around this long)
Then how about a quick workaround, at least for a web dashboard? You could modify the “loading-screen” class height to match header height and adjust the spinner size accordingly. It takes a minute and will be a great QoL improvement.
The downtime measurement is enabled. Suspension or disqualification is not yet enabled. You should try to minimize downtime because it will show up in your history for 30 days. If we enable suspension in 21 days you might get suspended. Disqualification shouldn’t be a problem because worst case you would just get suspended for up to 30 days but if you don’t collect new downtime you would get unsuspended.
You can already see the number using the earnings calculator.
For the first 30 days this score will show 100% though. I’m not entirely sure when those first 30 days are over. My nodes still show 100% everywhere. But I’ve also had barely any down time. The reason for this is that the satellites don’t want to punish nodes within the first 30 days, because not enough data is known yet. It should of course still show the actual score and just omit any punishments, but that’s not currently how it’s implemented. Either way, you can monitor the uptime there until it’s shown on the dashboard (which I’m sure will be soon as well).
By the way, is there an official topic or article that explains how Disqualification and Suspension work?
We can find information spread out around the forum but it would be more convenient and easier to understand if we had an article on support.storj.io.