-
Notifications
You must be signed in to change notification settings - Fork 243
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support creating and mounting Btrfs subvolumes #890
Comments
I was wondering whether it would make sense to extend the To mount the /home subvolume one could use a syntax such as
The brackets are escaped by udev, so there will be no conflict with existing path names (e.g. in a file system label), and this is the same syntax used by Creation of new subvolumes is more complex due to the fact that Btrfs supports different styles of subvolume layouts. Looking at the example from above we can see that most of the subvolumes are direct children of @ (which is not the root file system, but @/.snapshots/283/snapshot is). On the other hand e.g. @/var/lib/machines is a subvolume of @/var. Probably a distinction between relative and absolute paths (starting with a '/' or not in the brackets maybe?) would be enough, but in any case Ignition would have to make sure the parent is mounted to be able to create the subvolume... Any thoughts? |
Ping: Is there interest in this feature, or is extended Btrfs support out of scope? |
https://build.opensuse.org/request/show/764393 by user dimstar_suse Add 0002-allow-multiple-mounts-of-same-device.patch: Allows mounting a device multiple times, e.g. to mount several subvolumes from a Btrfs device or bind mounting the device to multiple places, by adding the path to the key. [Workaround for gh#coreos/ignition#890]
With Fedora's move to btrfs by default would this issue be in scope now? |
I think this issue is in scope, but I suspect we should add dedicated config attributes for it rather than overloading existing ones. @jdoss, it seems that Fedora change only affects desktop variants. |
This comment was marked as off-topic.
This comment was marked as off-topic.
Ignition supports compound primary keys. We could add a
Is the idea that a relative path would be relative to the default subvolume, and an absolute path would be relative to the top-level subvolume? Can we instead require that all paths be relative to the top-level subvolume? In order of preference, I see a few options:
Thoughts? |
And I guess we'd have to reject |
Agreed.
Not necessarily the default subvolume, but whatever is used for the current root ('/') file system.
That sounds like a very reasonable approach, as everything will be reachable from the top-level subvolume (but not necessarily from the root file system).
Thinking about this again this is probably also the expected solution from a user's perspective: At least when using snapshots for the root file system in most cases one probably doesn't want to have subvolumes of a snapshot.
Yes, btrfs subvolumes don't have labels themselves. |
Okay, sounds good!
That couldn't work anyway. Filesystem creation happens in the disks stage, before the OS mounts |
Any news about this? I really love to have this. |
I'm also very interested in seeing this feature. What exactly is the "top-level" subvolume you are referring to? Do you mean |
|
@bgilbert Yup, that would work just fine. Out of curiosity: I don't see a |
Yes, you'd need a separate mount unit for each subvolume. Butane normally creates that for you if you specify I assume btrfs itself doesn't impose any particular mount order requirements? systemd mount units automatically order themselves with respect to parent mounts (see "Implicit Dependencies" in |
Hey guys. Dusty helped me figure a workaround to get subvolumes mounted but it seems it has to be declared here:
and not with systemd.mount units for reasons of the order the ignition file executes. An issue here is you can't declare the same device twice as butane errors out with a duplication message hence I use $DISKID for the first mount and $DISKUUID for the second (both symlinked to the same device). Another issue here is we are limited to mounting two subvolumes unless we can somehow create more persistent symlinks to the device. There is a discussion here with a bit more detail about my findings with this. |
I understand how this mounts Btrfs subvolumes (and that's a pretty creative workaround btw), but this doesn't actually create them from a bare disk, or does it? Are you creating these subvolumes by hand in advance? |
Not at the moment. Ignition doesn't have this capability for subolume creating and mounting. I am creating the subvolumes beforehand manually. |
So, out of pure curiosity and since this is something I'd really like to see (All my FCOS instances run on Btrfs): Where would a change like this need to be implemented? I feel like this discussion isn't actively tracked or implemented anywhere, but maybe that's just my impression from following this thread. If my time permits and I don't have to modify a dozen repos all at once, maybe I'd give it a stab. I think that having some implementation would at least allow us to discuss how we best implement it and what's feasible. |
Is it possible to allow mounting multiple subvolumes, by ignoring duplicate devices if we have |
Feature Request
Btrfs is a supported file system for Ignition, but currently lacks support for several extended features. One of those features is subvolume support, which is used extensively on *SUSE distributions.
Desired Feature
In a first step Ignition should at least support mounting multiple existing subvolumes from the same device to be able to drop files on there during the files stage. This is currently failing because Ignition does not support using the same
device
name more than once.Mounting a single subvolume per device is possible since #872 by using appropriate mount options.
In a second step it would be good if Ignition would also support creating additional subvolumes.
Other Information
This is related to and doing the opposite of #815, where multiple disks contain one Btrfs file system.
Example
Subvolume layout from an openSUSE installation:
Currently it is not possible to mount more than one of these subvolumes besides the root file system.
The text was updated successfully, but these errors were encountered: