main completed, pruned 112GB with 230 lmdb resizes, all good. testnet / stagenet also

<ofrnxmr> How big is the lmdb map?

<ofrnxmr> set_log 2

<ofrnxmr> pop_blocks 500

<ofrnxmr> Then db map logs should print showing the map size and utilization

<sneedlewoods_xmr:matrix.org> @ofrnxmr: for me on stagenet:

<sneedlewoods_xmr:matrix.org> mrelay.p2pool.observer/p/-8Hc_qgLQzVBM19T/1.txt (code snippet, 4 lines)

<ofrnxmr> Ok, seems its not resizing as often as before. Used to resize when at like 10%

<ofrnxmr> That logic is/was all screwy (how much it grows, when to trigger it, etc). I think it might be fixed now (judging by your log)

<plowsof:matrix.org> ofrnxmr privatebin.net/?cf97c82557512b4d#Eu…wPZfUB8HwGXRhdK9bVTuaRastP9B2XWsgVe

<ofrnxmr> Oh yeah, i still think that 500mb resize needs to be bigger but looks fixed from blowing up the map for no reason

<ofrnxmr> Caused segfaults on arm 🧠

<ofrnxmr> It easentially never did a threshold resize before. Would just resize prematurely by huge amounts. Like, db = 3gb, resize to 300gb.db 4gb, resize to 900g

I'll check if the amount of resizes can be reduced

in a follow up PR

<jpk68:matrix.org> monero-project/monero #11248#discussion_r3961856813

<jpk68:matrix.org> ^ @jberman:monero.social Could you confirm this, please?

<jberman> > <tevador> Can someone explain why this is needed and if it needs to be done for every additional block as well? github.com/seraphis-migration/moner…ts/core_tests/fcmp_pp.cpp#L446-L458

<jberman> the block header needs the correct tree root set because the block gets consensus validated when it's added to the chain in chaingen.h L643 's call to handle_incoming_block. block headers don't include the tree root until the FCMP++ fork, so that's why it has to be done there and not before

<jberman> @jpk68:matrix.org: confirming with kayaba

I understood that part, but I thought the tree root calculation could be done in some way that doesn't require adding 10 blank blocks and then popping them.

If this is the only way, do I understand correctly that if I need to add say additional 2000 blocks in the test, I need to repeat the process (including popping the dummy blocks) for each block?

<jberman> It can, that hack there seemed the easiest way to get the tree root calculation in that specific spot

<jberman> want to send me your test? I think I'd need a bit more info

<jberman> if you know how the chain is going to look for the additional 2k blocks, you should be able to sync the tree correctly via the tree_cache all the way up until the tip and collect expected tree roots while iterating. Then for the last 9 blocks, you sync empty blocks and can collect tree roots while iterating there, that way a [... too long, see mrelay.p2pool.observer/e/99CEh6kLaWpjRTZp ]

<jberman> so you'd only need to do that hack thing once, just need to move it to the back

generator.construct_block_manually requires the tree root as an argument, so I can't just create 2000 blocks and then calculate the roots at the end, can I?

<jberman> no each FCMP++ block needs the correct FCMP++ tree root attached to it as it's added. If you know the outputs that will be in each block, then you can use the tree_cache to add them. You'd also want to manually construct the miner tx you're adding to each block in that case too, since construct_block_manually defaults to constructing it internally

<jberman> the PoW hash of block n includes the tree root of block n+9 essentially, so you can't construct the blocks completely before calculating tree roots

<jberman> here these docs might help / would show what the issue was that koe pointed out in the PR too: github.com/j-berman/monero/blob/e59…r-insertion-to-the-tree-upon-unlock