In order to run the startup piece scan, many of us that run the flag in docker run command would need to wait for the upgrade to 104 and than recreate the container with activate piecescan. So… if that downgrades the node, we didn’t accomplished anything. Maybe wait one more month until 104 is the minimum allowed version. Or make it now the minimum.
It won’t though. If you’re node is upgraded to 1.104, it will then always be below the cursor and will always keep downloading 1.104 after restart. The problem is for nodes that still aren’t selected for this update by the cursor, those will be downgraded from 1.102 to 1.101.
Aw. Crap. This again 
(Note: I only care because eating another startup-filewalker-full-disk-scan feels like a waste to go backwards in version)
Edit: I too have now seen a node go 1.102 → 1.101 after a simple restart
1 Like
The address for version server is in the config. Why not just changing it to whatever you want?
# server address to check its version against
# version.server-address: https://version.storj.io
Sorry everyone, I got an enable/disable confused again. That’s fixed again in the original post.
Thank you for the heads up about the miss on the minimum version. That should be fixed now too and I’m adding it to our preflight checks.
7 Likes
looks like version.storj.io updated minimum to be 1.102.3
4 Likes
Thanks for the fix, JT. Please make extra sure it doesn’t happen on the next rollout. If 1.104 gets downgraded to an earlier version those nodes will instantly break due to the db migration. So it’s extra critical next time.
7 Likes
–filestore.force-sync=true-> old way, bad performance but safe.
–filestore.force-sync=false → new way, good performance but not so safe.
Am I right?
It was considered but I voted against it. Under normal circumstances with no bugs you shouldn’t have to run it at all. That is cheaper than having to run it lets say once per month or so.
That is easy. Here is my code snipet:
sed -i 's/pieces\.enable-lazy-filewalker: false/pieces.enable-lazy-filewalker: true' /mnt/sn*/storagenode/storagenode/config.yaml
for i in {1..3}; do systemctl restart storagenode$i.service; done
This isn’t the correct config but you get the point. One line to change all configs is all it needs.
Same for docker nodes. I would use a docker compose file to define the environment variables for all nodes in one place. It would be easy to change it and restart all nodes.
Yes! And I should say, the new way is still fairly safe. But I agree with your assessment. The old way is extra safe.
2 Likes
That works for who uses config to set parameters. I only use docker run to set everything.
1 Like
Even docker users can set config parameters then restart docker using docker restart storagenode. This will apply the new config changes.
Sorry but maybe I’m a little hard to understand. Since I only use windows nodes, what are the new default settings? I don’t have anything set in the yaml file other than the default configuration apart from the db which are on an SSD and so I changed the path. Do I have to do something for the new filesync setting or does it leave everything by default and therefore without inserting anything into the yaml file and therefore automatically takes the new configuration? i.e. the fastest one but with less security for system crashes? Thanks but even reading the post I didn’t understand if something needs to be done to switch to the new quick configuration or if it’s enough to do nothing.
thanks a lot in advance
@nerdatwork I know, but I want to keep everything in one place. And we don’t all have scripting skills. To use run command and config means, at least for me, to fire up putty and winscp, one for commands, the other for config.
And since I am so lazy, I want to use only putty to set and change things.
@digitalfrank You don’t need to do anything. The default (speed/unsafe mode) will be enabled. I believe a new option will appear in config once you are upgraded to 104. If you want to disable it, you can change the defaut than.
1 Like
Dang… I didn’t get to read it. 
Now I’m curious what he is up to this time.
3 Likes
testnode v1.104.1
docker stop…
docker rm…
docker run…
absolutely nothing in the trash chart has changed…
Did the piecescan finished?
1 Like
Are you asking me?
And how do you check it? It’s been over an hour since the node was launched, it’s only about 14GB of data…
Another general reminder to use appropriate language when posting in the Forum.
Say what you need to say but let’s keep it clean.
Posting in the Forum requires abiding by the Code of Conduct
https://www.storj.io/legal/code-of-conduct
4 Likes
OK, I won’t write a word on this forum anymore…