User directories as Btrfs subvolumes by default #232
Labels
No labels
a11y
btrfs
Closed As
Can't fix
Closed As
Deferred to upstream
Closed As
Fixed
Closed As
Won't fix
default-apps
easyfix
experience
help-wanted
installation
meeting
meeting-request
nvidia
packaging
pending-action
qa
testing
user-docs
wg-docs
wg-meta
No milestone
No project
No assignees
4 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
workstation/tickets#232
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?
shadow-utilssince 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 tooling as well as encryption as tracked in #82), it may be a good idea to start defaulting to creating subvolumes on creating new users when on Btrfs.
General Fedora Btrfs ticket is tracked as fedora-btrfs/project#50.
This seems like an aspect of the discussion about homed and user data encryption. Do we need a separate ticket for it?
This is orthogonal to homed, since we can do this without homed today.
But it seems like it would be better to wait and see how homed plays out? Or, if you think we should do it ASAP, then let's put that to the WG to decide.
The main value for doing it now is making it easier to something like Time Machine for user data, since snapshotting or doing
btrfs sendof a subvolume is possible.Maybe some folks could try this layout locally, and see what happens? What are the cons? fedora-btrfs/project#50 has a couple of concerns listed: backup programs and the installer.
@lennart told us a few weeks ago that there's an early idea (perhaps it's "could happen" more than "will happen") of having systemd-homed learn about Btrfs snapshotting for this purpose; it already has subvolume support: A "btrfs" subvolume for each user, also located in /home/.homedir. This provides no encryption, but good quota support.*
Is the idea to have a way to convert from one subvolume regime to another? Just because it's subvolume based doesn't mean it'll "just work" with the systemd-homed way of doing things. Do we really want to do that work? We'd have to plan for that. Or alternative just wait and have one change instead of, in-effect, two changes? And while it's fairly simple to convert from one subvol regime to another (cp -r) it's harder to convert from one snapshot regime to another. We don't have a spec for any of that, it's all very tool specific with a ton of assumptions made by each tool.
And so on...
Seems like this would benefit from a wider discussion - setting the meeting label.
Metadata Update from @aday:
From last week's meeting:
Metadata Update from @ngompa:
Refreshing my memory on this:
shadow-utilsset the home subvolume to be owned byrootinstead of the new user, need to verify if this is still a problem. If it is, file a bug.@ngompa looks like you have the action item here.
@ngompa could you provide a status update please?
We discussed this on Tuesday's working group call. It seems that the main advantage of user directories as subvolumes is that, when encrypted, they can be backed up without the need for decryption.
This change is still wanted. The next step is to figure out how to use shadow-utils to do it - if someone wants to help with that, then that would be great.
Metadata Update from @aday:
This might break the trash feature?
@ngompa can you provide a status update on this please? The action item is assigned to you.
It fell off my radar, but it's on my list to investigate and test, especially as a precursor to other interesting work around encryption and easy replication.
This doesn't seem like a real advantage to me. When backing up, you surely want to exclude locations like cache directories and trash, and possibly git repos, and possibly container images and virtual machines, etc. Certainly you don't want to back up caches. In practice, my home directory often has 500 GB or more of data that should not be backed up and only about 30 GB of data that does belong in backups.
Looking over the concerns raised in https://pagure.io/fedora-btrfs/project/issue/50, it actually looks like this change would break several popular backup programs. Maybe we should just not do it?
@ngompa are you sure we still want to do this?
We do, but there's currently no way to adjust shadow to default to this. A ticket is open with upstream shadow about this.
Looks like we have two concerns here:
We'll just have to fix GLib.
We're OK with doing this anyway, and expect backup programs to fix themselves?
This seems manageable.
Metadata Update from @catanzaro: