geom_label: Use provider aliasing to alias upstream geoms

[cem]

Summary

For synthetic aliases (just pseudonyms inferred from metadata like GPT or
UFS labels, GPT UUIDs, etc), use the GEOM provider aliasing system to create
a symlink to the real device instead of creating an independent device.
This makes it more clear which labels and devices correspond, and we can
safely have multiple labels to a single device accessed at once.

The confusingly named geom_label on-disk construct continues to behave
identically to how it did before.

This requires teaching GEOM's provider aliasing about the possibility
that aliases might be added later in time, and GEOM's devfs interaction
layer not to worry about existing aliases during retaste.

Test Plan

# mount
/dev/gpt/rootfs on / (ufs, local, noatime, soft-updates)
devfs on /dev (devfs)

# ls /dev/gpt*/* /dev/vtbd0* /dev/ufs*/* -l
lrwxr-xr-x 1 root wheel       10 May 22 20:18 /dev/gpt/bootfs -> ../vtbd0p1
lrwxr-xr-x 1 root wheel       10 May 22 20:18 /dev/gpt/rootfs -> ../vtbd0p3
lrwxr-xr-x 1 root wheel       10 May 22 20:18 /dev/gpt/swapfs -> ../vtbd0p2
lrwxr-xr-x 1 root wheel       10 May 22 20:18 /dev/gptid/4d021bab-f468-11e8-8c36-0cc47ad8b808 -> ../vtbd0p1
lrwxr-xr-x 1 root wheel       10 May 22 20:18 /dev/gptid/4d021bb1-f468-11e8-8c36-0cc47ad8b808 -> ../vtbd0p2
lrwxr-xr-x 1 root wheel       10 May 22 20:18 /dev/gptid/4d021bb5-f468-11e8-8c36-0cc47ad8b808 -> ../vtbd0p3
lrwxr-xr-x 1 root wheel       10 May 22 20:18 /dev/ufs/rootfs -> ../vtbd0p3
lrwxr-xr-x 1 root wheel       10 May 22 20:18 /dev/ufsid/5c00d59e0ec74dab -> ../vtbd0p3
crw-r----- 1 root operator 0, 49 May 22 20:18 /dev/vtbd0
crw-r----- 1 root operator 0, 51 May 22 20:18 /dev/vtbd0p1
crw-r----- 1 root operator 0, 54 May 22 13:18 /dev/vtbd0p2
crw-r----- 1 root operator 0, 57 May 22 13:18 /dev/vtbd0p3

[imp]

I think there be dragons here.

sys/geom/geom_dev.c

412 ↗

(On Diff #72146)

So what happens when labels change? Eg I've labeled some partition fred. Then I label it wilma and a different one fred?

sys/geom/geom_subr.c

656 ↗

(On Diff #72146)

This is good no matter what we do

sys/geom/label/g_label.c

393 ↗

(On Diff #72146)

Does this mean the symlinks disappear?

414 ↗

(On Diff #72146)

this is a new check? I don't see it moved from elsewhere... Not that that's bad, just wondering

427 ↗

(On Diff #72146)

why?

[cem]

Thanks for taking a look!

sys/geom/geom_dev.c

412 ↗

(On Diff #72146)

For the kinds of aliases this covers, that means rewriting a partition table. Doing so spoils the provider and everything is retasted from there, I think.

sys/geom/label/g_label.c

393 ↗

(On Diff #72146)

This is moving lines formerly at 355-358 inside the condition where we found a real on-disk geom_label. They are not new in the revision.

The idea is that for labels that are not a real geom_label, we can keep the symlinks even with a consumer with write access -- they all point at the same unique cdev.

In the case where a geom has both an on-disk geom_label and other labels ... yeah, it might not create the symlinks. Possibly this should insead be:

if (pp->acw == 0)
    g_label_create(...);

I've never used the geom_label on-disk object and I'm not sure why one would anymore. UFS or GPT labels seem like a better fit today. So I mostly tried to leave the on-disk label objects alone.

414 ↗

(On Diff #72146)

It's the same check as in g_label_create(), but the other code is substantially different. It could be subroutined out of both.

427 ↗

(On Diff #72146)

Otherwise it never gets tasted, and never creates the devfs alias. If you have / on an alias label, boot times out during mountroot.

(g_provider_add_alias just throws the new string on a linked list; it doesn't create any first-class geom objects or cause geom_dev to retaste the provider.)