fix: reduce snapper timeline limits to prevent disk fill

[stufently]

Summary

• Adds timeline snapshot limit configuration (TIMELINE_LIMIT_*) to the existing snapper sed block in cloud-init
• Disables snapper-timeline.timer — redundant since transactional-update already creates pre/post snapshots
• Prevents disk fill on typical Hetzner VMs (40-80GB) that hit DiskPressure within weeks due to aggressive MicroOS defaults

Values applied

Setting	MicroOS default	New value
NUMBER_LIMIT	2-10	4 (unchanged)
NUMBER_LIMIT_IMPORTANT	4-10	3 (unchanged)
TIMELINE_LIMIT_HOURLY	10	0
TIMELINE_LIMIT_DAILY	10	3
TIMELINE_LIMIT_MONTHLY	10	0
TIMELINE_LIMIT_YEARLY	10	0
snapper-timeline.timer	enabled	disabled

Why these values

• Hourly = 0: timeline snapshots are noise when transactional-update already creates numbered pre/post pairs for every OS update
• Daily = 3: keeps a short rollback window without accumulating disk usage
• Monthly/Yearly = 0: useless on ephemeral cloud VMs — a full rebuild is faster than rolling back months

Impact

• Applies to all new nodes (control planes, agents, autoscaler) via cloudinit_runcmd_common
• Existing nodes are unaffected (cloud-init runs only on first boot) — users can apply the same sed commands via SSH or preinstall_exec
• No new variables, no API changes, no breaking changes

Related discussions

• .snapshots folder talking up all disk space on control planes #1319 — .snapshots folder taking up all disk space on control planes
• Node suffers from DiskPressure due to btrfs snapshots #1310 — Node suffers from DiskPressure due to btrfs snapshots
• New cluster control plane nodes at 100% disk usage #1078 — New cluster control plane nodes at 100% disk usage
• BTRFS balance operation causes disk IO usage 100%, all pods affected #1993 — BTRFS balance operation causes 100% disk IO

Follow-up (if desired)

If users need fine-grained control, a snapper_config variable with these as defaults could be added in a follow-up PR. This keeps the current change minimal and focused.

[gemini-code-assist]

Summary of Changes

Hello, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request addresses critical disk space issues on cloud VMs by refining the Btrfs snapshot management through snapper. It introduces more conservative timeline snapshot retention policies and disables the snapper-timeline.timer, which was creating redundant snapshots. These adjustments ensure that system snapshots are managed efficiently, preventing disk exhaustion while maintaining necessary rollback capabilities.

Highlights

• Snapper Timeline Limits: Configured TIMELINE_LIMIT_HOURLY, DAILY, MONTHLY, and YEARLY values in snapper to optimize snapshot retention, setting hourly, monthly, and yearly limits to 0, and daily to 3.
• Snapper Timer Disablement: Disabled the snapper-timeline.timer service to prevent redundant snapshot creation, as transactional-update already manages pre/post snapshots.
• Disk Space Management: Implemented these changes to prevent disk fill issues and DiskPressure on cloud VMs, which were previously caused by aggressive default MicroOS snapshot policies.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request addresses an important issue of disk space consumption by reducing the number of snapper snapshots. The changes to the timeline limits and the disabling of the redundant snapper-timeline.timer are well-justified and should prevent disk pressure on VMs with smaller disks. I have one suggestion to make the sed commands more robust against future changes in the base image.

[gemini-code-assist]

The sed commands rely on the default value being exactly "10". If the base image changes this default in the future, these sed commands will silently fail to apply the configuration, re-introducing the disk-fill issue.

Using a more robust pattern that matches the key and replaces any value will prevent this. I've also removed the unnecessary g flag.

- [sed, '-i', 's/^TIMELINE_LIMIT_HOURLY=".*"/TIMELINE_LIMIT_HOURLY="0"/', /etc/snapper/configs/root]
- [sed, '-i', 's/^TIMELINE_LIMIT_DAILY=".*"/TIMELINE_LIMIT_DAILY="3"/', /etc/snapper/configs/root]
- [sed, '-i', 's/^TIMELINE_LIMIT_MONTHLY=".*"/TIMELINE_LIMIT_MONTHLY="0"/', /etc/snapper/configs/root]
- [sed, '-i', 's/^TIMELINE_LIMIT_YEARLY=".*"/TIMELINE_LIMIT_YEARLY="0"/', /etc/snapper/configs/root]

[mysticaltech]

Thanks @stufently, this snapper timeline growth fix is included in the v2.19.3 patch train here: #2183.

Your contribution is preserved in the branch history and packaged as part of the patch release reliability fixes. Once #2183 lands, this PR can be closed as included.