We predominantly use hashtbl, but have started using memtbl more in cases where the RAM is available. Both are very fast. memtbl is only faster if the RAM is available for it, but if there isn’t enough RAM, then hashtbl is faster.
Ah yes, thank you for the context. It looks like since none of our code used it, it was removed in a refactor without causing anything to trip. It should be straightforward to add back. In fact, the telemetry data your node maintains does actually report satellite usage, e.g.:
$ curl -s yournode.local:5999/mon/stats | grep -E ^satellite_usage
satellite_usage,satellite=12L9ZFwhzVpuEKMUNUqkaTLGzwY9G24tbiigLiXpmZWKwmcNDDs,scope=storj.io/storj/storagenode/nodestats used_bytes=<BYTES HERE>
satellite_usage,satellite=1wFTAgs9DP5RSnCqKV1eLf6N9wtk4EAtmN5DpSxcs8EjT69tGE,scope=storj.io/storj/storagenode/nodestats used_bytes=<BYTES HERE>
...
The hashstore codepaths just ignore it. I don’t think you need to do anything. Hashstore makes the filestatcache unnecessary.
Good question - for right now, STORJ_HASHSTORE_TABLE_DEFAULT_KIND is specifically an environment variable. With this rollout I anticipate a lot more interest in changing configurations than we have had, so we will pursue exposing this configuration in the config file too. You should be able to set system and user environment settings in your Windows System Settings control panel.
Definitely! Perhaps someone on the forum will beat us to it, but there is be a config setting (that can be either environment variable or config file) that specifies where the hashtable metadata (the tables themselves) reside. Either --hashstore.table-path=/path/to/your/ssd/table/folder or STORJ_HASHSTORE_TABLE_PATH=/path or in the config file hashstore.table-path: "/path". There is a similar config option for the logs path (hashstore.logs-path)