ldeffenb
commented
2 months ago I added additional logging to the "reserve radius" logs and see this:
"time"="2024-04-30 17:17:15.653076" "level"="info" "logger"="node/storer" "msg"="reserve radius decrease" "radius"=10 "count"=2068699 "threshold"=2097152
"time"="2024-04-30 17:21:01.485788" "level"="info" "logger"="node/storer" "msg"="reserve radius increase" "radius"=11 "evicted"=0 "target"=1
"time"="2024-04-30 17:47:15.706153" "level"="info" "logger"="node/storer" "msg"="reserve radius decrease" "radius"=10 "count"=2069049 "threshold"=2097152
"time"="2024-04-30 17:54:05.898721" "level"="info" "logger"="node/storer" "msg"="reserve radius increase" "radius"=11 "evicted"=3 "target"=38Now I think I need to get and log the current "reserve in radius" or whatever is triggering the failed eviction pass that results in the radius going back to 11. And possibly what eviction actually caused it to drop back to 10, although I might actually have that log in place already.
Context
2.0.1 mainnet swarm
Summary
When the reserve capacity was exceeded, the storage radius was expected to transition from 10 to 11. Unfortunately, some of my nodes went into an oscillation between radius 10 and 11 and have yet to completely settle down.
Expected behavior
Transition should have gone once and stayed at the new level until a substantial change in the swarm reserve population happens.
Actual behavior
Storage radius bounces up and down even though the swarm chunk population is on a steady increase. From my nodes' logs:
0x300...
0xa00...
0xe7e...
Steps to reproduce
Just find the right neighborhood and check your logs for "reserve radius".
Possible solution
No idea at this time, but apparently the triggers for going up and going down are not very stable when at certain levels of reserve population.
Consider the ramifications of an increased reserve radius causing 1/2 of the chunks to be evicted and then the reserve radius going back down. Those evicted chunks need to be recovered from somewhere, but the pullsync intervals are not reset, so the new radius 10 peers are not re-pulled causing the reserve to be incomplete until it transitions again back to 11. As much as I hate the load on the swarm when pullsync intervals are reset, it definitely seems necessary when the reserve radius decreases. But then, please don't fix that until the cause of the radius oscillation is determined and corrected!