ldeffenb

I should also mention that in my observations, when the depth of a node drops significantly, the puller gets over-activate thinking that it needs to pull a lot more chunks...

Would this happen if the content was pinned or otherwise still present in the uploading node?

I suspect the issue results from the way in which the website-index-document is resolved and retrieved. IIRC, it doesn't redirect to the referenced document, but attempts to resolve it directly...

Is there a possible oscillation here? I have one batch that just unreserved 3,579,137 chunks in my reserve. Since the reserve capacity is just under 5,000,000 chunks, that means that...

  And headed to yet another Unreserve eviction when Storage Radius goes to 4, hopefully later today or tomorrow.

And a new behavior. Any idea why the Storage Radius incremented twice in quick succession? I'll be providing logs for this later today. ``` time="2022-06-28T18:18:12+02:00" level=debug msg="batchstore: Unreserve callback batch...

 

bee version - 1.6.2-684a7384-dirty Dirty is due to additional pin counter logging, pinning and stewardship do not traverse manifests, increased kademlia connection limits /reservestate: { "radius": 11, "storageRadius": 5, "commitment":...

I've worked around this issue on my own major pinning node by hacking the code so that any API-based pins (from uploading and explicit pinning) increment the pin counter by...

When you re-pin an existing pin from the API, nothing actually happens in the bee node. It just returns success. But if chunks have been unpinned below that reference, possibly...