Anyway to change pool to use the gpt label instead of gptid?

[Miroslav Lachman]

Pawel Jakub Dawidek wrote:
> On Sun, Oct 23, 2011 at 10:58:53PM -0700, Freddie Cash wrote:
>>> This looks like a bug or design oddity in GEOM.  Based on your setup you
>>> should have swap[0-5] and disk[0-5] in /dev/gpt, not just swap[0-5].
>>
>> GEOM shows all providers for a disk/partition that is not in use. Once you
>> acces a disk/partition via a particular provider, all others are hidden.
>> This is to prevent you from accessing a particular disk/paprtition via
>> multiple names.
>>
>> For example, a GPT-partitioned disk could be accessed via the following GEOM
>> providers:
>>    /dev/ada0p1
>>    /dev/gptid/somelongstring
>>    /dev/gpt/some-label
>>    /dev/ufsid/someotherlongstring
>>    /dev/ufs/some-other-label
>>
>> As soon as you mount the filesystem via one of those paths, all the rest are
>> hidden.
>
> This is a bit more complex than that.
>
> Some providers are created based on metadata of the underlying provider.
> When you open the underlying provider for write, all providers that were
> created based on metadata should disappear, because metadata can change
> during the write.
>
> Other providers are not created based on metadata of the underlying
> provider and writing to underlying provider will not change the reason
> for why the former exist.
>
> In your example gpt/<label>  and gptid/<uuid>  are configured in metadata
> of ada0, not ada0p1, so opening ada0p1 should have no effect on
> gpt/<label>  and gptid/<uuid>  existence. On the other hand when you open
> ada0 for write all should disappear.
>
> When it comes to ufs/<label>  ufsid/<id>  providers, they are created
> based on UFS metadata within ada0p1. This means that when you open
> ada0p1 for write they should disappear (UFS file system might be gone
> once you don't writing and if it isn't GEOM will discover this by
> retaste mechanism).
>
> Currently gpt/<label>  and gptid/<uuid>  are not implemented properly, as
> they don't follow the rules I described. They also won't appear
> automatically when partition is labeled, but they should.
> This is because they are implemented as part of the LABEL class
> (glabel(8)) and not as part of the PART class (gpart(8)).
>
> Note that it is not uncommon that the same data is visible through
> several GEOM providers. We don't hide the others for this reason.
> When you open ufs/<label>, ada0p1 will still exist. They
> appear/disappear for other reasons (which I tried to describe above).
>
> There are also some other problems with labeling for metadata data were
> not designed for autodetection, but it is a different story.
>
> All in all, gpt/<label>  and gptid/<uuid>  should be fixed.

If it is known problem and should be fixed, is there a PR for it?
Should I file one?

Miroslav Lachman