Skip to content

Add progress handling during hash index generation for adaptive mode 'block-hash-index' #1734

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

Open
wants to merge 7 commits into
base: master
Choose a base branch
from

Conversation

ejoerns
Copy link
Member

@ejoerns ejoerns commented Jun 16, 2025

Depending on the CPU and storage speed, generating the hash index for the adaptive mode 'block-hash-index' might take a notable amount of time.

So far, we don't emit any progress information during these steps, which could give the impression that the installation progress stalls.

With this approach, we reserve 10% of the step progress for both the 'target_slot' and the 'active_slot' generation and increment the progress evenly while generating the hash index.

Also, add some testing adaptations and improvements related to this feature.

ejoerns added 7 commits June 16, 2025 08:38
This allows installing the adaptive-enabled bundle
test/good-adaptive-meta-bundle.raucb from the emulated system.

Signed-off-by: Enrico Jörns <ejo@pengutronix.de>
The name TEST_UPDATE_HANDLER_INCR_BLOCK_HASH_IDX is a remnant from the
initial term 'incremental updates' that is now referred to as 'adaptive
updates'. Rename it to allow finding it when searching for 'adaptive'.

Signed-off-by: Enrico Jörns <ejo@pengutronix.de>
… adaptive mode

Depending on the CPU and storage speed, generating the hash index for
the adaptive mode 'block-hash-index' might take a notable amount of
time.

So far, we don't emit any progress information during these steps, which
could give the impression that the installation progress stalls.

With this simple approach, we reserve 10% of the progress for both the
'target_slot' and the 'active_slot' generation.
While this does not emit progress *during* the actual hash index
generation, it adds two benefits:

1. An update between the two hash indexes that might need to be
   generated
2. A progress of already 20% after reading or generating the hash index.
   Which might well reflect the optimization even if the index was
   loaded from a file.

Since 10% is a quite arbitrary value, define it by
R_HASH_INDEX_GEN_PROGRESS_SPAN to allow changing it easily and to
reflect its meaning (also for follow-up code added).

Signed-off-by: Enrico Jörns <ejo@pengutronix.de>
The newly introduced method r_context_inc_step_percentage() allows
incrementing the given step's percentage by one, without needing to now
its current absolute value.

Signed-off-by: Enrico Jörns <ejo@pengutronix.de>
While the previous change added progress updates after each possible
hash index generation, this now introduces progress updates *during*
hash generation.

We have reserved a fixed amount of step percentage for each generation,
represented by the R_HASH_INDEX_GEN_PROGRESS_SPAN variable. By splitting
up the generation into R_HASH_INDEX_GEN_PROGRESS_SPAN - 1 steps and
increasing the step percentage by one each time, we ensure emitting a
linear progress for each generation.

Signed-off-by: Enrico Jörns <ejo@pengutronix.de>
With the previous addition of progress handling for adaptive mode hash
index generation, the progress may already be at a certain percentage
when an adaptive error occurs that triggers the manual copying fallback.
The manual copying will then reset the step progress to 0.

Since we allow the step progress to go backwards but ensure that high
level progress is only emitted when progress increases, this shouldn't
be an issue. The only observable behavior in this case is that the
overall progress may stall until the step percentage exceeds its
previous value again.
Since this case should happen rarely, it should be acceptable.

Signed-off-by: Enrico Jörns <ejo@pengutronix.de>
Signed-off-by: Enrico Jörns <ejo@pengutronix.de>
@ejoerns ejoerns added the enhancement Adds new functionality or enhanced handling to RAUC label Jun 16, 2025
Copy link

codecov bot commented Jun 16, 2025

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 84.54%. Comparing base (b0d58a1) to head (a87e8bd).

Additional details and impacted files
@@            Coverage Diff             @@
##           master    #1734      +/-   ##
==========================================
+ Coverage   84.51%   84.54%   +0.02%     
==========================================
  Files          76       76              
  Lines       22328    22362      +34     
==========================================
+ Hits        18871    18905      +34     
  Misses       3457     3457              
Flag Coverage Δ
service=false 81.03% <100.00%> (+0.02%) ⬆️
service=true 84.49% <100.00%> (+0.02%) ⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@ejoerns
Copy link
Member Author

ejoerns commented Jun 25, 2025

While this solution is more like an intermediate workaround, I currently don't have more time in my project for a larger rework of the current progress handling, which would be required to allow more dynamic sub-step creation, etc.

Maybe I'll come back to this in some other context later, but for now, this is the best solution I can provide.

If someone is interested in improving progress updates during block-hash-index generation, please drop a note here.

@ejoerns ejoerns removed their assignment Jun 25, 2025
@ejoerns ejoerns requested a review from jluebbe June 25, 2025 19:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Adds new functionality or enhanced handling to RAUC
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant