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.
Hello,
I just manage to move the DBs to the fastest storage I have. My expectation was to reduce the I/O of my USB attached STORJ disk. That’s not happened for now. The 14 TB disk is still on the heavy load. Did I miss somth?
Moving DBs to another disk will not reduce I/O on the HDD, this only helps DBs themself to have less locks.
To reduce I/O on the HDD you need to add RAM or SSD as a caching layer, if your filesystem/OS allows to do so.
I guess it’s Windows and also in the VM?
My system is on Orangepi ARM running on 2 GB of RAM ARMBIAN linux.
I can attach a fast SSD to it as a caching layer, but I didn’t find an instruction hot to do that. Can you please guide me with that?
Thank you
If you are doing something like mounted NFS storage – which you should not do and storj says it’s not supported and it’s a bad idea – then file locking can be a problem with the database and running the database in a separate location helps.
As @alpharabbit say - the best approach would be to migrate to hashstore, it will effectively reduce I/O on the HDD.
The other ways with using SSD as a cache layer related to using either ZFS or LVM. Since your system has only 2GB of RAM your only choice is LVM. But if you don’t have it initially, the conversion is pretty complicated and dangerous. The safe way (but very long) is to use LVM on a new disk, create PV, LV with SSD layer and migrate your current node to there.
The current state is your initial state to emulate a storagenode, but with only one file disk1.raw 1GiB in size. Here you need to stop and remove the storagenode container, but not in this test lab
Convert the disk with GPT to LVM on the fly
unmount the disk, because ext4 doesn’t allow to shrink it online or you can resize your disk using GPart or KDE Partition Manager to free-up 1.1GiB of the disk space, then create a PV on it, and they will do this automatically, but we will continue in the CLI:
$ sudo resize2fs /dev/loop2p1 1900M
resize2fs 1.47.0 (5-Feb-2023)
Resizing the filesystem on /dev/loop2p1 to 486400 (4k) blocks.
The filesystem on /dev/loop2p1 is now 486400 (4k) blocks long.
shrink the partition (note - the size should be +1MiB)
$ sudo parted /dev/loop2 resizepart 1 1901MiB
Warning: Shrinking a partition can cause data loss, are you sure you want to continue?
Yes/No? y
Information: You may need to update /etc/fstab.
(here we need to stop and remove the storagenode container and make a last rsync with a --delete option and run the container back with a new path /mnt/storj-new). The node is now running and online using the new storage location.
unmount the old location
$ sudo umount /mnt/storj
create a new PV
$ sudo pvcreate /dev/loop2p1
WARNING: ext4 signature detected on /dev/loop2p1 at offset 1080. Wipe it? [y/n]: y
Wiping ext4 signature on /dev/loop2p1.
Physical volume "/dev/loop2p1" successfully created.
extend vg0 with a new PV
$ sudo vgextend vg0 /dev/loop2p1
Volume group "vg0" successfully extended
forbid coming a new data to the second PV, all new data will go to the first PV
move the data from the second PV to a first one on the fly (the storagenode will be online). This operation can be resumed, if there would be an interruption, it’s pretty safe.
remove the second PV after all data has been moved to a first PV
$ sudo vgreduce vg0 /dev/loop2p2
Removed "/dev/loop2p2" from volume group "vg0"
$ sudo pvremove /dev/loop2p2
Labels on physical volume "/dev/loop2p2" successfully wiped.
remove the second partition and extend a first one
$ sudo parted /dev/loop2 rm 2
Information: You may need to update /etc/fstab.
$ sudo parted /dev/loop2 resizepart 1 100%
Information: You may need to update /etc/fstab.
$ sudo partprobe /dev/loop2
extend PV
$ sudo pvresize /dev/loop2p1
Physical volume "/dev/loop2p1" changed
1 physical volume(s) resized or updated / 0 physical volume(s) not resized
