Graceful Exit Fix
The satellite keeps track of the last IP address of each storage node. When an uplink requests a list of storage nodes the satellite returns the last IP address so that the uplink doesn’t need to resolve any DNS entries. The same trick we will use now for a graceful exit. That way the graceful exit node doesn’t need to resolve any DNS entries. We believe this will reduce the number of connection issues caused by overloaded routers or network hardware.
Handling Corrupted Order Files
The storage node will now detect and handle corrupted orders or corrupted order files. Worst case it will skip an entire order file and just continue with the next one to make sure the storage node still gets paid for every valid order that it is still holding.
Untrusted Satellites in Payout History
With the removal of Stefan’s satellite, the corresponding line was missing in the payout history. The storage node dashboard will now display the payout but with an empty name. We hope this minimal solution will work for now.
Order Submission Phase 3
Over the last few releases, we have transitioned to a new accounting system. In the old accounting system, the satellite was keeping track of submitted and unsubmitted serial numbers. This was needed to reject double submissions but it was an expensive validation. In the new accounting system, storage nodes are supposed to group orders by creation hour and submit that batch once to the satellite. The satellite will write the sum into the accounting tables. If the storage node tries to submit an order twice, the satellite will notice that it has already an entry in the accounting table and reject the double submission. In the future (not the current release) we expect better performance and also better scaling. First, we need to remove some leftovers from the old accounting system.
Bugs happen. Just that. Don’t worry, it’s just a hypothetical for now. Besides, if Storj engineers believe that the risk of having a systematic error in order file generation is smaller than an occasional error, then it’s fine.
i think it is much bettery system, as today if there is corruption, then we discover is next month usualy, when there is smaller payout, and it is too late to submit this orders, in new one we will lost only currupted part.
Handling Corrupted Order Files sounds great, thanks. Though does anyone know why the order files get corrupted in the first place? This is too common to be one-off hardware issue and would be good to understand the cause. If sno stored data files with this error rate we’d all be disqualified by now.
I had corrupted orders on my few nodes which all have 100% audit/uptime and I’m using ext4 with Filesystem features: has_journal. What would I check to confirm the drive cache issue?
Will this version be released automatically? Means my node will update automatically or do i need to stop the node, remove the docker image and relaunch the node again? Is this already in production? 'cause my node is still on 1.16.1
Rollout of version 1.17 isn’t done yet. Give it a few more days.
As long as you have the watchtower setup (or equivalent if you’re on Windows… I’m not sure how it works on Windows), it should update automatically in the coming days.
