So im confused on hashtable piece. I have 256GB of RAM, so I want to use memtable/mmap, do I need a directory on an SSD as well?
If someone could help me sort out these docker config options that would be great.
Do I need to set --hashstore.table-path if I want to use mmap?
Hello @nitrobass24,
Welcome back!
No, you do not need to. Even for a non-memtable type.
I have enabled chore migration on my nodes, and I am now occasionally getting errors like this:
rmat version 1: too small for header (0 < 512)", "errorVerbose": "opening the old reader: pieces error: invalid piece file for storage format version 1: too small for header (0 < 512)\n\tstorj.io/storj/storagenode/piecemigrate.(*Chore).migrateOne:335\n\tstorj.io/storj/storagenode/piecemigrate.(*Chore).processQueue:277\n\tstorj.io/storj/storagenode/piecemigrate.(*Chore).Run.func2:184\n\tstorj.io/common/errs2.(*Group).Go.func1:23",
Any ideas?
This piece is corrupted, you may wait until migration of other pieces will be finished and remove the broken pieces after.
Do the pieces automatically get removed? Or will I have to manually remove them?
BTW, once turning on the hashstore migration (regardless of the mode), all new pieces are stored using hashstore, right? Iâm slightly confused - sorry 
There is passive migration and active migration. One puts new pieces in hashtore, the other MOVES stored pieces from piecestore to hashstore. If you enabled both, youâre good.
Nothing to do with the type of hashtore you are using⌠hashtable, memtable, etc.
I tried active migration few weeks back on one node. I see 100+ read iops on the node HDD all the time now. Migration is long finished. Is this expected? Hashstore tables are on SSDâŚ
Wasnât there an issue with ext4 and folders with large number of deleted files? You can delete all content in blobs folder but not the folder itself. Maybe it helps.
Also you can set migrate_chore to false once migration is finished.
Well, I have both the .migrate and .migrate_chore files (migrate_chore has true, migrate has {"PassiveMigrate":true,"WriteToNew":true,"ReadNewFirst":true,"TTLToNew":true}). In my logs though, it still says piecestore piece downloaded. This suggests to me that they arenât being saved to hashstore - is this the case?
I donât watch logs, donât know. Did you restarted the node?
In fact hashstore is implemented as an alternative storage backend for piecestore. Logging for upload/download happens in the common part and hasnât changed.
Do I actually need to do this?
Wonât think just eventually happen automatically?
It will happen automatically: Storj will slowly push it from the satellites. But some people go looking for trouble and want to try it early 
You want also enable the active migration
Because you showed only the passive one, with a passive migration pieces would be moved to hashstore when requested, otherwise they will stay in piecestore.
They also discover bugs early and help impruve the code before everyone could be affected.
For anyone on Linux and want to track progress of where your hashstore migration is at
sudo strace -p your_storagenode_pid -f -e trace=file -tt 2>&1 | grep blob
To get your storagenode pid, run
sudo docker top storagenode
Find the one that has the storagenode run on it.
Another way to do the same (perhaps easier for some):
cd /path/to/storj/node-data
fatrace -ct
Never seen that command before, looks more simple and easier to use. Will be adding it to my list of commands
Please do not forget to add your methods to the first post - itâs a wiki.
I added two these already.
There were multiple questions about compaction / related config values.
In general, I would say: you donât need to touch them. Defaults should work most of the time.
But if you are interested about the beauty of internals, and manual tuning, I created a video to explain them.
(Or at least an attempt to explain them )
Fortunately itâs already quite long, even if I didnât touch a few topicsâŚ
--hashstore.compaction.alive-fraction float
--hashstore.compaction.probability-power float
--hashstore.compaction.rewrite-multiple float