Ok thanks ! No worry, I just wanted to figure how it works, because I’ve actually a nice unused Samsung 850 Pro on my system (since it was my old system drive), and I check the SMART and Samsung Magician for the wearing, it’s a pretty solid SSD so far, still probably for years, because I don’t think the dbs writing should be so intense compared to my previous workload usage. But, in the past, when I mapped the dbs files directly, obviously, the others db-wal were still created after the run in the default path, then there were changes with the db structures (splitting db and so on), but the node was notably faster for the orders sending and the first run. Still, it’s still works nicely on the hard drives except the database temporarly locked when the node starts/restarts, but I know its a normal behavior when it loads back the data the first time, so yes, I could just continue like that. But I wanted be sure to use that feature properly if ever I use it.
I don’t want be your ennemy because of this mistake, I appreciate you into the community Bright. I fixed myself the procedure I took for example earlier to avoid confusions for other SNOs. If we meet, I could manually press an espresso for you, since I know you’re drinking coffee the morning. Cheers! <3
No worries, you won’t make an enemy out of me. I just want you to be fully informed about the risks. The fact is the network can deal with the loss of your node should the worst happen. But I’d rather prevent that for your sake. You seem to be doing your homework though, so you’re the only one who can determine whether you feel secure enough to make this move. I’d make damn sure I actually need it though. The only reason I’m using it is because I have a device I’m certain wouldn’t be able to keep up with the db’s on the same location. It still might not even with the db’s elsewhere. But then I’m not risking my main node. Just testing out a secondary node on this device to see if it can survive.
I’d take you up on that espresso though should we ever meet! And I’ll buy a round of beers later in the day.
I finally got some new SSDs mirrored in the NAS. Did this on ubuntu. Your CP command wouldn’t work quite right for me.
sudo docker stop -t 300 storagenode
sudo docker rm storagenode
sudo su
CD /mnt/iscsi/StorjV3/storage
cp *.db /mnt/iscsiSSD/StorjDB
exit
add to config.yaml: storage2.database-dir: “/app/db”
add to docker start options:
–mount type=bind,source="/mnt/iscsiSSD/StorjDB",target=/app/db
Remove DB files from OLD path!
U copy files from dir in witch u are. But input path works too. Strange why it not work for u.
Maybe u did it literally. But need cp /current-path-db/*.db /new-path-db/ without masked files at output path.
I agree. Didn’t dig too much before switching. It said the source path didn’t exist /current-path-db/*.db . I think it doesn’t like *.db being so close to the source path. Maybe it needed a space, but i backed out and did something i was more familiar with since these files are so sensitive.
I just came here to say that this still works as of v1.69.2
I am not running it under a Docker instance but rather as a Windows service.
I did have an issue where the Storage Node service wouldn’t start if my DB path was in a root directory in the root of C: but id did work if it was two directories deep from C:
i.e.
C:\StorjDB → did not work
C:\Storj\db → did work
Perhaps the issue is related to permissions, especially if you specified path as C:\, i.e. databases should be placed in the root - there are special system folders and they are not available for the service, resulting permissions denied issue and inability to access files in the root.
It’s always recommended to create a folder for data (or databases in this case) instead of using the root of the disk.
