Ask to prune on Low Disk space #7097

I had the bitcoin daemon running but it crashed because the disk run out of space.

If I try to restart it, it runs for a while and then crash again.

Error: Error: Disk space is low!

Maybe instead of crashing it should halt the download of the current blocks or give me the option/chance to prune the current space?

If CheckDiskSpace() detects low disk space (IIRC <50MB), it results in a shutdown (not a crash). A solution could be to stop all network traffic and ask the user to increase available disk space or prune the blockchain. But another state (disk-full-no-net-activity-state) is always a burden and should be avoided.

@jonasschnelli The problem is that I can't use the CLI if the daemon is not running. My point is, I can make use of the actual downloaded data or the available features. So why shut it down? Or maybe there is a technical limitation that I'm not aware of.

@omarabid: In case of a full disk, did you try to prune? Start the bitcoind (or bitcoin-qt) with -prune=550. Would be nice to hear if that work in a such full-disk-case.

That worked (and freed my AWS disk space). I wonder why this should be GUI only feature, especially that I'm using the CLI. Maybe have both? Anyway, there should be a taker for this issue first :)

Possibly relevant factor: if the disk is in fact completely full, Core will destroy the wallet irrepairably, and require restoring it from backup. So, it is a critical problem to be avoided at any cost; it may make sense to unconditionally begin pruning slowly to ensure the disk is never full.

It makes sense for the daemon to shutdown. It doesn't make sense for Qt to close (IMHO).

That worked (and freed my AWS disk space). I wonder why this should be GUI only feature

The GUI can ask the user what to do. The daemon can't.

I'm definitely against automatically starting pruning in the daemon, remember that you need to re-download everything to go from pruning back to full archive. That's not what you want to happen if for some reason disk space (which, on a server, you should be monitoring anyway!) is temporarily low. "Shutdown and let the operator decide" is the only thing that makes sense here.

Possibly also related to #7111 (in terms of 'notifying the operator')

Possibly relevant factor: if the disk is in fact completely full, Core will destroy the wallet irrepairably, and require restoring it from backup. So, it is a critical problem to be avoided at any cost; it may make sense to unconditionally begin pruning slowly to ensure the disk is never full. @luke-jr Is there a security concern to destroy the wallet?

I'm definitely against automatically starting pruning in the daemon, remember that you need to re-download everything to go from pruning back to full archive

Just getting there means OS-issued "Low space" warnings have been ignored for days if not longer. I'm not aware of any application that changes its setting because the OS is not properly maintained. Is it so difficult to empty one's Recycle Bin, uninstall Firefox or delete the last 51 blocks? To enable pruning could turn out to be more "expensive" than any other workaround.

There could be multiple thresholds. E.g. diskspace < 1GB it gives a warning in GetWarnings() (returned in getinfo and shown in the status bar), whereas the current 'hard emergency shutdown' threshold is kept to avoid @Luke-Jr's wallet munging concerns.

I think it would be more useful to ask whether to prune on first run of the application, at the same time the data directory is chosen. This question could be re-triggered on the next start after the application was shut down due to disk space concerns.

@laanwj are warnings printed to stderr?

dcousens: No. Just to the debug log. Well-behaved daemons and GUI application shouldn't print to stderr.

Related to: Exposing prune option in GUI #6461

I like the idea of automatically asking the user if it is ok to enable pruning in the event of insufficient disk space - however, I would prefer this feature waits until it's possible to turn off pruning without needing to re-download the entire block chain (i.e. only re-download the blocks that have been pruned).

(i.e. only re-download the blocks that have been pruned).

It would be useful to be able to re-download other ranges, especially when importing older wallets that need partial rescanning, but realize that the pruned part is always going to be a negligible part of the chain. E.g. the last 550Mb of >80GB. So it's not that big of a win when the goal is to switch back to full chain hosting.

@laanwj In the example of 550Mb of 80GB you're right that it wouldn't be a big win. However in the example of 40GB of 80GB it would be. I wasn't excluding examples such as the latter one.

Those are extremely rare though, because there is currently no gain (either to yourself or others) in storing a larger range if you prune. Sure, that may change too at some point. But this is absolutely no blocker to a more user-friendly "Prune" button.

For reference, is there a way to calculate the least amount of disk space necessary such that a pruned node set to 550 will never run out of space? For example, I've been experimenting syncing to a 2.49 GB RAM disk to avoid the heavy disk I/O on a laptop, and when spot checking it, the free space may have gotten below 500MB once or twice, but that's only what I've happened to have seen. I've got enough RAM to expand the RAM disk a bit more, but I have no idea what would be sufficient.

@mmortal03 The bitcoin data directory consists, globally, of:

• Configuration files: trivial
• Logging files: bounded at 10MB if the node is regularly restarted, otherwise it may grow larger, though with default debug settings this is only very slowly.
• UTXO database=chainstate: large ~3GB at the moment
• Block index: small, ~64MB at the moment
• Block storage and undo files: huge ~110GB at the moment
• Temporary state storage (banlist, mempool, etc): a few MB, max size of mempool can be configured

All of these except for the UTXO database, block index and block files are bounded. When pruning is enabled that also guarantees that "block storage and undo files" won't exceed the set threshold. What is left is:

• The block index is small, a few bytes per block, so pretty much irrelevant in this equation.
• The UTXO database is forever-growing and has to be completely stored at all times. This is the potentially problematic one here, which is why UTXO database growth and UTXO spam is considered such a serious issue.

If your goal is to avoid disk i/o during syncing a better choice than a RAM disk is to pump up -dbcache to a big number, say, 8000. The full amount of memory that you have available. This makes sure the entire initial sync will happen in the cache and will only sync to disk afterwards.

Thanks for the bullet points, that's very helpful! Based on the current UTXO size, I'll definitely need to allocate more space, then.

Regarding your second post, not to have things drift too far off topic, but I was previously running dbcache up to 2000 (not high enough?) and was still getting high disk i/o such that the computer was not very responsive for anything else needing access to the hard disk (not an SSD).

One thing that comes to mind is that I closed and re-opened Core a few times along the way, so, might it be that once you close Core and open it back up, you've lost the benefit of whatever was in the dbcache during those previous sessions for good?

One thing that comes to mind is that I closed and re-opened Core a few times along the way, so, might it be that once you close Core and open it back up, you've lost the benefit of whatever was in the dbcache during those previous sessions for good?

Part of it - it indeed won't pre-populate the cache at startup, so only entries that are updated will go back to the cache.

The GUI now does this, at least on first launch: #16714.

The GUI now does this, at least on first launch: #16714.

Ok, closing then.