[solved] blocks folder of pruned node keeps growing

HCP

legendary

Activity: 2086

Merit: 4314

Quote from: darkv0rt3x on March 27, 2021, 05:52:41 AM

But I'm still not sure it's all good now because I've been told more than once that for a pruned node to get sync'ed, it takes like 2 or 3h. But not in my case.

Pruning (in general) doesn't really sync any faster or slower than when not pruning... It still has to download and verify everything like a "standard" node... the only real difference in the process is that it doesn't store all the block data.

So, expect it to take as long as it would if you were just syncing normally.

darkv0rt3x

hero member

Activity: 1176

Merit: 647

I rather die on my feet than to live on my knees

Quote from: LoyceV on March 27, 2021, 06:39:06 AM

Quote from: darkv0rt3x on March 27, 2021, 05:52:41 AM

I've been told more than once that for a pruned node to get sync'ed, it takes like 2 or 3h.

That's very optimistic

A pruned node still needs to download and verify about 350 GB of data.

Quote

But not in my case.
It's now almost 20h and it is still at 06/2019.

Is this normal or it should be way faster?

Depending on your other system specs, this seems normal. It should be done by tomorrow.

This is a RockPro64 board with 4Gb of RAM. It uses a Dual-core Cortex-A72 up to 2.0GHz CPU an a Quad-core Cortex-A53 up to 1.5GHz CPU.
But I think the main role in the process is at the capability of read/write of the storage drive which is pretty much the best we can get at an affordable price (the Samsung 970 Evo Plus NVMe M.2 drive).

Quote from: ?? on ??

Quote from: darkv0rt3x on March 27, 2021, 05:52:41 AM

But I'm still not sure it's all good now because I've been told more than once that for a pruned node to get sync'ed, it takes like 2 or 3h. But not in my case.
It's now almost 20h and it is still at 06/2019.

Is this normal or it should be way faster? I'm running this on a Samsung 970 Evo Plus NVMe M.2 drive.

That depends on your hardware, but obviously there's bottleneck. On blog 2020 Bitcoin Node Performance Tests, he uses Samsung 960 EVO 1TB M.2 SSD (similar to yours) with high-end hardware and managed to fully sync in 5 hours 41 minutes.

But IMO 20h to reach 06/2019 is quite fast since some people took days to weeks to fully sync Bitcoin node.

yeah, I guess my bottleneck now is on the CPU computing power.

LoyceV

legendary

Activity: 3290

Merit: 16489

Thick-Skinned Gang Leader and Golden Feather 2021

Quote from: darkv0rt3x on March 27, 2021, 05:52:41 AM

I've been told more than once that for a pruned node to get sync'ed, it takes like 2 or 3h.

That's very optimistic

A pruned node still needs to download and verify about 350 GB of data.

Quote

But not in my case.
It's now almost 20h and it is still at 06/2019.

Is this normal or it should be way faster?

Depending on your other system specs, this seems normal. It should be done by tomorrow.

darkv0rt3x

hero member

Activity: 1176

Merit: 647

I rather die on my feet than to live on my knees

I think I found the problem.

I can't have the prune=550 config line inside the [testnet] section. It must be out of it.
But I'm still not sure it's all good now because I've been told more than once that for a pruned node to get sync'ed, it takes like 2 or 3h. But not in my case.
It's now almost 20h and it is still at 06/2019.

Is this normal or it should be way faster? I'm running this on a Samsung 970 Evo Plus NVMe M.2 drive.

nc50lc

legendary

Activity: 2394

Merit: 5531

Self-proclaimed Genius

You can add -prune=550 as an additional start parameter instead.

For the bitcoin config issue, is it located in the default directory?
If not, try to put the entries in the default data directory's bitcoin.conf file whether you're using a custom datadir or not.

darkv0rt3x

hero member

Activity: 1176

Merit: 647

I rather die on my feet than to live on my knees

Hello,

I've just installed the pre-compiled binaries of bitcoin core into a RockPro64 board and with the following config file, the blocks folder keeps growing. It is now with 163Gb and it shouldn't,
I think. What am I doing wrong here:

Code:

dbcache=2048
par=1 -daemon
server=1
rpcauth=bitcoin:[REPLACED]
rpcallowip=127.0.0.1
rpcport=8332
maxtxfee=0.00002000
mintxfee=0.00000002
network=testnet
 
# Options only for testnet
[testnet]
debug=net
debug=tor
debuglogfile=/media/Storage/blockchain/debug.log
addresstype=bech32
changetype=bech32
listen=1
prune=550

Just a side note. When I started this node, I forgot to delete the line 'txindex=1' and only noticed that when blocks folder was already 60Gb big. Then, I removed that line from the config file and restarted the daemon, but the blocks folder kept going and still is. What I need to do to force the daemon to use the config line 'prune=550' and stop blocks folder from growing?

Topic: [solved] blocks folder of pruned node keeps growing (Read 111 times)