From owner-freebsd-fs@FreeBSD.ORG  Mon Oct 24 11:48:21 2011
Return-Path: <owner-freebsd-fs@FreeBSD.ORG>
Delivered-To: freebsd-fs@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id E36071065673;
	Mon, 24 Oct 2011 11:48:20 +0000 (UTC)
	(envelope-from 000.fbsd@quip.cz)
Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4])
	by mx1.freebsd.org (Postfix) with ESMTP id 6ECC58FC18;
	Mon, 24 Oct 2011 11:48:20 +0000 (UTC)
Received: from elsa.codelab.cz (localhost [127.0.0.1])
	by elsa.codelab.cz (Postfix) with ESMTP id 31CAC28430;
	Mon, 24 Oct 2011 13:48:19 +0200 (CEST)
Received: from [192.168.1.2] (ip-86-49-61-235.net.upcbroadband.cz
	[86.49.61.235])
	(using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits))
	(No client certificate requested)
	by elsa.codelab.cz (Postfix) with ESMTPSA id 12A4C28428;
	Mon, 24 Oct 2011 13:48:18 +0200 (CEST)
Message-ID: <4EA55081.6050006@quip.cz>
Date: Mon, 24 Oct 2011 13:48:17 +0200
From: Miroslav Lachman <000.fbsd@quip.cz>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
	rv:1.9.1.19) Gecko/20110420 Lightning/1.0b1 SeaMonkey/2.0.14
MIME-Version: 1.0
To: Pawel Jakub Dawidek <pjd@FreeBSD.org>
References: <alpine.BSF.2.00.1110231949380.65073@borg>	<20111024011426.GA57172@icarus.home.lan>	<alpine.BSF.2.00.1110232023400.12166@borg>	<20111024014616.GA57735@icarus.home.lan>	<CAOjFWZ6CdzhQxiOw5ad6G2tfaG=U6WNAeH5rW7Qc6-FqCiU4Wg@mail.gmail.com>
	<20111024091404.GC1640@garage.freebsd.pl>
In-Reply-To: <20111024091404.GC1640@garage.freebsd.pl>
Content-Type: text/plain; charset=ISO-8859-2; format=flowed
Content-Transfer-Encoding: 7bit
Cc: freebsd-fs@freebsd.org
Subject: Re: Anyway to change pool to use the gpt label instead of gptid?
X-BeenThere: freebsd-fs@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Filesystems <freebsd-fs.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-fs>,
	<mailto:freebsd-fs-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-fs>
List-Post: <mailto:freebsd-fs@freebsd.org>
List-Help: <mailto:freebsd-fs-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-fs>,
	<mailto:freebsd-fs-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Oct 2011 11:48:21 -0000

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