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

[Pawel Jakub Dawidek]

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.

-- 
Pawel Jakub Dawidek                       http://www.wheelsystems.com
FreeBSD committer                         http://www.FreeBSD.org
Am I Evil? Yes, I Am!                     http://yomoli.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20111024/5db90668/attachment-0001.pgp