Yes, you can migrate (sort of) back to piecestore; just set all those lines to false, instead of true. Pieces will stop going in hashstore and be stored the classic way. And with the future deletes, the hashstore will be emptied in time. That’s what I did with one of my nodes, after migrating 2TB of data. Now it has 4TB stored, most of them in piecestore. It’s very quiet, with no compactions, and very performant. It took in like 1TB per month.
3 Likes
it’s just what i did too
it’s possible old nodes lossing storage because unpaid data deleted?
Old nodes with hashtore loss storage but new nodes with piecestore gained storage
I asked the team, since this thread is over flooded with piecestore/hashstore comparing, they didn’t look into it (as me too, unfortunately, I didn’t have a time until now).
1 Like
We now have it:
1 Like
Likely you are correct, the older nodes may keep the old unpaid data, and it’s deleted every time. So, maybe not the hashstore to blame.
At least on Select it showed a significant improvements in performance and effective resource usage on a “standard” servers without any special hardware requirements (we do not use a fresh new hardware there, it was there before, at least the majority as far as we know. So yes, we eat our own sentence about using of what’s exist and online).
set STORJ_HASHSTORE_TABLE_DEFAULT_KIND=mem and it’ll write out memtbls during compaction. That is all.
2 Likes
Can I enable hashstore during first storj node installation or still I have to edit this files manually?
My logic dictates that you first run setup, than start up the node to make those files appear, in order to change the settings and switch to hashstore, but maybe they are created at setup? I don’t realy know…
You still need to edit these files manually.