Bug 1203027 - No way of setting mount points for btrfs subvolumes in YaST
No way of setting mount points for btrfs subvolumes in YaST
Status: NEW
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: YaST2
Current
Other Other
: P5 - None : Normal (vote)
: ---
Assigned To: YaST Team
Jiri Srain
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2022-09-01 13:40 UTC by Richard Brown
Modified: 2022-11-02 13:12 UTC (History)
3 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Richard Brown 2022-09-01 13:40:03 UTC
If you are creating btrfs subvolumes in YaST partitioning, expert mode, during the installation of a TW/MicroOS machine, there is no opportunity to set a mount point for them

The only options are Path, noCoW and limiting the size

This effectively makes it impossible to customise the btrfs partitioning in any meaningful way, such as relocating subvolumes to a different physical disk or adding new subvolumes are mounting them in a suitable location
Comment 1 Michal Filka 2022-09-07 06:48:00 UTC
This sounds more like a feature request but ...

@Ancor
Is there any way how to do more advanced actions with btrfs subvolumes in expert partitioner? Or is there any plan (not) to implement that?
Comment 2 Ancor Gonzalez Sosa 2022-09-07 07:44:30 UTC
(In reply to Michal Filka from comment #1)
> This sounds more like a feature request but ...
> 
> @Ancor
> Is there any way how to do more advanced actions with btrfs subvolumes in
> expert partitioner? Or is there any plan (not) to implement that?

There are plans to fully redesign that part. We even have some cards at Trello which represents part of the plans (we would like to even go further):

- https://trello.com/c/4LaUUaD6/517-partitioner-proper-handling-of-mounting-subvolumes
- https://trello.com/c/608EeCYK/518-proper-nesting-of-subvolumes

As you can see, some of those cards are 2 years old. :-(

Unfortunately, the team resources are limited and there is always another priority that prevents us from jumping into the much needed revamp of subvolumes management. Nowadays those priorities include other areas of the installer, Cockpit on ALP and many other things.

So yes there are plans. But being realistic... and don't see that happening in the following year. :-(
Comment 3 Richard Brown 2022-09-07 08:20:18 UTC
(In reply to Michal Filka from comment #1)
> This sounds more like a feature request but ...

Given all of the subvolumes openSUSE/YaST/we make by default on every system all have defined mountpoints, I would argue that defining mountpoints for any additional subvolumes is something any user should expect to do. And given users can't do that, then I'd say the lack of mountpoints is a glaring bug, not a request for new features.

Users should be able to define subvolumes just the same way the installer already does.
Comment 4 Ancor Gonzalez Sosa 2022-09-07 09:25:00 UTC
(In reply to Richard Brown from comment #3)
> 
> Users should be able to define subvolumes just the same way the installer
> already does.

Actually they can. The current limitations are shared by the users and by the installer. As documented here[1] a subvolume in the control file is also limited to defining "path", "copy_on_write" and "archs".

With the current implementation of libstorage-ng, the mount point of a subvolume is always auto-calculated from the mount point of the file-system and the path of the subvolume.

That's one of the several things that would need to be changed in order to unleash all the potential for subvolume configuration.

[1] https://github.com/yast/yast-installation/blob/master/doc/control-file.md#the-volumes-subsection
Comment 5 Arvin Schnell 2022-09-07 10:34:30 UTC
(In reply to Ancor Gonzalez Sosa from comment #4)

> With the current implementation of libstorage-ng, the mount point of a
> subvolume is always auto-calculated from the mount point of the file-system
> and the path of the subvolume.

AFAIS there is not such a limitation in libstorage-ng.
Comment 6 Richard Brown 2022-09-07 10:47:54 UTC
(In reply to Ancor Gonzalez Sosa from comment #4)
> With the current implementation of libstorage-ng, the mount point of a
> subvolume is always auto-calculated from the mount point of the file-system
> and the path of the subvolume.

Am I totally mis-remembering stuff but isn't there a general over-arching philosophy with YaST that when there is something auto-calculated or auto-decided by YaST, there should be some way of correcting any mistakes/unwanted decisions made there?

Isn't that why the Installation Summary screen lets you review everything YaST is doing before the install starts?

The fact that YaST is auto-calculating mount points for subvolumes and not giving users a chance to correct any mistakes and/or set mount points for any additional subvolumes sure still feels like a bug to me that runs counter to how we typically do everything else in YaST...
Comment 7 Ancor Gonzalez Sosa 2022-09-07 13:26:51 UTC
(In reply to Arvin Schnell from comment #5)
> 
> AFAIS there is not such a limitation in libstorage-ng.

You are right. My memory messed up things. The only limitation "imposed" by libstorage-ng regarding advanced subvolume handling (which YaST cannot perform anyways) is the mount options, which right now are enforced to always be subvol=whatever_path.

I somehow messed that up with mount points.
Comment 8 Ancor Gonzalez Sosa 2022-09-07 14:27:50 UTC
BEWARE: philosophical conversation/digression ahead (not really useful to get the main issue addressed).

(In reply to Richard Brown from comment #6)
> 
> Isn't that why the Installation Summary screen lets you review everything
> YaST is doing before the install starts?

Mostly true. The "everything" word is the only part that is a bit over the top. ;-) YaST cannot do everything that is technically possible in the system.

As you mention, the user can always jump to the corresponding screen to correct unwanted decisions made by the automatic proposals... But, of course, the user can only modify those things that are supported by YaST. Whatever is not supported by YaST, falls out of that "everything". ;-)

Several examples: YaST doesn't have the ability to configure LUKS2 unlocking via TPM2, YaST doesn't have the ability to define several mount points for the same block device, YaST doesn't have the ability to configure LVM cache (only bcache is supported) and YaST doesn't have the ability to define a subvolume whose mount point is not below the mount point of its corresponding Btrfs file-system.

So there is no screen where the user can jump to "correct" those aspects of the proposal... because YaST can't simply do those things.

In the TPM2 example, is not that YaST decided to use a password instead of TPM2 for LUKS2 unlocking. It's simply that using a passphrase is the only way YaST knows. So the user cannot "correct" the proposal to use a different unlocking mechanism, even if that is something that can perfectly be done manually. We are not talking about the automatic proposal choosing the wrong option, we are talking about YaST limitations and lack of features. 

In the same way, subvolumes in YaST have been historically limited to just be mounted below its file-system according to the path of the subvolume (so they are treated as subdirectories on steroids). It has been like that since Btrfs was introduced in the distribution. YaST has never offered the possibility to adjust the mount point or the mount options of a subvolume in a completely independent and arbitrary way. Cannot be done with the Expert Partitioner, cannot be done with AutoYaST, cannot be configured in the control file and, of course, the installer cannot propose it automatically.

> The fact that YaST is auto-calculating mount points for subvolumes and not
> giving users a chance to correct any mistakes and/or set mount points for
> any additional subvolumes sure still feels like a bug to me that runs
> counter to how we typically do everything else in YaST...

I disagree with reasoning done to get to the idea that the current subvolume handling goes counter to how we do things in YaST (already explained). Having said that, I don't think it makes a big difference calling it a bug or a (lack of) feature. That doesn't change the fact that allowing totally arbitrary mount points (and mount options) per subvolume implies changing the whole historical approach of YaST to subvolumes. That means deep changes would be needed in YaST. Changes in the user interface, changes in the AutoYaST schema and, of course, internal changes.

We really want to improve that part, but sadly we have not found time in the last couple of years because the people who sets the priorities always had something more pressuring.
Comment 9 Richard Brown 2022-09-07 17:14:28 UTC
(In reply to Ancor Gonzalez Sosa from comment #8)
> BEWARE: philosophical conversation/digression ahead (not really useful to
> get the main issue addressed).
> 


> In the TPM2 example, is not that YaST decided to use a password instead of
> TPM2 for LUKS2 unlocking. It's simply that using a passphrase is the only
> way YaST knows. So the user cannot "correct" the proposal to use a different
> unlocking mechanism, even if that is something that can perfectly be done
> manually. We are not talking about the automatic proposal choosing the wrong
> option, we are talking about YaST limitations and lack of features. 
> 
> In the same way, subvolumes in YaST have been historically limited to just
> be mounted below its file-system according to the path of the subvolume (so
> they are treated as subdirectories on steroids). It has been like that since
> Btrfs was introduced in the distribution. YaST has never offered the
> possibility to adjust the mount point or the mount options of a subvolume in
> a completely independent and arbitrary way. Cannot be done with the Expert
> Partitioner, cannot be done with AutoYaST, cannot be configured in the
> control file and, of course, the installer cannot propose it automatically.

Except..YaST doesn't mount the subvolumes according to the path of the subvolume
The path of the default subvolumes is /@/$foo

YaST isn't mounting them as /@/$foo for all the default subvolumes, but doing some magic to mount them all as /$foo

This magic _CAN_ be configured by the control file by the following variable

<btrfs_default_subvolume> (usually @)

subvolumes $foo are defined by the <subvolumes> and <subvolume> parameters

YaST then does its magic munging <btrfs_default_subvolume> and <subvoulmes> together to make its automatic proposal...and if users don't like it..users be damned.. 

This is why I consider this bug a bug and not a feature request.

> 
> > The fact that YaST is auto-calculating mount points for subvolumes and not
> > giving users a chance to correct any mistakes and/or set mount points for
> > any additional subvolumes sure still feels like a bug to me that runs
> > counter to how we typically do everything else in YaST...
> 
> I disagree with reasoning done to get to the idea that the current subvolume
> handling goes counter to how we do things in YaST (already explained).
> Having said that, I don't think it makes a big difference calling it a bug
> or a (lack of) feature. That doesn't change the fact that allowing totally
> arbitrary mount points (and mount options) per subvolume implies changing
> the whole historical approach of YaST to subvolumes. That means deep changes
> would be needed in YaST. Changes in the user interface, changes in the
> AutoYaST schema and, of course, internal changes.
> 
> We really want to improve that part, but sadly we have not found time in the
> last couple of years because the people who sets the priorities always had
> something more pressuring.
Comment 10 Michal Filka 2022-09-13 06:39:30 UTC
The fix will be part of long term refactoring planned for the area
Comment 11 Markus Elfring 2022-11-02 13:12:13 UTC
I became also curious how affected software components will be improved further.