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

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

<p>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).</p>

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

CC BY-SA 4.0
2018-07-23T12:27:32.660Z
2018-07-23T12:27:32.660Z
G. Maxwell
<p><a href="https://statoshi.info/dashboard/db/unspent-transaction-output-set" rel="nofollow noreferrer">https://statoshi.info/dashboard/db/unspent-transaction-output-set</a></p>

<p>the serialized UXTO set is 4GB as of April 2020.</p>

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

CC BY-SA 4.0
2020-04-15T08:48:24.647Z
2020-04-15T09:34:17.093Z
2020-04-15T09:34:17.093Z
Cisco Mmu
<p>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.</p>

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

CC BY-SA 3.0
2017-10-23T02:24:38.963Z
2017-10-23T02:24:38.963Z
Ava Chow
<p>If you are already synced, you could call a simple script using <code>blocknotify=script.sh</code> in your <code>bitcoin.conf</code> to check for a higher numbered block file, and if one is found, move the lowest one out and the newest one in.</p>

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

CC BY-SA 3.0
2017-10-31T06:37:23.483Z
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.
Pieter Wuille
CC BY-SA 3.0
2017-10-31T06:45:35.933Z
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
CC BY-SA 3.0
2017-10-31T04:31:51.517Z
2017-10-31T04:31:51.517Z
Luke Mlsna
<p>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?</p>

CC BY-SA 3.0
2017-01-23T21:06:32.693Z
Are you using Bitcoin Core or some other client?  Please add an appropriate tag.
Nate Eldredge
CC BY-SA 3.0
2017-01-23T21:09:18.043Z
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.
Nate Eldredge
CC BY-SA 3.0
2017-01-24T02:11:35.340Z
@NateEldredge Yes, Core. I've added that tag.
Geremia
CC BY-SA 3.0
2017-01-24T02:13:06.050Z
@NateEldredge Yes, performance-wise that would be good, but I don't want the external HD running constantly, as it would need to be if the latest blocks were stored on it. (I'm on a laptop, so there are energy limitations.)
Geremia
CC BY-SA 3.0
2017-01-24T02:16:32.620Z
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).
Nate Eldredge
CC BY-SA 3.0
2017-01-24T15:37:00.670Z
@NateEldredge Yeah, that's what I was wondering about: what percentage of nodes, on average, would be requesting old blocks anyways
Geremia
CC BY-SA 3.0
2017-01-26T09:58:01.667Z
you can remove the block serving service flag I think so that peers don't ask for historical blocks from you.
rny
CC BY-SA 3.0
2017-10-31T06:47:54.077Z
Or just set maxuploadtarget really low.
Luke Mlsna
CC BY-SA 3.0
2017-12-30T22:55:48.993Z
I wonder if running two instances of bitcoind would work, one with full blocks, the other pruned, and allow the full block instance to only serve to the pruned one.
Bobbi Bennett
<bitcoin-core><storage><energy-consumption><pruning>
Keeping old blocks on an external hard drive and latest blocks on an SSD
Geremia
# Keeping old blocks on an external hard drive and latest blocks on an SSD

(Asked by: username_0 on 2017-01-23)

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?

**Tags:** bitcoin-core, storage, energy-consumption, pruning

> **Comments:**
> **username_1**: Are you using Bitcoin Core or some other client?  Please add an appropriate tag.  
> **username_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.  
> **username_0**: @username_1 Yes, Core. I've added that tag.  
> **username_0**: @username_1 Yes, performance-wise that would be good, but I don't want the external HD running constantly, as it would need to be if the latest blocks were stored on it. (I'm on a laptop, so there are energy limitations.)  
> **username_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).  
> **username_0**: @username_1 Yeah, that's what I was wondering about: what percentage of nodes, on average, would be requesting old blocks anyways  
> **username_2**: you can remove the block serving service flag I think so that peers don't ask for historical blocks from you.  
> **username_3**: Or just set maxuploadtarget really low.  
> **username_4**: I wonder if running two instances of bitcoind would work, one with full blocks, the other pruned, and allow the full block instance to only serve to the pruned one.  

---

## 4 answers

### Answer by username_5 on 2018-07-23. Score: 2 | Accepted answer

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.


---

### Answer by username_6 on 2020-04-15. Score: 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.


---

### Answer by username_7 on 2017-10-23. Score: 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.


---

### Answer by username_3 on 2017-10-31. Score: 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.

> **Comments:**
> **username_8**: 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.  
> **username_3**: 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.  

---

