"unspoilable" geom labels

[Warner Losh]

On Tue, Sep 12, 2017 at 5:54 AM, Andriy Gapon <avg at freebsd.org> wrote:

>
> At the moment all GEOM labels are spoilable in a sense that opening a
> provider
> in the write mode spoils GEOM labels that are attached as other consumers.
> The reason for that behavior is that the writer may modify the (meta-)data
> in
> such a way that the label would have to change.
>
> Here is a modest proposal to make some labels "unspoilable".
> Indeed, it's not necessary that the writer is always able to modify the
> label.
> The best example would be the disk ID labels that are based on the disk
> serial
> numbers.  It is not possible to modify the serial number by means of the
> regular
> access to the disk.
> Similarly, the GPT-based labels can not be modified by opening a partition
> for
> writing.  They can be modified only by changing the partition tables which
> requires opening the enclosing disk.
>
> For the sake of completeness, here is an example of a spoilable label: a
> label
> that's based on a filesystem ID that's recorded in a superblock or its
> equivalent.
>
> The goal of this proposal is to make the labels slightly stabler and
> slighly
> more usable.
> A preliminary patch can be found here:
> https://people.freebsd.org/~avg/geom-unspoilable-labels.diff
>
> I'd be first to admit that the proposal is just a minor improvement and
> does not
> solve all the problems with the labels.
> I think that the whole design for the GEOM labels needs to be changed.
> For example, I am not a big fan of adding another NOP geom between a
> driver and
> a real consumer in the I/O path.
> Perhaps, making labels be additional providers of an underlying geom would
> be a
> better solution.  Maybe something else.  Anything to make the GEOM labels
> look
> more like aliases for original GEOM providers.  Because right now they
> look like
> completely independent providers and you have to follow the GEOM graph to
> discover the relations (even if the original provider and its label are
> removed
> by just a single edge).
>

I recently added aliases, and the thought was that once the kinks are
worked out they could also be used for labels and we could eliminate the
extra geom nodes.


> Another thing that seems to be desirable is a better integration between
> CAM
> userland and GEOM.  For instance, I would like to be able to do things like
> camcontrol standby /dev/diskid/DISK-MK0351YVKNNX3A
> Unfortunately, that's not possible at present because the CAM code does not
> expect to see any alias (or a symbolic link) as the device name and the
> name is
> always expected to be in the form <driver><unit>.  It would be good if the
> code
> tried to follow links and it was able to understand GEOM labels / aliases.


The CAM code expects to be able to map the name 'da0' to 'pass14' so it can
send the passthrough devices. It has no clue about device names, apart from
passXXX it has to open to send the commands for the thing named 'da0'. In
fact, it has no clue at all about the upper layers at all. I would argue
that it would be quite difficult, given the current state of geom, to
properly guess. It shouldn't even try. Bad things can only come from
accidentally guessing wrong.

Instead, if you really want this functionality, we should create either an
ioctl to get this information (perhaps in a list for the case of gmirror,
but perhaps not) or a bio attribute that could be synthesized properly. The
third vehicle for this would be to put the attribute in the config for
geom, but that's a bit of a pain.

Then again, you can't easily map an entry from /dev into a device_t that
implements it (if any). You can't map a cam device, even, to a device_t
either, just as far as the SIM if you look hard enough.

Warner