-
Notifications
You must be signed in to change notification settings - Fork 129
BlockStorage: Reduce pruneduringinit as needed (no further than normal -prune) if disk space is low #158
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: 28.x-knots
Are you sure you want to change the base?
Conversation
…l -prune) if disk space is low
uint64_t prune_target_temporarily{(uint64_t)m_opts.prune_target_during_init}; | ||
if (prune_target_temporarily <= target) { | ||
target = std::max(min_overall_target, (uint64_t)m_opts.prune_target_during_init); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why not also use it in the std::max ?
why not go the extra mile and also check if target itself (not only the boost) is within the diskspace and cap it if necessary? |
Concept NACK I think overriding a genuinely inputted parameter by the user as an active argument: i.e.: -pruneduringinit should not be tampered with mid execution. Better to fail and let the user handle it as they see fit. |
That could risk pruning more than the user ever wanted to, which is not repairable.
There is currently no "smart" way to use as much disk as possible during IBD, and pruneduringinit is temporal by nature (after IBD completes, the normal prune setting will take over) |
I'm having some trouble imagining why people would want pruning configurations to this level of nuance to begin with, what are some of the use cases of Theres also a bunch of problems with the code i can see... |
Pruning forces the chainstate to commit to disk, significantly slowing down the initial sync. The original goal behind pruneduringinit is to avoid pruning longer, so sync completes faster, but immediately transition to the final prune size after it's done. So if you have 5 TB free disk space, but don't want the node to use more than minimum, you can set -prune=550 -pruneduringinit=0 to disable pruning entirely during sync, and reduce to 550 MB later. If we take free disk space into consideration as proposed by this PR, pruneduringinit=0 would be safe regardless of free disk space. |
Makes sense.
I am on the fence about overriding explicit user input over here because these users are anyways quite on the technical end of the spectrum but i dont have strong conviction either way However, this is broken for snapshot loaded nodes because most of your IBD will ignore |
No description provided.