On Wed, Jun 21, 2023, 6:22 PM Kevin Oberman <[email protected]> wrote:
> Well, they are still around, but not functional. They are symlinks to nda
> devices, but the symlinks don't work well.
>
They work for filesystem access.
I have no idea when the symlink of nvd to nda happened, but after updating
> my system to main-n263630-ab3e6234ab6e, at least geom related commands no
> longer function using nvd0p?. I hit this when trying to use gpart and geli.
> gpart claims "gpart: No such geom: /dev/nvd0." geli responds (after
> entering a passphrase) "geli: Provider not found: "/dev/nvd0p7"My previous
> system version was main-n262908-c16e08e5f324.
>
These will work with nda. They should likely work with the nvd aliases, but
don't it seems (though you don't need the /dev/ for geom commands).
Was this just a failure of muscle memory, or was there persistent config
that failed?
Was this intentional? If so, why was this change made? If not, could it be
> fixed? Since I usually use geli with the /dev/gpt devices, I didn't notice
> it right away, but it could certainly surprise many users.
>
All these questions are answered in the UPDATING entry from when I switched
the default:
20230612:
Belatedly switch the default nvme block device on x86 from nvd to nda.
nda created nvd compatibility links by default, so this should be a
nop. If this causes problems for your application, set hw.nvme.use_nvd=1
in your loader.conf or add `options NVME_USE_NVD=1` to your kernel
config. To disable the nvd compatibility aliases, add
kern.cam.nda.nvd_compat=0 to loader.conf. The default has been nda on
all non-x86 platforms for some time now. If you need to fall back,
please email [email protected] about why.
--
> Kevin Oberman, Part time kid herder and retired Network Engineer
> E-mail: [email protected]
> PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
>
