GPT as default?

Dag-Erling Smørgrav des at
Mon Apr 23 18:32:58 UTC 2007

Marcel Moolenaar <xcllnt at> writes:
> On Apr 23, 2007, at 12:09 AM, Dag-Erling Smørgrav wrote:
> > Marcel, my words may have been poorly chosen, but I've been using GPT
> > for several years, and I've reported these issues (and others) to you
> > several times over the course of those years and witnessed your
> > complete lack of interest.
> Yes, your words were poorly chosen and you continue to show poor
> judgement. I have exactly 1 thread in my mailbox where I discuss
> GPT with you and that problem has been resolved.

Yes, it was eventually resolved.  You ignored my initial report.  I
bugged you about it, and we had a fairly fruitful conversation during
which I pinpointed the exact change which had broken GPT.  That was
five months - to the day - before the bug, an overly-restrictive
sanity check which prevented GEOM_GPT from recognizing its own GPTs,
was finally fixed.

> I fail to see how that's several times over the course of years
> and I fail to see how that represents a complete lack of interest.
> What else did you send me mail about?

The fact that it's not possible to view or modify the partition table
while partitions are mounted.

> In an attempt to close the gap between us, let me ask you this:
> What's the cleft between g_part and the other GEOM classes?
> In what way do you think I'm hell-bent to increase that what
> I don't know?

I should have said "the gap between $GPT and other GEOM classes",
where $GPT is "whichever GEOM class currently implements GPT support".

We have a fairly large number of GEOM classes, and right now they fall
into two categories:

 1) those that are configured using a geom(8) plugin: gcache, gconcat,
    geli, gjournal, glabel, gmirror, gmultipath, gnop, graid3, gshsec,

 2) those that aren't: $GPT, gbde and gvinum

(there's a third category - GEOM classes which replace legacy code and
interface with legacy applications such as fdisk(8) and bsdlabel(8) -
but it isn't relevant here)

The fact that GEOM_GPT was in the second category was understandable
given that it was written two years before geom(8), but now that we
*do* have geom(8) I believe it is in everyone's interest to use it.
Yes, *your* interests as well, because it really *is* that easy to
write a geom(8) plugin if your class implements the necessary verbs;
you'll spend less time on the code than on the man page.

Dag-Erling Smørgrav - des at

More information about the freebsd-current mailing list