This one downloads the entire blockchain before pruning and destroys my vps, debug sees my 25gb limit as usual but it just continues. I can’t finish but it does hit 30gb before killing my vps.
http://builds.jonasschnelli.ch/nightlybuilds/2015-05-17/bitcoin-0.10.99-linux64.tar.gz
This one works correctly but is getting old
http://luke.dashjr.org/programs/bitcoin/files/bitcoind/misc/0.10.x/0.10.0rc3.autoprune/
-prune=-target did you set?
Bitcoin.conf prune=25000
I deleted the debug, I can try again if you think it should be working and it’s on my end.
It had
Autoprune configured to use less than 25000MiB on disk for block files
I still have the issue. I tried the latest snapshot.
Xxx
-debug=prune and upload the debug.log again?
Xxx
@laanwj i think this should get reopened.
It looks after a real issue:
Found the following in the logs (partial output of | grep prune):
02015-05-28 01:13:12 Prune: target=2500MiB actual=2462MiB diff=37MiB max_prune_height=197394 removed 0 blk/rev pairs
12015-05-28 01:13:14 Prune: target=2500MiB actual=2463MiB diff=36MiB max_prune_height=197504 removed 0 blk/rev pairs
22015-05-28 01:13:16 Prune: target=2500MiB actual=2470MiB diff=29MiB max_prune_height=197587 removed 0 blk/rev pairs
32015-05-28 01:13:16 Prune: target=2500MiB actual=2471MiB diff=28MiB max_prune_height=197593 removed 0 blk/rev pairs
42015-05-28 01:13:19 Prune: target=2500MiB actual=2486MiB diff=13MiB max_prune_height=197687 removed 0 blk/rev pairs
52015-05-28 01:13:19 Prune: target=2500MiB actual=2487MiB diff=12MiB max_prune_height=197688 removed 0 blk/rev pairs
62015-05-28 01:13:21 Prune: target=2500MiB actual=2503MiB diff=-3MiB max_prune_height=197699 removed 0 blk/rev pairs
72015-05-28 01:13:23 Prune: target=2500MiB actual=2520MiB diff=-20MiB max_prune_height=197744 removed 0 blk/rev pairs
82015-05-28 01:13:24 Prune: target=2500MiB actual=2526MiB diff=-26MiB max_prune_height=197788 removed 0 blk/rev pairs
92015-05-28 01:13:26 Prune: target=2500MiB actual=2527MiB diff=-27MiB max_prune_height=197876 removed 0 blk/rev pairs
102015-05-28 01:13:28 Prune: target=2500MiB actual=2530MiB diff=-30MiB max_prune_height=197967 removed 0 blk/rev pairs
112015-05-28 01:13:29 Prune: target=2500MiB actual=2532MiB diff=-32MiB max_prune_height=198042 removed 0 blk/rev pairs
@BitpopCoin Thanks for reporting this; I think I see the problem.
The pruning code enforces a requirement that the block files it keeps be contiguous, so that blockfile N will only be considered for pruning if blockfiles 0, …, N-1 were already pruned.
There is also a requirement that no block file will be pruned if there’s a block in the file with a height that is too close to the height of the tip. What appears to be happening here is that some peer likely inv’ed you a block at the tip while you were syncing (this is normal behavior); that block was stored in block file 5, and since its height is so large, it effectively stops pruning from taking place. From the debug.log:
2015-05-28 01:03:59 Leaving block file 5: CBlockFileInfo(blocks=7446, size=134174305, heights=148758...358316, time=2011-10-10...2015-05-28)
For what it’s worth, if the node were able to fully sync, I believe eventually the pruning targets would be respected again. This is certainly undesirable behavior though.
I think the best fix may be to relax the restriction that files be contiguous, which will complicate the logic slightly but seems likely to be worth it to avoid this outcome.
For what it’s worth, I’ve tried it many times. Last few times I’ve used 2.5 gb to speed things up. But I’ve originally used 25gb and it continues past 30gb breaking my droplet.
I think pruning will be used for limited disks and going over at all will break things. Can you add a quit for now? So when I do test I don’t have to spend an extra hour imaging the machine and restoring because the disk filled up and other things could have broke.
I run many nodes and upgrading will double my costs so I need pruning. I was going to move to vultr large storage but they don’t have imaging. Thanks guys.
Yes the relay node is connected.
addnode=public.us-west.relay.mattcorallo.com:8335
Good. That makes sense. I was wondering how a failure like this would have slipped through all the testing that has taken place thus far. There is definitely a bug here and there are a few routes for fixing it with varying levels of risk. There will be a patch forthcoming.
In the meantime, if you want to test pruning, disable the relay node during initial sync (and catchup syncs if your nodes go offline, or just altogether). It’s a difficult to trigger corner case if the relay node isn’t involved.
Thanks for reporting!
I was trying to think of anything odd about my node but I kept only thinking about the permissions. Another Bitcoin created .bitcoin but it ran as root and could write so I ignored the permissions issue, which was correct but I forgot I was using the relay network.
I’ll wait to try it again until a possible patch so let me know and I’ll test. I went back to Luke’s version but it’s getting old. Thanks.
Labels
Bug