Moving Bitcoin Core's block storage to other storage media - blocksdir option

[Cricktor]

I'd like to share my recent experience with moving block's storage of my non-pruned Bitcoin Core node due to storage space constraints that have built up and called for action. I found 85 search hits for "blocksdir" in post's text but none felt really suitable to append my post to, therefore I decided to post a new thread.

On my private daily internet driver (an older Thinkpad laptop) with Ubuntu as OS I've an internal 1TB SATA SSD as main storage. This device runs basically 24/7 (with closed screen hooked to my external monitor) and I've a full Bitcoin Core node monitoring a few watch-only wallets of interest for me and all sorts of indices enabled. I browse the forum with this device mostly and need the Bitcoin Core node when I do some blockchain queries or digging occasionally.

Free storage space dropped below 20GiB and it didn't feel comfortable to me anymore to procrastinate any longer. I had another spare 1TB SATA SSD and a caddy for it to insert into the optical drive bay (yes, the Thinkpad is that old to have something like this and is the only option to add a second internal SATA storage with 2.5inch form factor). This second SATA SSD was then recognized as /dev/sdb and the formatted sole partition /dev/sdb1 mounted permanently at /mnt/ssdplus.

My plan was to use the blocksdir option in my bitcoin.conf file after moving the main space hog blocks folder to the new partition. Shutdown the node clean. Rsynced .bitcoin/blocks to /mnt/ssdplus/blocks, verified the destination is the same as the source bit-by-bit, deleted .bitcoin/blocks and added below line to my bitcoin.conf:

Code:

# Specify a non-default location to store blockchain data.
blocksdir=/mnt/ssdplus

Fired up Bitcoin Core in GUI mode and, you guessed it, it didn't work out too well (because I didn't really read any documentation about the blocksdir option, I naively thought I could move the whole blocks folder to another partition, silly me). Bitcoin Core didn't recognize any block data apparently and I aborted to reinitialize the blockchain.

...
2025-07-24T13:37:43Z Using obfuscation key for blocksdir *.dat files (/mnt/ssdplus/blocks): '0000000000000000'
2025-07-24T13:37:43Z Opening LevelDB in /home/dude/.bitcoin/blocks/index
2025-07-24T13:37:43Z Opened LevelDB successfully
2025-07-24T13:37:43Z Using obfuscation key for /home/dude/.bitcoin/blocks/index: 0000000000000000
2025-07-24T13:37:43Z Using 16 MiB out of 16 MiB requested for signature cache, able to store 524288 elements
2025-07-24T13:37:43Z Using 16 MiB out of 16 MiB requested for script execution cache, able to store 524288 elements
2025-07-24T13:37:43Z init message: Loading block index…
2025-07-24T13:37:43Z Assuming ancestors of block 00000000000000000001b658dd1120e82e66d2790811f89ede9742ada3ed6d77 have valid signatures.
2025-07-24T13:37:43Z Setting nMinimumChainWork=0000000000000000000000000000000000000000b1f3b93b65b16d035a82be84
2025-07-24T13:37:43Z LoadBlockIndexDB: last block file = 0
2025-07-24T13:37:43Z LoadBlockIndexDB: last block file info: CBlockFileInfo(blocks=0, size=0, heights=0...0, time=1970-01-01...1970-01-01)
2025-07-24T13:37:43Z Checking all blk files are present...
2025-07-24T13:37:43Z Initializing chainstate Chainstate [ibd] @ height -1 (null)
2025-07-24T13:37:43Z Opening LevelDB in /home/dude/.bitcoin/chainstate
2025-07-24T13:37:43Z Opened LevelDB successfully
2025-07-24T13:37:43Z Using obfuscation key for /home/dude/.bitcoin/chainstate: 786dd8786c70e085
2025-07-24T13:37:43Z : Error initializing block database.
Please restart with -reindex or -reindex-chainstate to recover.
2025-07-24T13:37:53Z Shutdown: In progress...
2025-07-24T13:37:53Z scheduler thread exit
2025-07-24T13:37:53Z Flushed fee estimates to fee_estimates.dat.
2025-07-24T13:37:53Z Shutdown: done

