Observation
The SAFE/RISK output in `check` and `rollback` (shipped in 0.4.0) groups every non-mountpoint directory inside the root subvolume under RISK. This conflates two very different risks:
- Directories that carry user or system state that would meaningfully regress if reverted (`/etc`, `/usr`, `/opt`, custom data dirs).
- Directories that are ephemeral by convention and get rebuilt on boot anyway — reverting them is inconsequential.
On the default Fedora 43 btrfs layout this distinction is partially handled implicitly: `/run` (tmpfs), `/proc` (procfs), `/sys` (sysfs), `/dev` (devtmpfs), and often `/tmp` (tmpfs) are mountpoints and get filtered out by the existing `is_mountpoint` check in `check::print_rollback_scope`. But the current check is purely structural (mountpoint or not); it does not capture the semantic intent.
The gap becomes real on layouts where a conventionally-ephemeral directory exists as a plain directory inside root (e.g. `/tmp` not mounted as tmpfs). Under current logic that directory shows as RISK even though reverting it has no meaningful consequence. And even on the default layout, a user reading the output has to know "these absences mean tmpfs" rather than having the categorization spelled out.
Proposal
Add a third category, EPHEMERAL (or REGENERATED), that lists directories which are at risk by structure but inconsequential in practice.
Two axes of detection:
- Mount type detection: if the mount at the path is tmpfs / procfs / sysfs / devtmpfs / ramfs, classify as EPHEMERAL.
- Conventional paths: maintain an explicit list of paths whose contents are standardly ephemeral (`/run`, `/tmp`, `/proc`, `/sys`, `/dev`, `/var/run` if still present). Used as fallback for paths that are NOT currently mountpoints but are nominally ephemeral.
The current `is_mountpoint` filter stays; the new category replaces the silent exclusion with explicit classification.
Example output
Rollback scope:
SAFE Separate subvolumes (not affected by rollback):
/home
/var
RISK Inside root subvolume (will revert on rollback):
/etc
/usr
/opt
EPHEMERAL Rebuilt on boot (revert is inconsequential):
/run
/tmp
/proc
/sys
/dev
Why not in 0.4.0
This is a refinement of the classification's fidelity, not a correctness fix. The 0.4.0 output is accurate for the common case and safely conservative (overstating risk never hurts; understating it would). Ship this as 0.4.1.
Acceptance criteria
- Third category added to output, labeled clearly (EPHEMERAL or REGENERATED, final label tbd)
- Classification derived from mount type (via findmnt or /proc/self/mountinfo) where available, with a fallback list of conventionally-ephemeral paths
- Does not reclassify anything currently in SAFE (those remain separate-subvolume-protected)
- VM test: on Fedora 43 default layout, EPHEMERAL section appears with whatever subset of `/run /tmp /proc /sys /dev` are present at top level
Milestone
0.4.1
Observation
The SAFE/RISK output in `check` and `rollback` (shipped in 0.4.0) groups every non-mountpoint directory inside the root subvolume under RISK. This conflates two very different risks:
On the default Fedora 43 btrfs layout this distinction is partially handled implicitly: `/run` (tmpfs), `/proc` (procfs), `/sys` (sysfs), `/dev` (devtmpfs), and often `/tmp` (tmpfs) are mountpoints and get filtered out by the existing `is_mountpoint` check in `check::print_rollback_scope`. But the current check is purely structural (mountpoint or not); it does not capture the semantic intent.
The gap becomes real on layouts where a conventionally-ephemeral directory exists as a plain directory inside root (e.g. `/tmp` not mounted as tmpfs). Under current logic that directory shows as RISK even though reverting it has no meaningful consequence. And even on the default layout, a user reading the output has to know "these absences mean tmpfs" rather than having the categorization spelled out.
Proposal
Add a third category, EPHEMERAL (or REGENERATED), that lists directories which are at risk by structure but inconsequential in practice.
Two axes of detection:
The current `is_mountpoint` filter stays; the new category replaces the silent exclusion with explicit classification.
Example output
Why not in 0.4.0
This is a refinement of the classification's fidelity, not a correctness fix. The 0.4.0 output is accurate for the common case and safely conservative (overstating risk never hurts; understating it would). Ship this as 0.4.1.
Acceptance criteria
Milestone
0.4.1