#50 User directories as Btrfs subvolumes by default
Opened 3 years ago by ngompa. Modified a year ago

shadow-utils since version 4.7 has supported the ability to create user home directories as subvolumes.

As an iterative step toward supporting use-cases for isolating and protecting each user's data individually (to lay the groundwork for disaster recovery options and encryption), it may be a good idea to start defaulting to creating subvolumes on creating new users when on Btrfs.


Anaconda doesn't show nested things as nested, it shows all the subvolumes in a flat list. It'll definitely add confusion to the Custom and Advanced Custom UIs.

We might need a separate tracker for anaconda btrfs things (Automatic UI's lack of shrink, the free space fib, no subvolume support; Custom UI is non-obvious how to reuse home, Automatic can't reuse a Btrfs fs at all). A discoverable subvolume spec would help avoid the need for more UI, and make things less ambiguous. I think even take away the user's ability to (arbitrarily) name subvolumes in the installer entirely.

Metadata Update from @chrismurphy:
- Issue marked as depending on: #20

3 years ago

Custom UI will have a new "unknown" section that lists user subvolumes and snapshots. The listed "$DISTRO$RELEASEVER for $ARCH" still shows /home, which is what the user needs to assign to /home mountpoint when doing a clean install while reusing an existing home subvolume.

So it is incrementally more confusing, but perhaps not a deal killer. I'm torn between fixing the installer's btrfs UI, versus just getting rid of it entirely and just depend on something like "discoverable subvolumes spec" to assemble things where they should go automatically and only show those things. If the user doesn't like the auto-assemble they can click (-) to remove it, although that immediately lands them in the ambiguity of whether (-) means "don't use for this installation" versus "delete it".

If you use (-) in the "New Fedora Installation" section it means don't use it for the installation, but won't be deleted. If you use (-) in any other section it means delete it.

Some utilities, noteably rsync -x and borg (by default) will not cross filesystem boundaries. And subvolumes are treated as separate filesystems by these utilites. It's possible choosing /home for backup will not backup anything, if each user dir is actually a subvolume. I think this change needs a change proposal to help explore the various issues. Maybe punt to 36? If systemd-homed will be used, possible fallout needs some exploration anyway, whether subvolumes or LUKS.

Also, would all DE's do this? What are the consequences if some DEs do it and not others?

Also, would all DE's do this? What are the consequences if some DEs do it and not others?

This would be a distro-wide default, so we'd change the core tools that everything interfaces with.

I think this change needs a change proposal to help explore the various issues. Maybe punt to 36?

I'm fine with this. I didn't set a Fedora release milestone on purpose. :smile:

I'm not super familiar with Timeshift but my understanding is it has a hard requirement on an@home named subvolume. And it isn't configurable. Even if subvolume chris is nested under @home, (a) Timeshift only snapshots @home and (b) snapshots aren't recursive. While Timeshift doesn't work out of the box now, it probably stops working entirely if user directories become subvolumes.

Log in to comment on this ticket.

Metadata
Attachments 1