Long story short: blocksdir is only about the *.dat files in the blocks folder, Bitcoin Core still expects the block's index database folder blocks/index to remain in the datadir location. That was apparently unintuitive to me, but may have its reasons depending on how intensely the block's index database is utilized.

In above debug.log italic highlighted line Bitcoin Core tries to access the LevelDB in .bitcoin/blocks/index folder which wasn't there because I falsely moved it to /mnt/ssdplus/blocks/index. Subsequently Core thought I didn't have any block files at all and wanted to go into IBD mode and download blockchain from scratch or recover in a similarly lengthy process with -reindex startup option. Something I absolutely didn't want to do!

The solution was of course pretty simple: move /mnt/ssdplus/blocks/index folder back to .bitcoin/blocks/index and restart Core. After that it was happy again with my blockchain data and continued to sync just fine from where it left off before I moved blockchain data files.

You may ask, why did I post this here? Well, it wasn't intuitive for me how the blocksdir option works and I don't find the man page verbose enough to understand it's only about the *.dat files, but that's maybe just me (well, not really as I found some discussion about more verbose documentation of blocksdir in Bitcoin Core issues/pull requests).

      -blocksdir=<dir>

              Specify directory to hold blocks subdirectory for *.dat files (default: <datadir>)

I hope this helps someone else and clarifies the use of blocksdir option. I now have a more healthier storage space situation for my daily driver Ubuntu box (sizes in KiB, MiB and GiB below). Should take some time before blockchain growth exhausts available space on /dev/sdb1.

Code:

Filesystem                 Size  Used Avail Use% Mounted on
tmpfs                      783M  3,3M  779M   1% /run
/dev/mapper/vgubuntu-root  898G  121G  732G  15% /
tmpfs                      3,9G     0  3,9G   0% /dev/shm
tmpfs                      5,0M  4,0K  5,0M   1% /run/lock
efivarfs                    56K   28K   24K  54% /sys/firmware/efi/efivars
/dev/sda2                  1,7G  393M  1,2G  26% /boot
/dev/sda1                  511M  6,1M  505M   2% /boot/efi
/dev/sdb1                  916G  716G  154G  83% /mnt/ssdplus
tmpfs                      782M  124K  782M   1% /run/user/1000

[LoyceV]

I had another spare 1TB SATA SSD and a caddy for it to insert into the optical drive bay (yes, the Thinkpad is that old to have something like this and is the only option to add a second internal SATA storage with 2.5inch form factor).

My laptop is also that old, but with an almost equally old 2 TB HDD in the DVD bay. Having blocks on HDD works fine, as long as chainstate is on SSD.

I naively thought I could move the whole blocks folder to another partition

My (much easier) solution was to symlink my blocks directory to a different partition. That includes all subdirectories inside blocks.

I now have a more healthier storage space situation for my daily driver Ubuntu box

You're still using the default 5% reserved space. On large disks, I usually reduce that to 2%: it frees up 30 GB per TB:

Code:

sudo tune2fs -m2 <partition>

[alani123]

Ok but why?

The integrity of the blockchain is protected by miners and I'm pretty sure they'll be perfectly able to afford a good enough SSD to fit the entire blockchain as is.
Bitcoin's blockchain isn't bad at all in terms of storage. Compare it to a full archive of Ethereum, Binance Smart Chain, or any smart contract enabled chain and you'll see that the difference is abysmal.

A personal computer can still easily store bitcoin's blockchain easily, although the difference here would be that this node wouldn't be contributing to the most important aspect of decentralization without mining shares, but that's another topic of discussion (and perhaps another fundamental issue of bitcoin).

[LoyceV]

Ok but why?

OP already explained why:

my private daily internet driver (an older Thinkpad laptop) with Ubuntu as OS I've an internal 1TB SATA SSD as main storage.

The integrity of the blockchain is protected by miners and I'm pretty sure they'll be perfectly able to afford a good enough SSD to fit the entire blockchain as is.

