Measure earnings without downtime

Node Operators
1

I noticed in this support article it says you have to take down your node to measure your earnings and suggests copying the data folder to prevent concurrent access corrupting the db. What I did to test it out without taking down the server was this:

  1. Created sandbox directory and go into it.
  2. made a shell script like this
#!/usr/bin/env bash

set -ex

rsync -avr --exclude="blobs" ../data .
python3 earnings.py data/
  1. Then I just run it with sudo and it usually works fine (sometimes you catch the db in a bad state and it fails). If if fails I just run it again and it works.

It’s also a bit faster since I leave out all the blobs stored in the data dir.

2

nobody every suggested to copy the data folder… only the databases.

1 Like
3

Why do you even copy the database? sqlite files are perfectly capable of being used by multiple programs at a time.

4

Except network storage protocols such as SMB and NFS. The docker for Windows and docker for Mac uses them unfortunately to mount folders to the container.

5

This is a nice idea, but on Linux like systems you really don’t have to copy at all.

6

Did you read the article I linked to?

Run the script from the data folder (it’s better to copy it to a different place and run this script from there to avoid the database corruption with a parallel access)

Copy “it” seems to refer to the data folder.

7

Because I generally don’t ever run scripts I haven’t personally written or have a high degree of trust in against production databases if I can help it. Copying is a perfectly normal safety precaution when running unknown scripts that may or may not cause database locking or God knows what else. Especially considering data corruption could cause your node to be disqualified.

If you guys aren’t worried about that and are fine with running against your database, go for it. I presented an easy, fast alternative that basically guarantees no script can break it.

1 Like
8

I did read it but skipped that part… I only saw the bottom part:

Note . Better to stop the storagenode and copy all the *.db files to a different place,

@Alexey might be good to correct this sentence in the docs https://support.storj.io/hc/en-us/articles/360029053531-Calculate-the-current-earnings-for-v3:

  1. Run the script from the data folder (it’s better to copy it to a different place

I don’t think you meant copying the whole data folder but that’s how you would understand that sentence.

9

May not be a bad idea to throw in that rsync command I wrote since it’ll avoid the blobs for you and get everything else rather than having to manually copy the *.db files.

10

I just take a snapshot then run the earnings script on the snapshot. Go ZFS! Here’s my wrapper script:

zfs snapshot tank/encrypted/storj/data@delete_me
zfs clone tank/encrypted/storj/data@delete_me tank/encrypted/storj/data_delete_me
python ./storj/storj_earnings/earnings.py /mnt/raid/encrypted/storj/data_delete_me/
zfs destroy tank/encrypted/storj/data_delete_me
zfs destroy tank/encrypted/storj/data@delete_me

Edit: It is fast too! 0m3.858s according to the time command.

1 Like
11

Very cool! ZFS is so nice. Does that mean you’re using an NFS share then?

I ended up just setting up ESXi with PCI pass through of my LSI card to FreeNAS, then mounting an iSCSI volume to boot my Storj VM off of. You may want to be careful if you’re running a sqlite database off of NFS though, apparently it can cause locking issues sometimes. It totally borked my Sonarr setup with SQLite when I ran it directly on NFS.

12

Hey thanks for the heads up about sqlite+NFS. I’m running my node via docker directly on my storage server so fortunately I don’t have to worry about it.

13

Done, please, check it

3 Likes
14

The command you wrote would copy the entire trash folder, which can be several gigabytes larger and has nothing to do with this. It would also copy the temp folder and anything else that ends up in that path. Just an example. The blobs folder used to be blob without an s. A change like that would have your script copying all stored data. You should copy what you specifically need, not exclude what you don’t need.

Looks better now, but if you don’t stop the node you need to also copy the *.db-wal and *.db-shm, otherwise you’re looking at old data.

2 Likes
15

Yeah I didn’t mean verbatim. Probably would be smart to exclude other stuff too or maybe write a little bash script to do it. I just don’t want to manually cp *.db and recreate the directories and stuff.