"unspoilable" geom labels

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

"unspoilable" geom labels

Andriy Gapon

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
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-geom
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: "unspoilable" geom labels

Warner Losh
On Tue, Sep 12, 2017 at 5:54 AM, Andriy Gapon <[hidden email]> 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
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-geom
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: "unspoilable" geom labels

Andriy Gapon
On 12/09/2017 16:28, Warner Losh wrote:
> 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.

I noticed that change, thanks!
There is one thing that, in my opinion, is not perfect about the aliases unless
I misunderstand the code.  It's that unlike the current approach the aliasing is
not automatically propagated up the GEOM graph and each geom class needs to be
made aware of the aliases.  I mean that currently we create a new geom that
carries the label name and all the tasting, etc automatically happens for.  It
has its own problems as we know, but there is a lot of auto-magic too.
With the aliases there are no additional geoms, so any classes attaching on top
of geoms with aliases need to handle the aliases.  E.g. the partition classes
need to create an alias for each partition, etc.

Also, the aliases seem to be rather adequate for the userland consumers, but
they seem to be not as convenient for the in-kernel consumers that expect the
names to be names of GEOM providers.

But maybe I am extrapolating too much from the existing code and the bigger
design for the GEOM aliases handles the mentioned issues.

--
Andriy Gapon
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-geom
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: "unspoilable" geom labels

Andriy Gapon
In reply to this post by Warner Losh
On 12/09/2017 16:28, Warner Losh wrote:
> 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.

I mean that maybe it's not exactly the job of a function like cam_get_device(),
maybe it's a job if its callers (like camcontrol), but at the very least we
could check if /dev/$name is a symlink and resolve it.  I assume that the valid
device names always corresponding devices entries under /dev.

And, yes, mapping a GEOM label to an original name is harder than it should be
with the current implementation.  Maybe it would be easier with labels
implemented as aliases.

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

I agree.  Maybe such a method would be a good thing to have regardless of the
labels implementation.

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

I think that this is a little bit different issue.  I think that getting from
e.g. /dev/diskid/DISK-MK0351YVKNNX3A to e.g. /dev/ada77 should be sufficient for
most userland utilities.

--
Andriy Gapon
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-geom
To unsubscribe, send any mail to "[hidden email]"