Can confirm. I’ve set refquota on a dataset that is used for storage, but not on the one used for databases. Then I set available space to 999TB in the config file. Egress stops correctly, when whatever buffer, (5GB?) of free space is remaining, regardless of what node thinks it’s supposed to be using. Dashboard shows total space correctly, matching the quota.
It’s a brilliant solution that guarantees the node won’t be able to overshoot the allocated space.
This also makes it easy to adjust space. I don’t need to restart the node.
This is still a bit scary if anything else is on the same file system or within the same quota, like logs, databases or order files. Even if a node is technically not accepting uploads, these other files may fill up the rest of the quota. Then node would start failing downloads or even simple bandwidth rollups.
It turns out, the Raspberry pi I was testing badger on is still running an older 32 bit version of Raspbian OS. The node was created back in 2019. I suspect that might be why I received the “mremap size mismatch” error when testing the new badger cache. I see that a 32bit OS is not within the current published system requirements. I will need to reinstall the OS at some point.
Then it’s a bug that needs to be fixed. Storj does offer 32bit binaries, there are plenty of 32 bit systems around.
It’s possible it’s badger bug who also neglects 32 bit systems. Then the feature needs to be disabled on 32 bit systems.
The real problem is I don’t things storj tests 32 bit binaries they produce in the first place ( I have reported 32-bit system related bug in the past too, and both bugs reproduce immediately). That too needs to be fixed.