Shifting Bitcoin Core's block storage to different media blocksdir option

Just wanted to share what I went through recently with moving the block storage of my non-pruned Bitcoin Core node. Been running low on storage space for a while, so it was time to do something about it. I found a bunch of mentions for "blocksdir" in previous posts but none of them really fit what I wanted to say, so here I am with a fresh thread. I'm using an older Thinkpad laptop with Ubuntu, and it’s got a 1TB SATA SSD as the main drive. This thing runs almost all the time, with the screen closed and connected to an external monitor. I’ve got a full Bitcoin Core node set up to keep tabs on some watch-only wallets, plus all the necessary indices. Most of my browsing happens on this laptop, and I need the Bitcoin Core node whenever I need to run blockchain queries. So, I noticed my free storage was dropping below 20 GiB, and I figured it was time to act. Thankfully, I had another 1TB SATA SSD lying around along with a caddy to fit it into the optical drive bay (yeah, this Thinkpad is really that old). The new SSD showed up as /dev/sdb, and I formatted it, mounting the partition as /mnt/ssdplus. My plan was to adjust the blocksdir option in my bitcoin.conf file after shifting the main blocks folder over to this new partition. I shut down the node properly, rsynced .bitcoin/blocks to /mnt/ssdplus/blocks, checked that the data matched up perfectly, deleted .bitcoin/blocks, and then added the necessary line to my bitcoin.conf.

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. My (much easier) solution was to symlink my blocks directory to a different partition. That includes all subdirectories inside blocks. 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:

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

OP already explained why: 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.

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. Good point, although performance of some SSD (usually older or cheap ones) got reduced when it's nearby full (90% full or more). 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.

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

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.

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.

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