"unspoilable" geom labels

Andriy Gapon avg at FreeBSD.org
Tue Sep 12 11:55:13 UTC 2017


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).

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.


-- 
Andriy Gapon


More information about the freebsd-geom mailing list