Date: Mon, 24 Oct 2011 13:48:17 +0200 From: Miroslav Lachman <000.fbsd@quip.cz> To: Pawel Jakub Dawidek <pjd@FreeBSD.org> Cc: freebsd-fs@freebsd.org Subject: Re: Anyway to change pool to use the gpt label instead of gptid? Message-ID: <4EA55081.6050006@quip.cz> In-Reply-To: <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> <20111024091404.GC1640@garage.freebsd.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4EA55081.6050006>