Changelog v0.31.9

For Storage Nodes

Preflight Check System Clock
Storage node will print out an error message if the system clock is off by more than 10 minutes. Kill the storage node if the system clock is off by more than 30 minutes with all trusted satellites.

Preflight Check SQLite Database
If something is wrong with the SQLite Database the storage node will not start. This check is now enabled by default.

Graceful Exit Performance Improvements
We optimized the settings around graceful exit. The batch size on the satellite side is increased from 100 to 300. The storage nodes will start with 4 workers and 5 concurrent transfers per worker. The minimum transfer speed is now increased from 128 B/s to 5 KB/s. That way the graceful exit node should not get stuck because the target node is transferring too slow. Lets see how that works.

For Customers

Delete Performance
Even when deleting a big file the uplink should finish almost immediately. The satellite will handle the rest.

Zombie Segments
Zombie segments can now be overwritten. The satellite will delete the old zombie segments before uploading the new segments.

Order Expiration
Decrease order expiration from 7 days to 2 days. This is only the first step to make the billing more transparent. More changes will follow.

Billing Enabled
Billing is now activated. In the webUI you should see the total price you would have to pay at the end of the month. Don’t worry we will not create an invoice for January. Every user with a credit card, or 50$ in STORJ tokens will get a 1 TB coupon. You might have to refresh the page to see the coupon. Soon we will publish more information about the 1 TB coupons.
The 10% disccount on STORJ payments is not finished yet. It will hopefully be available with the next release.

Rate Limiting
We have added a rate limit of 30 requests per project per second. If you need a higher limit please contact us.

Upload and Download Performance Improvement
We have upload and download usage limits in place to prevent free accounts from abusing the system and for paid customers, we want to be able to balance supply and demand. The usage limit are stored in the database and updated on every upload and download. Instead of hitting the database directly we have added a cache. On top of that we reduced the load other queries are causing on the database. This should improve the performance.

Please run your performance tests again and give us new feedback.


What is that mean? Kill is dq?

My understanding is that the node just won’t start, more like kill the process versus kill the ID.

1 Like

No, these comments are referencing only preflight checks, which are checks that the nodes now need to pass upon startup. As I understand it, if a node does not pass these preflight checks (most likely because of a bad configuration, such an unsynched clock), the node will not even start up in the first place. If the SNO remedies the problem (i.e. by synching the system clock in this case) then the node should properly start up and commence functioning, unless there is some other failed preflight check impeding it from doing so.


When it just not starts it just not starts. But here is something new

This isn’t the node not starting, these are pre-flight checks. The node will run through these checks before doing anything else. If they fail the storagenode will stop, as Heunland has mentioned in her reply, until the issues are resolved. It does not disqualify the node.

Okey. Thank you both

You are right about every thing else :slight_smile: