What can I delete on storagenodes

Node Operators FAQ
,
1

On Linux/Docker nodes, maybe on Windows too (I don’t run any), at node ver. 1.120.4, these are all the main dirs and files in my storagenode location /mnt/hdd1/Storj:

  • main directory:
/Storj/ >
bin (dir)
Backups (dir)
Identity (dir)
orders (dir)
retain (dir)
storage (dir)
trust-cache.json
config.yaml
revocations.db
  • storage directory:
/Storj/storage/ >
blobs (dir)
filestatcache (dir)
hashstore (dir)
piece_expirations (dir)
temp (dir)
trash (dir)
storage-dir-verification
*.db
*.db-shm
*.db-wal

The Identity dir it’s user created. I created the identity files on a diferent machine and copied the entire dir. You can put it werever you want, but it’s a good practice to keep it on the node’s drive, in the storagenode location. One without the other it’s useless.

The Backups dir it’s also user created. In it I keep a copy of the Identity dir and storage-dir-verification file. If some fs problem or bad block hits the main files, I can recover them from here. You can put it on another drive too, your choise.

filestatcache is created only if you activate badger cache.

*.db-shm and *.db-wal are temporal files of the main db files and they should disappear when you stop the node, because they are flashed to main db-es. If they don’t, like it happened to me when I had db-es on USB drive, then you should reconsider your db-es location; maybe move them back to storage drive or on a SSD in local SATA port.

So, in case you have some problems with your node and you want to do a cleanup, you MUST stop the node first and then you can delete these:

  • filestatcache dir
  • piece_expirations dir
  • *.db, *.db-shm, *.db-wal
  • anything in temp older than 10 days.
  • anything in trash older than 10 days.

After this, you must run a successful startup-piece-scan, to recreat everything and hoppefuly show a nice dashboard with real data.

2

From my experience - I performed this when I had mysterious issues with one of my nodes and this resolved the issue.
Following is for Windows but I guess the same apply for any OS, you will know where your folders are located. You can freely delete following folders and files, and when I say freely, it means the node will work just fine and you will not loose money, but the consequences may be the Dashboard not showing any data for a couple of hours, Filewalker full run, etc. Obviously it required stopping the storagenode first.

  1. c:\Storj\app\ - app folder where you have your storagenode.exe: all subfolders can be deleted, as well as files: revocations.db, storagenode.log, storagenode.old.v1.117.8.exe and all storagenode.old.*.exe, storagenode-updater.log, storagenode-updater.old.exe, trust-cache.json
  2. c:\Storj\dtb\ - the path is defined in config.yaml as storage2.database-dir: ... - delete all files and subfolders, not the folder itself.
  3. d:\Storj\data\ your data folder, the path defined in config.yaml as storage.path: ... - delete content (not the folder itself) of d:\Storj\data\filestatcache\, d:\Storj\data\hashstore\, d:\Storj\data\temp\ - there should be nothing in temp anyway.
  4. And if you have serious need and willing to the some minor risk, you can delete content of d:\Storj\data\trash. In worst case, if you are unlucky, this may lower your Audit Score by a percent or so but if your node is screwed up and have nothing to lose…

Or from the other side - you need to keep only:

  1. in app folder keep: config.yaml, storagenode.exe, storagenode-updater.exe
  2. in database folder: nothing needed
  3. in data folder: keep everything in d:\Storj\data\blobs\, file storage-dir-verification, and remove content of all other folders but keep the folders themselves.
3

I believe the content of hashstore dir is a critical part of the new hashstore storing system, and if you loose that, you loose your node.

2 Likes
4

Possibly, I was talking about standard production node.

5

This one is the next generation analogue of blobs, so deleting it may lead to disqualification. I wouldn’t recommend to do so.