Date: Fri, 06 Sep 2019 20:30:50 +0000 From: bugzilla-noreply@freebsd.org To: geom@FreeBSD.org Subject: [Bug 230246] GPT label mishandling Message-ID: <bug-230246-14739-mjRPk3uPWq@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-230246-14739@https.bugs.freebsd.org/bugzilla/> References: <bug-230246-14739@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D230246 --- Comment #15 from andrew@tao11.riddles.org.uk --- Just to wrap this up for the record (I explained all this to the OP in anot= her place): There's no bug in the code as such, the odd behavior is just an artifact of= how geom tasting works, and the fact that it works rather unpredictably when ge= oms are being created and removed while the system is up (rather than at boot time). Specifically, the sort of thing that happens is that a partition might beco= me visible via many different provider paths, such as ada0p1, diskid/DISK-NNNN= p1, gpt/partname, gptid/someuuid, and then if there is existing metadata at the partition's last sector, in this case for gmirror, the mirror geom might at= tach to any of the providers. If it attaches (say) diskid/DISK-NNNNp1, then the exclusive open of the underlying disk causes the gpart instances providing ada0p*, gpt/*, etc. to detach, so those labels go away. This shows up as more of an issue with GPT because the combination of GPT a= nd glabel produces many providers, often inconveniently many. (For example you= can end up with "gmirror stop" failing to work, because as soon as the mirror closes, it becomes visible via another provider and immediately starts agai= n.) So this is ultimately, in my view, a "user experience" issue. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-230246-14739-mjRPk3uPWq>