The docker’s overlay filesystem may revert your changes if the container is not removed before the change.
Please give me the algorithm for creating a new node for Hashstore.
I thought the network was already set for any new data to go into hashstore? If so… then every new node is a new node for hashstore. Just do a normal install.
I believe we’re waiting for Storj to start pushing migration of data on old nodes to hashstore.
1 Like
Start the node as usual, than activate passive and active migration. Wait 1 day. Clean the blobs folder. Bam! You are on hashstore with a fresh new node. 
New nodes still start on piecestore.
1 Like
You both with @Roxor are correct. The new nodes starts on piecestore, but they will receive a command from the satellite to use hashstore for any new pieces on the next check-in.
@max232 You can just start with the new node and do nothing, or do like @snorkel is suggested.
1 Like
3 posts were split to a new topic: Multinode is failed to fetch node version
Do I understand correctly that old nodes in new versions migrate to the hashstore themselves?
When Storj is comfortable with the software quality: they’ll be able to slowly toggle old nodes to begin active-migration to hashstore. Right now old data is left in piecestore, and new data (on all nodes) is going into hashstore.
I don’t see a big benefit of forcing active-migration early: knowing I can “just wait” (and perhaps avoid some early bugs) and it will happen automatically.
3 Likes
I started a new node like 10 hours ago and all pieces are stored in piecestore, no folders or files in hashstore. So, I believe, the active and passive migration still needs to be triggered manualy. Also, all the tasks were set to false.
Maybe I missunderstood your refference about satellite check in? Maybe it needs a restart to trigger the automigration? I don’t know. I stopped and migrated manualy.
The node should receive a command from the satellite, if the hashstore rollout cursor would allow it to be enabled.
I just enabled full migration on new node
Right now I am noticing a wierd behavioir, seems like a bug.
When I start a new node, then I immediately switch it to hashstore via the echo-order. The migration is happening but the new data is running into the blobs and the piecestore. Not into the hashstore.
Is this intented?
This seems to be default atm. If you don’t want it like that you have to make your changes after first start of node.
Yeah I don’t like it and I don’t want it. I want to have it all to hashstore. What changes are to be made exactly after the first start?
Make sure content of *.migrate files is like this:
{"PassiveMigrate":true,"WriteToNew":true,"ReadNewFirst":true,"TTLToNew":true}
2 Likes
And you need not only stop the container, but also remove it, if you use docker, otherwise your changes could be reverted by docker.
So for hastore only node after migration I am wondering:
- Are there any databases that can be deleted
- Do we still want databases on SSDs
- Can we remove/disable filewalker on startup/lazy filewalker
- Do we still need filestatcache
To me it seems that all of this can be disabled or removed? Or at least which settings are recommended now on hashstore node to not to interfere any longer?
1 Like
Stop node, remove node;
-check if there are any non-zero byte size files in blobs dir;
-delete anything in blobs directory, but not the blobs directory itself;
-delete all databases;
-delete filestatcache dir;
-I’m not sure if you can delete piece_expirations dir, so let it be.
-there was one more dir, but I can’t remember the name; it’s deprecated, so it can be removed.
For a normal hashstore only linux+docker node:
-in the mounted directory (Storj1 for ex.) you should have these dirs:
bin
Identity
orders
retain
storage
-and these files:
revocations.db (never delete this)
trust-cache.json
config.yaml
OPTIONAL, but recommended:
-Backups dir, where you hold a copy of Identity dir and storage-dir-verification file.
-in the storage dir, you should have only these dirs:
blobs
hashstore
piece_expirations
temp
trash
-and these files:
all the db files that are recreated after restart;
storage-dir-verification (never delete this).
You start the node with:
-lazzy-mode disabled
-startup-piece-scan enabled
-badger-cache disabled
-the dbs dir on the storage drive (no need to move it, the activity is verry low).
Hello!
My nodes are running under Synology docker.
I see that they all already have hashstore libraries, but I would like to speed up migrations by making them active.
For example, the contents of the hashstore/meta migrate files on my 3rd node, the chore is false everywhere:
1wFTAgs9DP5RSnCqKV1eLf6N9wtk4EAtmN5DpSxcs8EjT69tGE.migrate
{"PassiveMigrate":false,"WriteToNew":false,"ReadNewFirst":false,"TTLToNew":false}
12EayRS2V1kEsWESU9QMRseFhdxYxKicsiFmxrsLZHeLUtdps3S.migrate
{"PassiveMigrate":false,"WriteToNew":true,"ReadNewFirst":true,"TTLToNew":true}
12L9ZFwhzVpuEKMUNUqkaTLGzwY9G24tbiigLiXpmZWKwmcNDDs.migrate
{"PassiveMigrate":false,"WriteToNew":true,"ReadNewFirst":true,"TTLToNew":true}
121RTSDpyNZVcEU84Ticf2L1ntiuUimbWgfATz21tuvgk3vzoA6.migrate
{"PassiveMigrate":false,"WriteToNew":false,"ReadNewFirst":false,"TTLToNew":false}
a compose file-om:
storagenode3:
image: storjlabs/storagenode:latest
container_name: storagenode3
network_mode: host
environment:
- WALLET=x
- EMAIL=x@gmail.com
- ADDRESS=x.x.x.x:28969
- STORAGE=8TB
volumes:
- type: bind
source: /volume4/shared3/storj3/identity
target: /app/identity
- type: bind
source: /volume4/shared3/storj3
target: /app/config
- type: bind
source: /volume1/SSD/storj_node3_db
target: /app/dbs
command:
- "--console.address=:14006"
- "--filestore.write-buffer-size=4MiB"
- "--pieces.write-prealloc-size=4MiB"
restart: unless-stopped
stop_grace_period: 300s
If I want to start it, then I set everything to true in the migrate file for each satellite and also true in the chore file?
Do I need to add this to the compose file?
–hashstore.table-default-kind hashtbl
Then the container removal and compse up?
Thanks…
I don’t use compose, but you just need to follow the guide in the first post aka just stop, remove, set everything to true and start.
3 Likes