0

My setup is an old (~2012) laptop + small SSD and a NAS with HDDs. I noticed that trying to sync Bitcoin Core (v0.18) on the NAS was slow, but on SSD was very fast. (Everything is connected via ethernet cables of ~3ft length, so can't be a network problem, can it?)

So I thought about syncing a pruned node, with manual pruning, and periodically backing up the data from /blocks and /chainstate of my datadir to the NAS, before executing the prune. My idea was to set up a node with the full chain once the sync was done.

The problem is it doesn't work. So if I run the node with datadir on the NAS, Bitcoin Core will just shut down. But if I remove the /blocks and /chainstate directories from the NAS, the IBD starts with no problems. (Aside from slow, that is.)

So my question is, can this trick be used? If so, how?

 

If it helps, my bitcoin.conf for the pruned node is

### bicoin.conf of pruned node
debug=0
daemon=1
server=1

prune=1

dbcache=4096

and the one for the full archivial node on NAS is

### bitcoin.conf of archivial node on NAS
debug=0
daemon=1
server=1

dbcache=4096
par=-1
listen=0

 

Edit: debug.log from last time I tried running the node on NAS (removed timestamps)

Bitcoin Core version v0.18.1.0-3b0422118 (release build)
InitParameterInteraction: parameter interaction: -listen=0 -> setting -upnp=0
InitParameterInteraction: parameter interaction: -listen=0 -> setting -discover=0
InitParameterInteraction: parameter interaction: -listen=0 -> setting -listenonion=0
Assuming ancestors of block 0000000000000000000f1c54590ee18d15ec70e68c8cd4cfbadb1b4f11697eee have valid signatures.
Setting nMinimumChainWork=0000000000000000000000000000000000000000051dc8b82f450202ecb3d471
Using the 'sse4(1way),sse41(4way)' SHA256 implementation
Default data directory /home/bitcoin/.bitcoin
Using data directory /home/bitcoin/.bitcoin
Config file: /home/bitcoin/.bitcoin/bitcoin.conf
Using at most 125 automatic connections (1024 file descriptors available)
Using 16 MiB out of 32/2 requested for signature cache, able to store 524288 elements
Using 16 MiB out of 32/2 requested for script execution cache, able to store 524288 elements
Using 3 threads for script verification
scheduler thread start
HTTP: creating work queue of depth 16
No rpcpassword set - using random cookie authentication.
Generated RPC authentication cookie /home/bitcoin/.bitcoin/.cookie
Using rpcauth authentication.
HTTP: starting 4 worker threads
Using wallet directory /home/bitcoin/.bitcoin
init message: Verifying wallet(s)...
Using BerkeleyDB version Berkeley DB 4.8.30: (April  9, 2010)
Using wallet /home/bitcoin/.bitcoin
BerkeleyEnvironment::Open: LogDir=/home/bitcoin/.bitcoin/database ErrorFile=/home/bitcoin/.bitcoin/db.log
init message: Loading banlist...
Cache configuration:
* Using 2.0 MiB for block index database
* Using 8.0 MiB for chain state database
* Using 4086.0 MiB for in-memory UTXO set (plus up to 286.1 MiB of unused mempool space)
init message: Loading block index...
Opening LevelDB in /home/bitcoin/.bitcoin/blocks/index
Opened LevelDB successfully
Using obfuscation key for /home/bitcoin/.bitcoin/blocks/index: 0000000000000000
LoadBlockIndexDB: last block file = 1818
LoadBlockIndexDB: last block file info: CBlockFileInfo(blocks=119, size=96043707, heights=598015...598157, time=2019-10-05...2019-10-06)
Checking all blk files are present...
LoadBlockIndexDB(): Block files have previously been pruned
Shutdown requested. Exiting.
Shutdown: In progress...
scheduler thread interrupt
Shutdown: done
5
  • What do you see in the debug.log file on the NAS when you start bitcoind after copying to it. – Pieter Wuille Dec 15 '19 at 1:26
  • Added debug.log details. – leilerg Dec 15 '19 at 3:14
  • It seems you've made your copy after some pruning already happened. – Pieter Wuille Dec 15 '19 at 3:23
  • This is odd... in my blocks dir I have blk00000.dat onwards and the corresponding revXXXXX.dat files. And in chainstate the files get pruned automatically, don't they? How can I tell? Or differently, what do I need to make it work? – leilerg Dec 15 '19 at 4:01
  • Hmm, that's surprising. – Pieter Wuille Dec 16 '19 at 1:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.