Re: Fun with SSD and GPT wedges

[mlelstv%serpens.de@localhost (Michael van Elst)]

rnestor%mac.com@localhost (Robert Nestor) writes:

>*) GPT and DKCTL merrily allow me to create wedges that can?t be mapped because the /dev nodes don?t exist.

You can also plug in new disks (e.g. USB) without having the /dev nodes
to use them. There are only a small number of nodes pre-created. Creation
of missing /dev nodes can be automatized by running devpubd, you could
also run MAKEDEV.

Of course the 16 pre-created /dev nodes for wedges might not be enough
for some people. I didn't reach that limit until I wrote examples on
how to use them.


>*) The SSD is so fast that after creating wedges and even listing them, I find I can?t newts them until the buffers get flushed which dkctl does with the synccache command.

You can use a wedge immediately (assuming there is a /dev node). If you
hot-plug a new disk there is a small delay until autodiscovered wedges
are created, but when creating wedges with dkctl or when using gpt
(which runs dkctl internally), this is a synchronous operation.

dkctl synccache lets you prepare to remove a hot-plug disk, it has
nothing to do with wedges.

The delay between attaching a disk and wedge autodiscovery is also
visible for virtual disks, e.g. disks created by vndconfig or cgdconfig.
Scripts that prepare images using vnd need to handle this, but dkctl
synccache doesn't help except by adding a short delay, a simple sleep
command has the same effect (and is as unreliable).


> This also happens after completing the newts operation; the newly formatted wedge can?t be mounted until the disk cache is flushed.

It can be mounted immediately and there is no difference between wedges
and regular disks. That would even be true when the device close operation
wouldn't already imply a cache flush.


>*) GPT and DKCTL happily allow me to destroy, recreate (or mis-create) wedges on disk(s) with wedges that are currently mounted in the running system.

Wedges that are mounted are not destroyed or recreated. You can rewrite
the partition table with gpt, even remove entries that correspond to wedges
that are in use or create new entries that conflict. But a wedge that is
mounted (the dkN device) will not go away and no wedge will be created
that would conflict. Only after you unmount the wedges you can run
dkctl makewedges to remove and create wedges for those GPT entries that
were ignored. In fact, all unused wedges for the disk will be removed
and re-created according to the partition table. The newly created wedges
then might have different unit numbers than before.

So while you can remove partitions from the partition table that are
in use, it doesn't have the effect you imply. This is also no different
from modifying a traditional disklabel or changing a MBR partitions
using fdisk.


Things are different for unplugging (and re-plugging) a disk. Unplugging
will detach the disk device which will forcefully destroy associated
wedges and existing mounts will be dead so that every operation results
in an I/O error. 
You can also detach the disk device with drvctl -d to the same effect
but which isn't anything special for wedges, it would be very similar
for disk slices (e.g. wd0a) and mounts using them.


>*) I had been using the ?name=? parameter in both newts and mount with the wedges.  This worked fine for spinning disks, but I see all sorts of random failures when the wedges are on SSD.

The system doesn't make any difference between SSDs and spinning disks,
regarding wedges or anything else.


> Maybe this is related to a disk block buffering issue, not sure.  My workaround is to figure out which DKn wedge corresponds to the name using dkctl, and specify the wedge by /dev/dk? for newts and mount.

Specifying a name just does an immediate lookup of the dk device. It's
exactly like doing the lookup with dkctl and then using the dk device
because that's what using a name is (it's not running the dkctl command
but calling the same system function called by dkctl).


Greetings,
-- 
-- 
                                Michael van Elst
Internet: mlelstv%serpens.de@localhost
                                "A potential Snark may lurk in every tree."