I’ve created this FR; https://github.com/storj/storj/issues/3973
It basically attempts to prevent a storage node from starting, if the node starts in the wrong location.
The reasons could be many;
- SNO made a mistake;
- forgot a mount and rebooted
… or any other silly thing happened. The point is, the node shouldn’t start and get reachables, and DQ itself fast and silent. Instead - stop the node, and write about a wrong path.
That would remove a large percentage of the reasons why SNO’s DQ nodes - simple mistakes. In a robust storage network theres NO place for such a fragile setup; ‘made a mistake? We’ll boot anyways, and give you a silent death, haha!’ - instead, shut down the node. Simple.
See the FR for more info and suggestions.
docker mounts have it’s own protections against this on startup. The container may constantly restart until the volumes attached have appeared.
There could be additional checks within the software though if it makes it past this stage. Which i think were added in a previous release, but i don’t have the changelog handy at the moment.
I don’t know if this has changed but previous Docker only errored out if it couldn’t access the mount, before that it stored data internally which is a gross error. Docker should not start if databases and config files aren’t openable. There should be a separate command to create these. Again, don’t know if this has changed in the meantime, I haven’t tested.
Surely a node could be aware whether it’s new or not thanks to satellites?
Instead of having to initialize manually a node, it could do it on its own at start-up by querying sats’?
The problem is that if I mount /dev/sdm1 into /mnt/node3 and have docker mount into /mnt/node3 - that dir will always exist, and the mount check will always work. However if I forget the file system mount first; the mount will be empty, and that is the situation to prevent.
If I were to mount /mnt/node3/subdir/otherdir/datadir into Docker, and didn’t mount the filesystem, the docker mount check would prevent the docker from starting, as the directory wouldn’t exist, because it was empty from /mnt/node3 and down.
This is exactly what I said, if a node is started like “fresh” with only an old (not DQed) identity file, it will fail spectacularly.
It’s implemented as a setup step: Storage Node - Storj and in the Windows installer GUI Install - Windows - Storj during install.
We creates all needed folders structure and file in the storage location, it contains NodeID.
In usual run:
If file is missing, or the current NodeID does not match the NodeID in the file - the node will crash.
If storage location is not writeable or readable or there is no expected structure - the node will crash.