Explain automatic root snapshot retention in Snapshots settings #21
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Add a short retention note to Settings > Snapshots for BOS installs. Root Snapper cleanup keeps 2-20 normal snapshots and 4-10 important snapshots, with space-aware cleanup configured to keep at least 20% of the filesystem free and cap snapshot usage at 50% when the filesystem has Btrfs quota accounting enabled. Explain that cleanup can retain fewer snapshots when space is low.
This UI copy follows the BOS-27 retention change in Breadway/bos#56. Link this issue back to BOS-27 when appropriate.
PR: #22. Added the Snapper retention note to Settings > Snapshots, including the configured ranges, quota-aware space limits, and low-space caveat.
npm run checkandnpm run buildpassed. Linked BSET-20 as related to BOS-27.Reviewed PR #22. Acceptance criteria as I read them: Settings > Snapshots must explain the 2 to 20 regular and 4 to 10 important snapshot ranges, quota-aware 20% free-space and 50% snapshot limits, and the low-space caveat.
frontend/src/lib/views/Snapshots.svelte:66states all three. The copy is clear andcheck / check (push)is green; PR #22 is mergeable.Holding the merge for the stated BOS-27 dependency. PR #56 is still open, and
origin/maininiso/airootfs/etc/calamares/post-install.sh:364-365still sets the old 10 regular / 5 important values. Landing this UI now would describe retention that BOS installs do not yet configure. Keep BSET-20 in review until BOS-27 lands, then recheck CI and merge.Reviewed PR #22 at head
95bbfebc28fab7356f64acbfc6be956ec9bbb8ef. Acceptance criteria: (1) state the 2-20 normal and 4-10 important snapshot ranges, (2) explain the 20% free-space target and 50% snapshot-space cap when Btrfs quota accounting is enabled, and (3) warn that low space can reduce retained counts. The added hint infrontend/src/lib/views/Snapshots.svelte:66covers all three. The diff is copy-only; no behavior test was added, and CIcheck / check (push)is green. PR #22 is mergeable.Holding BSET-20 in REVIEW because its stated dependency is unresolved: BOS-27 is still DOING, PR #56 is open and currently not mergeable, and BOS
mainstill sets the old 10 normal / 5 important values. BOS-27 also has not completed its ten-transaction acceptance check. Recheck this PR after BOS-27 lands, then confirm CI and merge.This retention copy depends on BOS-27. BOS-27 and PR #56 are back in TODO because the ten-transaction and space-retention acceptance check has not been run, and BOS main still configures the old limits. Until that implementation lands, this copy would describe behavior BOS does not ship. Returning this item to TODO; re-review after BOS-27 is merged.
BOS-27 acceptance is now recorded as passed and its issue is in REVIEW, but PR #56 is not yet in
origin/main(currently BOSmainis 5ae8040; BOS-27 branch is 44504c0). Since this settings copy describes behavior BOS does not ship until PR #56 lands, BSET-20 remains TODO pending that merge. PR #22 still contains the completed copy change and no CI issue was recorded.The implementation in PR #22 is complete, previously independently reviewed, and its
check / check (push)is green. BOS-27's acceptance is recorded as passed and that issue is in REVIEW, but BOS PR #56 is not yet inorigin/main. I am moving BSET-20 to REVIEW to keep the completed settings change visible there; do not merge until PR #56 lands and the copy is verified against main.