I'm pretty sure most Bitcoin miners don't keep a copy of the blockchain. They rely on their mining pool to handle everything for them, all they do is produce hashes.

[ABCbits]

Long story short: blocksdir is only about the *.dat files in the blocks folder, Bitcoin Core still expects the block's index database folder blocks/index to remain in the datadir location. That was apparently unintuitive to me, but may have its reasons depending on how intensely the block's index database is utilized.

Bitcoin Core approach makes sense. They probably expect blocksdir located on slower (and bigger) drive and you want to keep index file on faster drive.

I now have a more healthier storage space situation for my daily driver Ubuntu box

You're still using the default 5% reserved space. On large disks, I usually reduce that to 2%: it frees up 30 GB per TB:

Code:

sudo tune2fs -m2 <partition>

Good point, although performance of some SSD (usually older or cheap ones) got reduced when it's nearby full (90% full or more).

The integrity of the blockchain is protected by miners and I'm pretty sure they'll be perfectly able to afford a good enough SSD to fit the entire blockchain as is.

Mining pool is the one who run full node. Miner only need to join a mining pool and then point their ASIC to pool's stratum link to get mining reward.

[Cricktor]

You're still using the default 5% reserved space. On large disks, I usually reduce that to 2%: it frees up 30 GB per TB:

Code:

sudo tune2fs -m2 <partition>

Very good point, thanks. I already had it on my agenda to research why there's such a significant difference between available free space and total space minus used space. I totally forgot about such thing as reserved space. Next on my bucket list: when is reserved space  actually used (I'll figure it out).

Bitcoin Core approach makes sense. They probably expect blocksdir located on slower (and bigger) drive and you want to keep index file on faster drive.

Once I figured out the actual behavior and with your nod to it, I concluded that this is most likely why it is as it is. Stuff like indices, chainstate, wallets should be in datadir location on fast, high IOPS storage.

Good point, although performance of some SSD (usually older or cheap ones) got reduced when it's nearby full (90% full or more).

Probably more modern flash controllers are smarter after TRIM and at some time later garbage collection and consolidation of free flash blocks and remapping of data to gain more continuous free flash blocks to speed up writing new data. No expert in this, but I like to read publications about how fancy flash storage evolves if I stumble upon them.

[LoyceV]

when is reserved space  actually used (I'll figure it out).

It's used by system services (so for instance logs can still be written), and to avoid fragmentation. The former doesn't take 50 GB, the latter isn't much of a problem on an SSD. Wear leveling may be a thing, but I'm not sure if and how that's influenced by a full disk.

[Cricktor]

From what I have read somewhere about wear leveling of flash storage and how I understand it, it likely suffers from a near full flash storage simply because there are less unused free flash blocks to write new data to. Thus, if there's a lot of rewriting of data the low number of free unused flash blocks makes them be used and rewritten more often than for flash media which has a lot of free unused flash blocks to spread wear.

To reduce wear new writes are directed to free unused flash blocks and rewrites of existing data can also be redirected to free flash blocks, flagging the former flash blocks as free and later to be garbage collected to consolidate them into larger continuous free flash blocks. The flash blocks are internally remapped to appear at same virtual "physical" blocks from the external OS perspective.

This makes also proper use of TRIM important for the flash controller because with TRIM the OS clearly flags regions of sectors or whatever the smallest addressable chunk of storage is as free, unused, available for wear leveling, new writes, remapping and so on.

It got quite complex to maintain good endurance when multi-bit-level flash cells don't have such high number of reliable write-cycles.

Somewhat a digress now, but I don't mind.

[LoyceV]

From what I have read somewhere about wear leveling of flash storage and how I understand it, it likely suffers from a near full flash storage simply because there are less unused free flash blocks to write new data to.

I wouldn't feel comfortable if my system partition is >95% full anyway, but if it's only blocks on it's own disk, it doesn't take much writing. You could probably fill that partition up to the last GB (adding a few extra months before you need to replace it).