Open fanquake opened 1 week ago
mzumsande
commented
1 week ago That's strange. I just tried to reproduce syncing this snapshot with current master (39219fe145e5e6e6f079b591e3f4b5fea8e71804) and didn't experience this (although I do get get similar "Cache size" log messages).
Are you syncing from random peers or do you have some local setup?
pablomartin4btc
commented
1 week ago @fanquake what getchaintips returns?
fanquake
commented
1 week ago Are you syncing from random peers or do you have some local setup?
This was syncing from random peers.
maflcko
commented
1 week ago Are all random peers limited peers, which wouldn't serve historic blocks?
fanquake
commented
1 week ago Are all random peers limited peers,
I don't think so, given some peers would have to be serving (historic) blocks for the background chain to continue syncing? I've now restarted this node, and the behaviour hasn't persisted, both chains are currently syncing. If this gets to the point that the snapshot load completes, I'll close this.
mzumsande
commented
1 week ago It also seems like the cache resizing has not worked correctly?
Just wanted to mention that I think that the cache resize worked as expected here:
After the snaphot is loaded, the cache of the background chainstate is set to a lower value:
resized coinstip cache to 22.0 MiB
because loading from the snapshot chainstate is prioritized.
Then, the cache for the background chainstate is frequently flushed because blocks are downloaded to it and it runs full quickly. These are the
Cache size (23160048) exceeds total space (23068672) messages.
So the problem is only that no progress is made towards the snapshot chain, with the larger cache, for an unknown reason (which I still couldn't replicate in multiple runs), but not the cache resizing.
fjahr
commented
4 days ago If this gets to the point that the snapshot load completes, I'll close this.
I don't think we have to close this right away, we can keep this open for a few more weeks to see if this issue occurs for other users. Having an open issue already makes it easier for people to engage. But did loading of the snapshot actually complete eventually @fanquake ?
I am currently looking into the obfuscation key because I find it suspicious that it changes for chainstate_snapshot. From my understanding that shouldn't happen. Note below how @fanquake 's obfuscation key changes from 3cedc53d26d5e869 to d5cf473cf236f9ee while mine stays at a92b5f447f34b873. So far I couldn't figure what caused this though. @fanquake could you share the full logs for the whole sync so I can track down further differences that might give a hint for changes (privately if you prefer). For example, I am curious if there were any abnormal interactions with the snaphot chainstate.
FYI, comparison between my test run and @fanquake 's log excerpts:
fanquake
commented
2 days ago But did loading of the snapshot actually complete eventually
It did. I haven't had time to (re-)test anything here further. I don't think I have the full logs to share any more, but I will try and recreate them.
Testing
-loadtxoutseton node running master (39219fe145e5), with Sjors snapshot (height 840000). After it finished validating the snapshot, it (so far), has just not started syncing the snapshot chain, only the background chain is progressing. It also seems like the cache resizing has not worked correctly?./build/src/bitcoin-cli getchainstates