Yes, that will kick off the conversion.
Not sure on badger cache, but I believe it becomes redundant on hashstore. Might be worth leaving it enabled until conversion completed.
1 Like
Are you sure? That part sounded like it would kick off the passive migration which I believe shall not be required when I am performing an active migration with echo -n 'true' > 121RTSDpyNZVcEU84Ticf2L1ntiuUimbWgfATz21tuvgk3vzoA6.migrate_chore.
Only WriteToNew:True might make sense during active migration as I donāt know how uploads are handled while active migration is running.
But the other setting donāt make sense during active migration as I understand them.
Yes, they need to be enabled too. Based on my tests on storj-up, they do not contradict each other.
You may also do not enable an active migration, but enable only a passive one, but the migration itself will be much longer.
Like this
echo '{"PassiveMigrate":true,"WriteToNew":true,"ReadNewFirst":true,"TTLToNew":true}' > 12EayRS2V1kEsWESU9QMRseFhdxYxKicsiFmxrsLZHeLUtdps3S.migrate
additionally to
echo -n 'true' > 12EayRS2V1kEsWESU9QMRseFhdxYxKicsiFmxrsLZHeLUtdps3S.migrate_chore
?
Yes. falses there were for protection from the mistakes on early stages, but now itās pretty safe to enable them.
Ok then. But the chosen wording seems to me very strange thenā¦
You need to enable both, one puts new pieces in hashstore, the other moves already stored pieces from piecestore to hashstore.
But why? It sounds contradicting.
TTLToNew sends only TTL uploads to hashstore. WriteToNew sends all uploads to hashstore.
ReadNewFirst sends pieces to hashstore that got a download request but these should get moved during active migration anyways.
I have enabled it but I still see no point in these settings additionally to an active migration.
Whether or not it makes sense, Alexey is right that the code expects these config values to be present for it to be enabled, prior to our official rollout.
1 Like
It is still weird in the light of what I have just observed:
I had set everything to true in the files with migrate_chore and migrate suffix.
So for example: 12L9ZFwhzVpuEKMUNUqkaTLGzwY9G24tbiigLiXpmZWKwmcNDDs.migrate_chore > true and 12L9ZFwhzVpuEKMUNUqkaTLGzwY9G24tbiigLiXpmZWKwmcNDDs.migrate > {"PassiveMigrate":true,"WriteToNew":true,"ReadNewFirst":true,"TTLToNew":true}
Then I have restarted the node.
After 16 hours when I checked, the files with suffix migrate_chore contained no longer true but false. The other one is still showing true as expected.
Modification timestamp shows that the files have been modified appr. 2 hours ago which means I did not do it. All migrate_chore files have been modified to false even from those satellites that have their migration not finished yet as there are still files in the blobs folders.
So if the code expects all settings and parameters set to true to work properly then something did go wrong.
I have for now set the values back to true again and restarted the node.
It just happened again. The value has been flipped to false again.
I donāt know what is going on.
Could you please try to do it in a different way:
- Stop and remove the container
- Change these options back to
true - Run the container
I will try it. It may take a bit to switch. However let me add that I am (trying) to migrate a couple of nodes and I started it performing the same action on them. And I see a node that did the flip and another that did not as you can see from the ls output:
ls /storagenode_01/storage/hashstore/meta/ | grep migrate
Aug 23 12:59 121RTSDpyNZVcEU84Ticf2L1ntiuUimbWgfATz21tuvgk3vzoA6.migrate
Aug 23 12:59 121RTSDpyNZVcEU84Ticf2L1ntiuUimbWgfATz21tuvgk3vzoA6.migrate_chore
Aug 23 12:59 12EayRS2V1kEsWESU9QMRseFhdxYxKicsiFmxrsLZHeLUtdps3S.migrate
Aug 23 12:59 12EayRS2V1kEsWESU9QMRseFhdxYxKicsiFmxrsLZHeLUtdps3S.migrate_chore
Aug 23 12:59 12L9ZFwhzVpuEKMUNUqkaTLGzwY9G24tbiigLiXpmZWKwmcNDDs.migrate
Aug 23 12:59 12L9ZFwhzVpuEKMUNUqkaTLGzwY9G24tbiigLiXpmZWKwmcNDDs.migrate_chore
Aug 23 12:59 1wFTAgs9DP5RSnCqKV1eLf6N9wtk4EAtmN5DpSxcs8EjT69tGE.migrate
Aug 23 12:59 1wFTAgs9DP5RSnCqKV1eLf6N9wtk4EAtmN5DpSxcs8EjT69tGE.migrate_chore
ls /storagenode_02/storage/hashstore/meta/ | grep migrate
Aug 23 11:53 121RTSDpyNZVcEU84Ticf2L1ntiuUimbWgfATz21tuvgk3vzoA6.migrate
Aug 24 09:22 121RTSDpyNZVcEU84Ticf2L1ntiuUimbWgfATz21tuvgk3vzoA6.migrate_chore
Aug 23 11:53 12EayRS2V1kEsWESU9QMRseFhdxYxKicsiFmxrsLZHeLUtdps3S.migrate
Aug 24 09:22 12EayRS2V1kEsWESU9QMRseFhdxYxKicsiFmxrsLZHeLUtdps3S.migrate_chore
Aug 23 11:53 12L9ZFwhzVpuEKMUNUqkaTLGzwY9G24tbiigLiXpmZWKwmcNDDs.migrate
Aug 24 09:22 12L9ZFwhzVpuEKMUNUqkaTLGzwY9G24tbiigLiXpmZWKwmcNDDs.migrate_chore
Aug 23 11:53 1wFTAgs9DP5RSnCqKV1eLf6N9wtk4EAtmN5DpSxcs8EjT69tGE.migrate
Aug 24 09:22 1wFTAgs9DP5RSnCqKV1eLf6N9wtk4EAtmN5DpSxcs8EjT69tGE.migrate_chore
You can see from the modified date that āsomethingā changed the file and when I look into the modified filed they have been reset to false.
Something went wrong. Is there a way to get the 1wFTAgs9DP5RSnCqKV1eLf6N9wtk4EAtmN5DpSxcs8EjT69tGE.restore file back? I think I have killed it.
Edit: Is there even supposed to be a 1wFTAgs9DP5RSnCqKV1eLf6N9wtk4EAtmN5DpSxcs8EjT69tGE.restore file? Because I see it on some nodes and not on others.
Edit2: I have checked on another node where I had not started migration yet. And it has only these restore files:
ls /storage/hashstore/meta/ | grep restore
121RTSDpyNZVcEU84Ticf2L1ntiuUimbWgfATz21tuvgk3vzoA6.restore
12EayRS2V1kEsWESU9QMRseFhdxYxKicsiFmxrsLZHeLUtdps3S.restore
12L9ZFwhzVpuEKMUNUqkaTLGzwY9G24tbiigLiXpmZWKwmcNDDs.restore
So Saltlake restore file is missing there tooā¦
On converted nodes I have this file. On node that has not been converted yet, I do not have this file.
1 Like
But only this one is missing, correct? You do have the restore files for the other satellites even on the not yet converted nodes?
I have same problem, on windows GUI node change it back to false.
I made nodes migrate_chore to true in file, and today after reading this post, checked it, and it is back to false.
Yes
(16 wasted chars)
1 Like
Checked on one of the nodes that I started migrating to hashstore 2 days ago.
The migrate_chore files stayed at true as intended, and the migration is still chugging along.
Running baremetal Linux (no docker, no vm).