Bitcoin Forum
September 05, 2026, 03:24:16 AM *
News: Latest Bitcoin Core release: 31.1 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 [2]  All
  Print  
Author Topic: 1TB micro SD card for storing blockchain, any reason not to do this?  (Read 499 times)
LoyceV
Legendary
*
Offline

Activity: 4158
Merit: 22616


Thick-Skinned Gang Leader and Golden Feather 2021


View Profile WWW
August 31, 2026, 08:01:29 PM
Merited by vapourminer (1)
 #21

Would it be feasible for me to use this method to compress the blockchain file on my 1TB SSD? I'm down to my last 8GB, so I've got about a month left. Soon I'll have to either migrate to a new drive or compress the blockchain in its current location. Would the latter be possible?
Assuming Linux: I've never used a compressed filesystem, and I can't tell you if it can be compressed on the fly or needs to start from scratch.
But: have you considered reserved space on the disk? Chances are it reserved 5% by default, and if you reduce that to 2%, you buy yourself a few more months. Keyword: tune2fs (if that's the case).

Is there a reason you're not just pruning Bitcoin Core?

¡uʍop ǝpᴉsdn pɐǝɥ ɹnoʎ ɥʇᴉʍ ʎuunɟ ʞool no⅄
zabzob (OP)
Member
**
Offline

Activity: 167
Merit: 60


View Profile
August 31, 2026, 09:22:52 PM
 #22

have you considered reserved space on the disk? Chances are it reserved 5% by default, and if you reduce that to 2%, you buy yourself a few more months. Keyword: tune2fs (if that's the case).

Is there a reason you're not just pruning Bitcoin Core?

Thanks so much for this advice. I used tune2fs to reduce reserved space to 2%, and my available space increased from 8GB to 35GB. That buys me about 3 more months, or 4 total. That's huge, because I'll have more cash available for a new drive in a few months. By that time I'll be able to get a new 2TB ssd instead of getting an external hdd, which would be a hassle to use.

I wasn't even aware that Linux reserved so much space by default. Any reason not to reduce the reserve further to 1%, or even 0? Do I really need reserved drive space?

As for not using a pruned node, I'm running an app that requires a full node.
LoyceV
Legendary
*
Offline

Activity: 4158
Merit: 22616


Thick-Skinned Gang Leader and Golden Feather 2021


View Profile WWW
September 01, 2026, 05:15:07 AM
 #23

I wasn't even aware that Linux reserved so much space by default.
It's a remnant from the time disks were much smaller.

Quote
Any reason not to reduce the reserve further to 1%, or even 0? Do I really need reserved drive space?
Reserved space is used for system processes, you don't want them running out of disk space, that would lead to unexpected problems. And it's used for wear leveling and to reduce fragmentation. Chances are writing gets much slower when the disk is almost full.
I wouldn't recommend filling your system disk to the last byte.

¡uʍop ǝpᴉsdn pɐǝɥ ɹnoʎ ɥʇᴉʍ ʎuunɟ ʞool no⅄
ABCbits
Legendary
*
Offline

Activity: 3724
Merit: 10356



View Profile
September 01, 2026, 07:27:31 AM
Merited by vapourminer (1)
 #24

Would it be feasible for me to use this method to compress the blockchain file on my 1TB SSD? I'm down to my last 8GB, so I've got about a month left. Soon I'll have to either migrate to a new drive or compress the blockchain in its current location. Would the latter be possible?
Assuming Linux: I've never used a compressed filesystem, and I can't tell you if it can be compressed on the fly or needs to start from scratch.

ext4 filesystem (probably most commonly used format) doesn't have disk-level compression feature. OP probably need to reformat his drive into filesystem that support disk-level compression feature. btrfs, OpenZFS and F2FS are the common option, but AFAIK it can be tricky to configure it properly. But personally i only tried it with btrfs with mixed result.

Other approach such as using FUSE-zip exist, but it's less popular and i wouldn't recommend people use it for something as important as running full node.

zabzob (OP)
Member
**
Offline

Activity: 167
Merit: 60


View Profile
September 01, 2026, 03:43:40 PM
Merited by vapourminer (1)
 #25

I wasn't even aware that Linux reserved so much space by default.
It's a remnant from the time disks were much smaller.

Quote
Any reason not to reduce the reserve further to 1%, or even 0? Do I really need reserved drive space?
Reserved space is used for system processes, you don't want them running out of disk space, that would lead to unexpected problems. And it's used for wear leveling and to reduce fragmentation. Chances are writing gets much slower when the disk is almost full.
I wouldn't recommend filling your system disk to the last byte.

Got it. I might reduce it again to 1% if I need to wait an extra month before upgrading the SSD. 10GB reserved should be enough to keep the processes running. And since that'll be the last month of its use as an OS drive, I'm not worried about wear and fragmentation.
vapourminer
Legendary
*
Offline

Activity: 5152
Merit: 6792


what is this "brake pedal" you speak of?


View Profile
September 04, 2026, 02:13:32 PM
Last edit: September 04, 2026, 02:42:19 PM by vapourminer
Merited by philipma1957 (1)
 #26

Would it be feasible for me to use this method to compress the blockchain file on my 1TB SSD? I'm down to my last 8GB, so I've got about a month left. Soon I'll have to either migrate to a new drive or compress the blockchain in its current location. Would the latter be possible?

if you do system level disk compression with only ~8GB free you are goin to absolutely hammer that thing writing/rewriting/moving/erasing etc with such little space available.

how far do you trust that SSD being able to take a 100% duty cycle, non stop 24/7, abuse for a day or two (just a guess) of compression duty?

i would do it if i had a proper tested backup.. otherwise... oooff kinda a tossup. do you trust your hardware?

anyway i would throw a fan on it if you try it.

edit: nevermind, seem his OS doesnt support it anyway. reading is hard.
Pages: « 1 [2]  All
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!