07:03:28 main completed, pruned 112GB with 230 lmdb resizes, all good. testnet / stagenet also 08:01:51 How big is the lmdb map? 08:02:28 set_log 2 08:02:28 pop_blocks 500 08:03:02 Then db map logs should print showing the map size and utilization 13:24:58 @ofrnxmr: for me on stagenet: 13:24:58 https://mrelay.p2pool.observer/p/-8Hc_qgLQzVBM19T/1.txt (code snippet, 4 lines) 13:26:09 Ok, seems its not resizing as often as before. Used to resize when at like 10% 13:27:39 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) 15:13:53 ofrnxmr https://privatebin.net/?cf97c82557512b4d#Eu82DFPn4wPZfUB8HwGXRhdK9bVTuaRastP9B2XWsgVe 15:20:07 Oh yeah, i still think that 500mb resize needs to be bigger but looks fixed from blowing up the map for no reason 15:20:17 Caused segfaults on arm 🧠 15:21:39 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 16:42:29 I'll check if the amount of resizes can be reduced 16:42:47 in a follow up PR 17:28:18 https://github.com/monero-project/monero/pull/11248#discussion_r3961856813 17:28:38 ^ @jberman:monero.social Could you confirm this, please? 18:00:42 > Can someone explain why this is needed and if it needs to be done for every additional block as well? https://github.com/seraphis-migration/monero/blob/b7b4e5790a52a24f3d5cd0aca8b2b2ec50cfe855/tests/core_tests/fcmp_pp.cpp#L446-L458 18:00:42 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 18:01:01 @jpk68:matrix.org: confirming with kayaba 18:04:21 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. 18:05:24 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? 18:05:44 It can, that hack there seemed the easiest way to get the tree root calculation in that specific spot 18:06:56 want to send me your test? I think I'd need a bit more info 18:15:32 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 https://mrelay.p2pool.observer/e/99CEh6kLaWpjRTZp ] 18:16:47 so you'd only need to do that hack thing once, just need to move it to the back 18:20:42 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? 18:38:06 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 18:44:32 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 18:47:36 here these docs might help / would show what the issue was that koe pointed out in the PR too: https://github.com/j-berman/monero/blob/e593906a4764ca8480f1ea4110bda87d09b5b78f/docs/FCMP%2B%2B_INTEGRATION.md#2i-curve-trees-merkle-tree-preparing-locked-outputs-for-insertion-to-the-tree-upon-unlock