xattr: support user.update-interval xattr for component stability#100
Merged
xattr: support user.update-interval xattr for component stability#100
user.update-interval xattr for component stability#100Conversation
First, the Fedora minimal image is too tiny to get a good signal out of benchmarking improvements. Second, bump warmups to 3 since I've seen cases where 1 is not enough to preload caches. Third, redirect to a real file rather than `/dev/null` so it's closer to how chunkah is actually used.
Compression impacts both the OCI archive itself and tar layers. It's the same setting but the logging right now gives the impression that it doesn't apply to the latter.
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces support for the user.update-interval extended attribute, allowing users to specify component update frequencies (e.g., daily, weekly) to optimize the layer packing algorithm. The implementation includes parsing logic for named labels and integer days, stability probability calculation using a Poisson model, and conflict detection. Additionally, the pack_components function was refactored for better parameter passing, and comprehensive tests were added. Review feedback suggests refining the documentation regarding fallback stability behavior and refactoring repetitive setup logic in the new tests for better maintainability.
Allow users to specify the stability of xattr components via `user.update-interval`. The value can be either a positive integer representing the average update interval in days (e.g. '30') or a named label (daily, weekly, biweekly, monthly, quarterly, yearly). That makes it easier to understand than having them plug in the probability directly. This plugs a notable gap we've had so far in the xattr repo, which without this information was useful mostly when there was no to little packing pressure. As soon as aggressive packing is required, treating a high stability component as low can lead to suboptimal outcomes. Closes: #98 Assisted-by: OpenCode (Claude Opus 4.6)
With xattrs now supporting stability, it's super easy to have a unit test which exercises packing more from end-to-end. Do this. This at the same time tests the xattr stability feature itself. Assisted-by: OpenCode (Claude Opus 4.6)
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Allow users to specify the stability of xattr components via
user.update-interval. The value can be either a positive integer representing the average update interval in days (e.g. '30') or a named label (daily, weekly, biweekly, monthly, quarterly, yearly). That makes it easier to understand than having them plug in the probability directly.This plugs a notable gap we've had so far in the xattr repo, which without this information was useful mostly when there was no to little packing pressure. As soon as aggressive packing is required, treating a high stability component as low can lead to suboptimal outcomes.
Closes: #98
Assisted-by: OpenCode (Claude Opus 4.6)