udisks
udisks copied to clipboard
storaged-project
Can't mount multiple btrfs subvolumes
Our mount function currently doesn't allow mounting a device multiple times. This is problem for btrfs subvolume where to mount it user needs to mount the underlying block device multiple times with different subvol= option.
This should be probably part of bigger refactoring of the handle_mount function which is quite messy and adding a special exception for mounting btrfs (sub)volumes would make it even worse.
It might be better to add a special MountSubvolume function to the .Filesystem.Btrfs interface to make it easier for users to mount subvolumes without specifying the subvol= option for the "generic" Mount function. (But I still think Mount should work with btrfs subvolumes because it used when mounting devices using udisksctl.)
Right, given that the btrfs module already provides methods for creating/removing/listing subvolumes, adding a method for mounting seems like a logical next step. Internally still it would have to use major portion of the regular Mount() method codepath.
There's also possibility to expose object representation of subvolumes similar to regular block devices.
So o.fd.U.Filesystem.Mount can either mount things listed in /etc/fstab ("system-managed") or mount things for a non-root user in ad-hoc places, like removable USB drives. For Cockpit, we are only interested in the system-managed case. We will write a correct entry into /etc/fstab, and then want to mount exactly that.
With btrfs, there are multiple entries for a given block device, but o.fd.F.Mount will always use the first one. What would work for us is to add a pretty generic "target" (mountpoint) option to the method, which would be used to find the correct entry in fstab. This would enhance the Mount method without making btrfs specific.
Even more general would be to add a "configuration" option which would specify the whole entry from o.fd.U.Block.Configuration that should be mounted. The Mount method would verify that this entry actually exists in fstab, and then take whatever is needed from it.
That would allow having multiple entries in fstab for a given block device with the same target but different options. Cockpit wouldn't be able to make use of that, but I think it'd be neat.
(And Unmount would also need the same option, "target" or "configuration".)