Changelog v1.6.4

Is there a statistic how much nodes (%) are in Windows, how much in docker?

Not really.
You can see a total number of pulls for the storagenode image: https://hub.docker.com/v2/repositories/storjlabs/storagenode/ but it useless
However, you can configure something like https://www.gasimof.com/blog/track_docker_image_pulls/ to track this stat.

The same is going for the binaries (you can take a look on number of downloads): https://api.github.com/repos/storj/storj/releases

And moreover - the docker can be run on Windows (and MacOS) too

I’m sure this will be integrated in the binaries in the future to report such things to Storj.

Is the upgrade finish on docker? Usually it take less then 2 week after the announcement? My watchtower didn’t update the node yet.

I think update was pulled because of some bugs

2 Likes
2 Likes

Update v1.6.4

Bugfix for the fatal errors some storage nodes had with v1.6.3.
Bugfix for repair traffic on storage node payment dashboard.
Monkit stats for delete_random_serial

I have updated the changelog.

5 Likes

For docker nodes ? For update

On a short question without understanding the background I will give a short answer. Yes.

The long answer would be: We haven’t published v1.6.3 on docker so there is no need to push out v1.6.4 right now. The number of windows nodes that have to deal with the v1.6.3 bug is relativ low. It could get worse with v1.6.4. -> Slow rollout even for the bugfix. Maybe not as slow as usually but at the end I don’t see a reason to update the v1.6.3 nodes to v1.6.4 within a few minutes. We shouldn’t rush it and make sure the bugfix is working as expected.

1 Like

For the phased rollout it might be good to stick with the same seed and just reset the cursor so effected nodes with 1.6.3 get this version first.

I take it, it will randomly start dropping “Used” serial numbers, rather than new serial numbers that haven’t expired yet within the 1hr.

Ideally these serial numbers should be dropped in the oldest timestamp first, rather than at random.

Nope for 2 reasons.

  1. Tracking the timestamp requires a lot of additional memory.
  2. If you drop the oldest timestamp first then I can cheat you and download my file twice without having to pay for it. If you drop a random serial number that might be a serial number from 10 minutes ago but from my perspektive it is very unlikely that 29 storage nodes dropped the same serial number. Even if you dropped it I can’t abuse it.
2 Likes

I´m on the middle of a graceful exit on one of my windows nodes. I stopped the update service while the process doesn´t end. Right move?

You should be able to update just fine. GE will resume after the update is done. If you’re on 1.6.3 I think it’s probably better to get that update as there is a known issue in that one. If you’re on 1.5.2 you may as well finish the GE on that version.

1 Like

I´m on 1.6.3 :frowning:
So, should I just keep the update service running?
Are we sure it won´t break the GE process? I have quite an amount in held…

I’m sure that Storjlings have said in the past that a restart is fine and the process will proceed as long as you don’t stay offline too long. That’s good enough for me, but I haven’t done a code review on this. You’ll have to decide for yourself whether you want to rely on that. But the alternative is sticking with a version that has caused fatal errors on some nodes and took them offline. So that doesn’t sound like a great idea either. I would take the update when it’s available, but perhaps @littleskunk can advise on this.

1 Like
  1. Wouldn’t a ring buffer automatically drop the oldest orders without tracking any timestamps?
  2. If the oldest timestamp is dropped, in what situation can you cheat me and download files twice which isn’t covered by the unlikelyhood of 29 storagenodes all dropping the same orders? (because then there must be a situation where all 29 storagenodes can’t submit the orders and are all dropping the same orders. So the only possibility I can think of is a satellite downtime of more than 1 hour)

serial numbers != orders

ok, guess I may not have understood what serial numbers and orders are about in that context. So I’ll just leave it at that.

Should I just leave the updater service running in my windows node that´s running a GE?