Date: Tue, 12 Sep 2017 14:54:11 +0300 From: Andriy Gapon <avg@FreeBSD.org> To: freebsd-geom@FreeBSD.org Subject: "unspoilable" geom labels Message-ID: <648bcd86-5ef8-b58e-ed04-48880f867fc0@FreeBSD.org>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?648bcd86-5ef8-b58e-ed04-48880f867fc0>