Re: Fun with SSD and GPT wedges

[Robert Nestor <rnestor%mac.com@localhost>]

Somewhat related, but the man page on GPT in the example on how to set up a BIOS boot indicates that one should newfs dk?, not rdk?.  A number of people have pointed out to me that I should be running newfs on rdk?, NOT dk?.  This was probably the source of a lot of my problems, but in my defense I was just following the documentation.  :-)

-bob
 
On Feb 12, 2019, at 6:57 PM, Greg Troxel <gdt%lexort.com@localhost> wrote:

> Robert Elz <kre%munnari.OZ.AU@localhost> writes:
> 
>>  | but wiping the GPT header doesn’t seem to always immediately
>>  | free the corresponding wedges.
>> 
>> It doesn't.   You need to be aware of the logical separation here.
>> GPT is a disc partitioning scheme (as are MBR and disklabel) which
>> divides drives into multiple pieces.   Wedges are an OS software
>> reference device which map a range of blocks on a particular device
>> to a /dev name (ie: give a handle by which a piece of disc can be
>> referenced).
>> 
>> Normally, when a drive (which already contains a label) is scanned,
>> any GPT partitions (of suitable types) are connected to wedges so
>> they can be referenced - but you can always just create a wedge for
>> any random piece of a drive without any GPT back end if you like.
>> 
>> With a new drive, as it was originally coded, you would add a new
>> GPT partition, and the gpt command would tell you what you needed
>> to type (or cut&paste) as a dkctl command to create a wedge for the
>> new partition (if you wanted one).
>> 
>> But since just about everyone wants one, that's why they created
>> the partition usually, and since having one command spit out instructions
>> for running another command is kind of weird, when it could just
>> run the command itself, the gpt command was changed to create a
>> wedge when it creates a new partition (that is the in kernel data
>> struct, whether or not it has a /dev/dkN entry available).
>> 
>> Apart from that one concession, the gpt command and wedges are two
>> separate things (and so are MBR and wedges and disklabel and wedges
>> if you use them that way - most people don't as it isn't traditional.)
> 
> I can see how we got here, but the situation seems wrong from a logical
> consistency point of view.  If gpt(8) is going to create wedges on
> adding a new partition, it should delete the wedge corresponding to a
> partition that it removes.  And when destroying a GPT label, it should
> first remove each partition, and thus remove each wedge.
> 
> With disklabels, when the label is scanned then the various abcdefgh
> partitions can be used.  Ideally, when writing the block with the
> disklabel it would be rescanned.
> 
>> That means, that when you no longer want to keep a wedge, you need
>> to dkclt delwedge it to cause the kernel to lose the mapping.  What
>> you do (if anything) with the GPT map on the drive is unrelated.
>> But certainly keeping wedges when you're about to remap the drive
>> space in some different way would cause you all kinds of weirdness.
> 
> Agreed that currently you must, because gpt remove does not drop the
> wedge, one has to do it manually.