|
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> |
| Severity: | Major | ||
| Priority: | P5 - None | CC: | ancor, snwint, suse |
| Version: | Current | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | Other | ||
| URL: | https://trello.com/c/fJ3Jpn8Q/ | ||
| See Also: |
https://bugzilla.opensuse.org/show_bug.cgi?id=1171310 http://bugzilla.opensuse.org/show_bug.cgi?id=1171311 |
||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
|
Description
Tripple Moon
2020-08-12 08:18:55 UTC
Who is 'we'? (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 ;)] 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) '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.
(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. 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. (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. |