5

I would like to keep the latest 512 MB of blocks on my SSD (using pruning?) and the rest of the blockchain on an external non-SSD hard-drive. Is there a way to do this already, or do I need to write a script to accomplish this?

9
  • Are you using Bitcoin Core or some other client? Please add an appropriate tag. Commented Jan 23, 2017 at 21:06
  • 1
    Note that you might be able to achieve a similiar performance gain by putting all the blocks on the external hard drive (e.g. by making .bitcoin/blocks a symlink) and leaving the chainstate and other heavily-accessed databases on the SSD. Commented Jan 23, 2017 at 21:09
  • @NateEldredge Yes, Core. I've added that tag.
    – Geremia
    Commented Jan 24, 2017 at 2:11
  • 1
    I see. But I would not be surprised if you get fairly frequent requests for old blocks, from nodes trying to sync for the first time. Bitcoin Core would try to satisfy those requests and spin up the external drive. So depending on your timeout settings, I expect you will either be running that drive a large fraction of the time, or spinning it up and down a lot (not good for its lifespan). Commented Jan 24, 2017 at 2:16
  • 1
    you can remove the block serving service flag I think so that peers don't ask for historical blocks from you.
    – rny
    Commented Jan 26, 2017 at 9:58

4 Answers 4

2

Blocks are not accessed under normal operation, except: When a peer fetches one (and the most recent block is usually served out of an in memory cache), when there is a reorginization that must undo the effect of a block (which is pretty rare), or when you use an RPC to look up a historic block.

With that in mind, perhaps you can just put your blocks directory on the other disk.

If you set your node to be pruned but set the pruned amount much larger than the amount of block data, you will avoid peers fetching large numbers of old blocks from you (but still keep the data around).

If you found high disk accesses while in this configuration, I think thats something that the project would like to fix.

0

You could have two datadirs, one locally and one on the external hard drive where, every so often, you connect the external hard drive and start Bitcoin Core to use that as a datadir and sync it up. The local one could be pruned.

However if you wanted to have most blocks stored on the external hard drive and have Bitcoin Core automatically move them there and then be able to handle when it can't find those blocks, then that is not possible.

0

If you are already synced, you could call a simple script using blocknotify=script.sh in your bitcoin.conf to check for a higher numbered block file, and if one is found, move the lowest one out and the newest one in.

But a better way would probably be doing this at the block level with some fs/raid abstraction, or an inotify watcher if you have to do it at the file level.

2
  • 1
    I don't think this will work, as bitcoind may try to access the file afterwards. Even if you replace it with a symlink, it may be accessed in between deleting the old file and creating the link. Commented Oct 31, 2017 at 6:37
  • Yeah, you're probably right. I would just raid the ssd & hdd together, but if that's not possible and you have to do it by moving blk.dat files around, probably the safest bet is to (1) watch the blocks directory for new files with inotify; (2) stop the bitcoind service, (3) move the newest file to the ssd, (4) move the oldest file on the ssd to the hdd, (5) resymlink those two files to blocks, (6) restart bitcoind.
    – Luke Mlsna
    Commented Oct 31, 2017 at 6:45
0

https://statoshi.info/dashboard/db/unspent-transaction-output-set

the serialized UXTO set is 4GB as of April 2020.

You can put everything in the RAM and Hardisk. SSD has a limited life span especially if you have excessive write operation.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.