Re: the need for a discoverable sub-volumes specification

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.




[Index of Archives]     [LARTC]     [Bugtraq]     [Yosemite Forum]     [Photo]

  Powered by Linux