From owner-freebsd-fs@FreeBSD.ORG  Mon Oct 24 09:14:54 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 EC606106564A
	for <freebsd-fs@freebsd.org>; Mon, 24 Oct 2011 09:14:53 +0000 (UTC)
	(envelope-from pawel@dawidek.net)
Received: from mail.dawidek.net (60.wheelsystems.com [83.12.187.60])
	by mx1.freebsd.org (Postfix) with ESMTP id 1A3BF8FC08
	for <freebsd-fs@freebsd.org>; Mon, 24 Oct 2011 09:14:52 +0000 (UTC)
Received: from localhost (58.wheelsystems.com [83.12.187.58])
	by mail.dawidek.net (Postfix) with ESMTPSA id 22285881;
	Mon, 24 Oct 2011 11:14:49 +0200 (CEST)
Date: Mon, 24 Oct 2011 11:14:04 +0200
From: Pawel Jakub Dawidek <pjd@FreeBSD.org>
To: Freddie Cash <fjwcash@gmail.com>
Message-ID: <20111024091404.GC1640@garage.freebsd.pl>
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>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="SxgehGEc6vB0cZwN"
Content-Disposition: inline
In-Reply-To: <CAOjFWZ6CdzhQxiOw5ad6G2tfaG=U6WNAeH5rW7Qc6-FqCiU4Wg@mail.gmail.com>
X-OS: FreeBSD 9.0-CURRENT amd64
User-Agent: Mutt/1.5.21 (2010-09-15)
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 09:14:54 -0000


--SxgehGEc6vB0cZwN
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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].
>=20
> 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.
>=20
> For example, a GPT-partitioned disk could be accessed via the following G=
EOM
> providers:
>   /dev/ada0p1
>   /dev/gptid/somelongstring
>   /dev/gpt/some-label
>   /dev/ufsid/someotherlongstring
>   /dev/ufs/some-other-label
>=20
> 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.

--=20
Pawel Jakub Dawidek                       http://www.wheelsystems.com
FreeBSD committer                         http://www.FreeBSD.org
Am I Evil? Yes, I Am!                     http://yomoli.com

--SxgehGEc6vB0cZwN
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (FreeBSD)

iEYEARECAAYFAk6lLFwACgkQForvXbEpPzTFHQCfVv8PuxW+xdkTiadGKjM/FCSg
c4IAn1fA6MaY6Kio3KkFvF5GL1LWuMd/
=Gral
-----END PGP SIGNATURE-----

--SxgehGEc6vB0cZwN--