lib/deploy: Round to block size in early prune space check #3130
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
cgwalters
approved these changes
Jan 4, 2024
When we estimate how much space a new bootcsum dir will use, we weren't accounting for the space overhead from files not using the last filesystem block completely. This doesn't matter much if counting a few files, but e.g. on FCOS aarch64, we include lots of small devicetree blobs in the bootfs. That loss can add up to enough for the `fallocate()` check to pass but copying still hitting `ENOSPC` later on. I think a better fix here is to change approach entirely and instead refactor `install_deployment_kernel()` so that we can call just the copying bits of it as part of the early prune logic. We'll get a more accurate assessment and it's not lost work since we won't need to recopy later on. Also this would not require having to keep in sync the estimator and the install bits. That said, this is blocking FCOS releases, so I went with a more tactical fix for now. Fixes: coreos/fedora-coreos-tracker#1637
There are a few things the estimator doesn't account for, e.g. writing the new BLS entries. Rather than trying to perfect it (since I think we should change approach entirely -- see previous commit message), just add a 1M margin to the space check.
jlebon
force-pushed
the
pr/autoprune-aarch64-dtb
branch
from
39ff27f to
cc5747a
Compare
Merged
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When we estimate how much space a new bootcsum dir will use, we
weren't accounting for the space overhead from files not using the
last filesystem block completely. This doesn't matter much if counting
a few files, but e.g. on FCOS aarch64, we include lots of small
devicetree blobs in the bootfs. That loss can add up to enough for the
fallocate()check to pass but copying still hittingENOSPClater on.I think a better fix here is to change approach entirely and instead
refactor
install_deployment_kernel()so that we can call just thecopying bits of it as part of the early prune logic. We'll get a more
accurate assessment and it's not lost work since we won't need to
recopy later on. Also this would not require having to keep in sync the
estimator and the install bits.
That said, this is blocking FCOS releases, so I went with a more tactical
fix for now.
Fixes: coreos/fedora-coreos-tracker#1637