Re: Fun with SSD and GPT wedges

[Greg Troxel <gdt%lexort.com@localhost>]

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.