[systemd-devel] the need for a discoverable sub-volumes specification

[Christopher Cox]

On 11/3/21 12:52 PM, Chris Murphy wrote:
> There is a Discoverable Partitions Specification
> http://systemd.io/DISCOVERABLE_PARTITIONS/
> 
> The problem with this for Btrfs, ZFS, and LVM is a single volume can
> represent multiple use cases via multiple volumes: subvolumes (btrfs),
> datasets (ZFS), and logical volumes (LVM). I'll just use the term
> sub-volume for all of these, but I'm open to some other generic term.
> 
> None of the above volume managers expose the equivalent of GPT's
> partition type GUID per sub-volume.

You can't trust that information anyway.  At the end of the day, you attempt 
mount a block device.

This gets even more complicated as volumes may nest.  That is, you could have a 
logical volume in LVM that is a phyical volume in a lower context which is part 
of a volume group containing logical volumes.  Now.. probably doesn't make sense 
in most cases to try to take things that far of course.  Perhaps I should have 
used a better combo of layering, like something with logical volumes and 
software RAIDing (plus encryption, etc. lots of dev mapper possibilities).

Let's just say, there's a reason for the explicitness of fstab.  Guessing can be 
done, but at the end of the day, it's going to be a guess.  Could be a very bad 
guess.


> 
> One possibility that's available right now is the sub-volume's name.
> All we need is a spec for that naming convention.
> 
> An early prototype of this idea was posted by Lennart:
> https://0pointer.net/blog/revisiting-how-we-put-together-linux-systems.html
> 
> Lennart previously mentioned elsewhere that this is probably outdated.
> So let's update it and bring it more in line with the purpose and goal
> set out in the discoverable partition spec, which is to obviate the
> need for /etc/fstab.
> 
> 

You'll have to move the "explicit intent" data in the "things" you discover. 
It's not there today and there are good reason why it shouldn't be there.  You 
may not like fstab, but it is an abstraction which prevents making assumptions 
about the underlying block devices.

Not saying you can't make an fstab alternative, but at the end of day, it's an 
fstab alternative (you've just moved things from "here" to "there").  Or, you've 
placed a behavioral assumption onto things that wasn't there before.  And I'd be 
careful about the latter.

A lot of my block devices are partitionless, as the good Lord intended things to be.