Bugzilla – Full Text Bug Listing
|Summary:||Expert partitioner interaction with BTRFS is flawed and bugged|
|Product:||[openSUSE] openSUSE Tumbleweed||Reporter:||Tripple Moon <suse>|
|Component:||YaST2||Assignee:||YaST Team <yast-internal>|
|Status:||NEW ---||QA Contact:||Jiri Srain <jsrain>|
|Priority:||P5 - None||CC:||ancor, snwint, suse|
|Found By:||---||Services Priority:|
|Marketing QA Status:||---||IT Deployment:||---|
Description Tripple Moon 2020-08-12 08:18:55 UTC
Because a BTRFS partition is "kind of" like an LVM (in respect to multi-volumes inside one BTRFS partition): - We need a way to separately select *where* to mount the sub-volumes inside each BTRFS partition. (You can have more than one in a system like i have) While doing this don't forget to allow for mount options per sub-mount... - When you want to unmount a BTRFS partition, the Yast2 expert partitioner bugs out with an error and leaves the sub-volume mounts in /etc/fstab, and thus provides no way to unmount a BTRFS partition or it's sub-volumes. (Seems someone already reported about this in bug #1171310 ) Because suse and most other Linux distributions are using Systemd as a system manager in this century; I would also suggest to create systemd mount units instead of entries inside /etc/fstab to move to the new century of Linux in general ;) That will also enable things like dependencies on other FS, auto-(un)mounting, etc... IMHO the *only* entries in /etc/fstab should be the rootFS and maybe the swap, the rest like ESP,etc can all be moved into mount units with or without automount units...
Comment 1 Steffen Winterfeldt 2020-08-12 09:19:52 UTC
Who is 'we'?
Comment 2 Tripple Moon 2020-08-13 09:01:28 UTC
(In reply to Steffen Winterfeldt from comment #1) > Who is 'we'? Isn't it obvious from context that i mean all users that run openSUSE? [At least now it's explicitly mentioned ;)]
Comment 3 Tripple Moon 2020-08-18 11:03:03 UTC
As an real-world example, i have an extra BTRFS partition with these sub-volumes: --- ID 257 gen 1404 top level 5 path @esp ID 260 gen 1404 top level 5 path @iso ID 261 gen 1402 top level 5 path @gitrepos ID 262 gen 1404 top level 5 path @www ID 263 gen 1402 top level 5 path @opt_software ID 264 gen 1402 top level 5 path @SteamGameLib ID 265 gen 1404 top level 5 path @for_new_machines ID 267 gen 1402 top level 5 path @homes --- Whom i want to mount in various spots of my file system separately. At moment the only way for me would be using systemd-mount units (with or without automount)
Comment 4 Steffen Winterfeldt 2020-08-18 12:23:43 UTC
'We' might have been 'big company with a use case requiring this'. That's why I asked. That aside, you are touching actually two distinct issues: 1) btrfs subvolume handling is indeed rudimentary and afaik there are plans already to extend this 2) going for systemd mount units instead of fstab entries Even though systemd might seem the way to go for a lot of things I don't see any compelling reason to move away from fstab. It's easier by far than system mount unit files. And citing systemd.mount(5): > In general, configuring mount points through /etc/fstab is the > preferred approach. In any case, Ancor is coordinating storage-ng development, so let's ask him for comments.
Comment 5 Tripple Moon 2020-08-19 06:54:17 UTC
(In reply to Steffen Winterfeldt from comment #4) > 'We' might have been 'big company with a use case requiring this'. That's why > I asked. > > That aside, you are touching actually two distinct issues: > > 1) btrfs subvolume handling is indeed rudimentary and afaik there are plans > already to extend this > > 2) going for systemd mount units instead of fstab entries > > Even though systemd might seem the way to go for a lot of things I don't see > any compelling reason to move away from fstab. It's easier by far than > system mount > unit files. And citing systemd.mount(5): > > > In general, configuring mount points through /etc/fstab is the > > preferred approach. > > In any case, Ancor is coordinating storage-ng development, so let's ask > him for comments. I only mentioned (2) as the only way currently to do what i wrote about, because of the lack of selecting mount points separately per subvolume of the respective BTRFS. True /etc/fstab is a lot simpler, but systemd-mount units allow so much more extra functionality that is not possible by /etc/fstab. As already mentioned very shortly, examples would be: - dependencies on other FS's and paths the mount point depends on. - auto-mounting and auto-unmounting (with configurable delays), according to needs. - automated snapshoting configurable by timer units. - mounting with different user/group ownership's or umasks. - etc It was not a suggestion or request to switch the FS handling in openSUSE from /etc/fstab to systemd-mounts, but IMHO would ofcourse be better and more modern ;) So the main point of this topic was to be able to select where to mount a subvolume of a particular BTRFS on a per subvolume basis.
Comment 6 Tripple Moon 2020-08-21 10:46:52 UTC
I just noticed due to a fresh install of Leap that even-though the installing person selects an BTRFS partition to NOT be automatically mounted at boot, it IS infact auto-mounted anyway including all it's sub-volumes. This topic, the above fact and those listed in https://bugzilla.opensuse.org/show_bug.cgi?id=1175210#c26 made me drop openSUSE as a result.
Comment 7 Ancor Gonzalez Sosa 2020-09-07 11:29:10 UTC
(In reply to Tripple Moon from comment #5) > > So the main point of this topic was to be able to select where to mount a > subvolume of a particular BTRFS on a per subvolume basis. In that regard, as commented by Steffen in comment#4 we have a plan to improve Btrfs handling for Leap 15.3 and beyond. Those changes will start to land in Tumbleweed in the following months. For that part, we can say this is a duplicate of bug#996598, although I'm not marking this as such because bug#996598 points to SLE and this to openSUSE. (In reply to Tripple Moon from comment #6) > I just noticed due to a fresh install of Leap that even-though the > installing person selects an BTRFS partition to NOT be automatically mounted > at boot, it IS infact auto-mounted anyway including all it's sub-volumes. Please, open a separate bug for this issue.