Date: Mon, 24 Oct 2011 11:14:04 +0200 From: Pawel Jakub Dawidek <pjd@FreeBSD.org> To: Freddie Cash <fjwcash@gmail.com> Cc: freebsd-fs@freebsd.org Subject: Re: Anyway to change pool to use the gpt label instead of gptid? Message-ID: <20111024091404.GC1640@garage.freebsd.pl> In-Reply-To: <CAOjFWZ6CdzhQxiOw5ad6G2tfaG=U6WNAeH5rW7Qc6-FqCiU4Wg@mail.gmail.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
--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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20111024091404.GC1640>