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
/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
/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