Date: Sat, 28 Nov 2015 19:58:19 +0000 (UTC)
From: mlel...@serpens.de (Michael van Elst)
Message-ID: <n3d10r$l9e$1...@serpens.de>
| The correct thing is therefore to drop the dk_getdisklabel call.
| Can you verify that this just solves the problem?
Yes, that works too.
I wondered about that, but wasn't sure if the disklabel read might be
needed for the dkwedge_discover() that immediately follows.
That I can't easily test (and I doubt almost anyone else can either) as
until we get cgd crypto validation that's based upon finding a valid GPT
(rather than, or instead of, a disklabel, or valid ffs) GPT labelled cgds
are not very useful, so I have never tried one.
Nor do I use the "convert labels to wedges" kernel option (whose name
I don't even remember... the thing that would make wd0a appear as dk0
instead). So, if the label read is needed for that, I wouldn't observe
any ill effects.
But for a "regular" cgd, with a disklabel (I install one, even when the
entire cgd is to be one file system) you're right, that (ancient)
dk_getdisklabel() seems to be nothing more than a problem.
kre
ps: incidentally, I even though (dev_t)0 is wd0a, I doubt that the major()
part of it ever gets used, just minor(dev), which is why the PR observed
reading from cgd0 when cgd1 was configured.
