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=230246 --- Comment #15 from andrew@tao11.riddles.org.uk --- Just to wrap this up for the record (I explained all this to the OP in another 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 geoms 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 become visible via many different provider paths, such as ada0p1, diskid/DISK-NNNNp1, 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 attach 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 and 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 again.) So this is ultimately, in my view, a "user experience" issue. -- 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>