On 06/02/14 13:26, Pawel Jakub Dawidek wrote:
On Mon, Jun 02, 2014 at 11:01:08AM -0700, John-Mark Gurney wrote:
Michael W. Lucas wrote this message on Mon, Jun 02, 2014 at 11:36 -0400:
On Mon, Jun 02, 2014 at 10:45:52AM -0400, Ryan Stone wrote:
On Mon, Jun 2, 2014 at 9:26 AM, Allan Jude <allanj...@freebsd.org> wrote:
It also tends to sometimes hide the gpt label provider on me (not sure
in which cases it does this, but it is annoying)
This happens when something (e.g. zfs) happens to open the diskid
provider instead of the gpt label. For me this ended up being a bit
more than annoying; my swap was mounted in /etc/fstab via a gpt label
so I silently lost my swap when I did an upgrade.
Wait-- one type of one label can hide another?
I thought a big point of labels was to remove ambiguity...
Surprisingly, yes... I didn't think about this, but it's true...
A disk will get exported via two different devices, diskid and normal
da/ada... The tasting will go through and create all the necessary
sub devices, but the problem is that we now have two different paths,
and if something opens the diskid path, then the da/ada paths all
disappear...
This sounds like we need to fix geom to "bind" the two together so
that when one opens, the other doesn't disappear... The problem is
that geom views them as two separate disks when in fact they are the
same... someone who knows geom well should think about how to solve
this problem, as diskid isn't the first time this has happened, just
most prevalent w/ ZFS and diskid.
The problem is that GPT labels (or GPT IDs for that matter) should not
be implemented within GLABEL. This is wrong. It should be implemented as
part of GPART, so that GPART would create ada0p1, gpt/label and
gptid/whatever. Opening one of those should not make the others
disappear then. Only opening ada0 for writting would make them disappear.
Indeed. This would also fix some tasting races, allow programmatic
retrieval of the label device from gpart, and expand label device
support from GPT to all partition schemes supported by gpart (APM, for
instance).
-Nathan
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
