Re: Fun with SSD and GPT wedges

[John Nemeth <jnemeth%cue.bc.ca@localhost>]

On Feb 12,  7:57pm, Greg Troxel 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

     gpt(8) does not create the wedge, it simply calls the same
ioctl() that "dkctl makewedges" does.  The manpage for dkctl(8) says:

     makewedges          Delete all wedges configured on the specified disk,
                         and autodiscover the wedges again.  Wedges that are
                         in use are not deleted and conflicting or overlapping
                         wedges are not created.  You need to list wedges to
                         find out what has changed.

} partition that it removes.  And when destroying a GPT label, it should

     Wedges that are not mounted/open are deleted.

} first remove each partition, and thus remove each wedge.

     Keep in mind that original poster says that he destroys the
GPT by zeroing out the first few sectors of the disk.  Besides
being the wrong way to do, it is pretty obviously that gpt(8) isn't
involved (it is most likely dd(1) although there are other ways to
do it).  Also, the manpage for gpt(8) says:

     gpt destroy [-r] device ...
             The destroy command allows the user to destroy an existing,
             possibly not empty GPT.

It is up to the user to delete the partitions first if they so wish.

} 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.

     What do you mean by "rescanned"?  Normally with disklabels
there are no wedges, unless you create them yourself or use the
DKWEDGE_METHOD_BSDLABEL kernel option.

}-- End of excerpt from Greg Troxel