Officially document the format of names under /dev/mapper

[DemiMarie]

To quote man 8 lvm (formatting mine):

Links or nodes in /dev/mapper are intended only for internal use and the precise format and escaping might change between releases and distributions. Other software and scripts should use the /dev/VolumeGroupName/LogicalVolumeName format to reduce the chance of needing amendment when the software is updated. Should you need to process the node names in /dev/mapper, you may use dmsetup splitname to separate out the original VG, LV and internal layer names.

However, this presents a serious problem for writers of generic tools, which may not necessarily know anything about LVM2. Such software will likely use the kernel’s name under /dev/mapper. For instance, lsblk displays the names under /dev/mapper, not the ones in VG/LV format.

[zkabelac]

Each device type has it's own set of rules - whoever writes any generic tool needs to learn about them - no way around this.

For lvm2 - we present /dev/vgname/lvname as the mechanism to tell apart 'public' LVs (those users should be using) and 'private' (those users should not try to access - i.e. individual raid legs, metadada device).
'/dev/mapper' is 'all symlinks for all DM devs' - where a very skilled admin can see all named links.
All kernel DM devs are preseted with /dev/dm-XXX.

Other subsystems like dm-multipath, dm-crypto, stratis,.... have their own rules...

Yes we would like to see other user-space tools to be complaint with our /dev/vg/lv naming for LVs - however we have no control over them...

[DemiMarie]

Each device type has it's own set of rules - whoever writes any generic tool needs to learn about them - no way around this.

To do that, the author need to know what the rules are, and have a reasonable expectation that those rules will not change out from under them. qubesd already hard-codes its believe as to what the rules are for LVM, because I did not find a better option.

For lvm2 - we present /dev/vgname/lvname as the mechanism to tell apart 'public' LVs (those users should be using) and 'private' (those users should not try to access - i.e. individual raid legs, metadada device). '/dev/mapper' is 'all symlinks for all DM devs' - where a very skilled admin can see all named links. All kernel DM devs are preseted with /dev/dm-XXX.

Other subsystems like dm-multipath, dm-crypto, stratis,.... have their own rules...

The rules for dm-crypt are simple (/dev/mapper/XYZ IS the public API), but I have no clue about the others. If there was simple and thread-safe C API for figuring things out, I might be willing to use it, but to the best of my understanding, no such library exists.

[zkabelac]

Each device type has it's own set of rules - whoever writes any generic tool needs to learn about them - no way around this.

To do that, the author need to know what the rules are, and have a reasonable expectation that those rules will not change out from under them. qubesd already hard-codes its believe as to what the rules are for LVM, because I did not find a better option.

It's hard task - I've already seen myself about 20 projects trying to make universal device managing software....
None of them really worked well.

For lvm2 - we present /dev/vgname/lvname as the mechanism to tell apart 'public' LVs (those users should be using) and 'private' (those users should not try to access - i.e. individual raid legs, metadada device). '/dev/mapper' is 'all symlinks for all DM devs' - where a very skilled admin can see all named links. All kernel DM devs are preseted with /dev/dm-XXX.
Other subsystems like dm-multipath, dm-crypto, stratis,.... have their own rules...

The rules for dm-crypt are simple (/dev/mapper/XYZ IS the public API), but I have no clue about the others. If there was simple and thread-safe C API for figuring things out, I might be willing to use it, but to the best of my understanding, no such library exists.

dm-crypt is more simple with it's device usage and doesn't resolve all issues as lvm2 does (i.e. private/public) and has no concept of volume management...

And yeah we would also like to see some well written project handling all sorts of block devices....
(as we know how hard is that even when we focus on lvm only...)
Also note a lot of lvm2 code complexity is in handling devices...

[DemiMarie]

On further thought, the main reason I need to know the format of names under /dev/mapper is so that I can avoid colliding with them. I need to be able to generate names that are guaranteed to not be the name of any LVM2 logical volume.

[zkabelac]

lvm2 strictly uses 'vgname-lvname' where '-' in name is escaped in '--' way.
DM NAME is up to 128 characters.
Same with DM UUID - where lvm2 uses 'LVM-' prefix (we would like to see each DM subsystem would use some rules - but we can't enforce it...)

While device is 'active' - it can be renamed - but it can't change its UUID - for that change device must
be deactivated and activated again with new UUID.

There are many ways, how to generate non-colliding names... although usually such names are not readable for humans ;) But I think here you are looking for problems which do not really exist in practice....

[DemiMarie]

lvm2 strictly uses 'vgname-lvname' where '-' in name is escaped in '--' way.
DM NAME is up to 128 characters.
Same with DM UUID - where lvm2 uses 'LVM-' prefix (we would like to see each DM subsystem would use some rules - but we can't enforce it...)

That is enough information for me, thanks!