From nobody Thu Jun 22 00:52:15 2023 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Qmhfk028Jz4fxVM for ; Thu, 22 Jun 2023 00:52:30 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com [IPv6:2a00:1450:4864:20::629]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Qmhfj5WKcz477y for ; Thu, 22 Jun 2023 00:52:29 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ej1-x629.google.com with SMTP id a640c23a62f3a-988f066f665so414733866b.2 for ; Wed, 21 Jun 2023 17:52:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20221208.gappssmtp.com; s=20221208; t=1687395147; x=1689987147; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=EDzahfPL2sQJbpXFsMKqaq+S+AWgqpaqQ676s03xeEk=; b=iKrGL/qxeYyBkA/9KSFAlc4r+x4S3JYc2Nw5u7oNK6LxXOYq3qJXLmGB5JngzI4YY+ Ra+g5/KwIZUbnS2AJMPx5uwbUG8su4enioBboJ0Ey4shc+eRiriEno/uRQ2htZ2w+DDi M/rPSvZ7ujI0s2PAYnunSB4zKXdRtdzyRYNPLuIlZnPKhIZoedg/hMR8LkczqS1jJgA8 hWMJ8iqvskCu4EqSVshofzyxC7kdhk4Md1HwplzUDNPpFID7vaJSotk2IF8E+7DKMk1O KBBTOZLnRW5fsIjlIjREINVuV/rFxOL/KRNw5SBJy94QnfuFkX6awiJeynoBjU3HOIbS 9eVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687395147; x=1689987147; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=EDzahfPL2sQJbpXFsMKqaq+S+AWgqpaqQ676s03xeEk=; b=LM3hWlRubpiPptXKJhUKLMXopCV18frZYnsYNCCdMUR966xHDC5R5LS3kYV85XXWjV jdfiwG0+5VJ5MZp3TeO3f0SW//ZnjIvz+wBy5OyCRiRZrpgypCa5zQN7nZLvwp9tVSwk M6okaKVr9hpV9AWRfB4rUK7X/GQ+P3571OoZKNxZyiZyNxDwPrr0qz7Dq+s8N6vukj3I Gd+vCV5y9kKtC7l21gffy0wfrTrzuvJmJK8Snd3Rzc+xH2ZNEsp9pWuXr/Rjtp3q2tgR pAhm3UdxqcA36VZQXDNprxDavac7f5VRMPjsXUHaYLiBQOAx3DNNMUXGx9H2p3Vepiy5 vloA== X-Gm-Message-State: AC+VfDwjNxTzuxo+y70/LjS7e4FzbXXzqRVZRurwsJ+kJhcDfZat/q9l fkJYJe/qA95VoEhh0YDyfxxrKKZSoHx6oKYVbQ9/9gLRsHuWjpHB X-Google-Smtp-Source: ACHHUZ6Li8/S9dFs+dN38/wW0aKZOBrvWCB8atq+FfscmyjVIqpNg6k41eTPExb3md6NsBLMBqmjsOTKceiwy++Ysn8= X-Received: by 2002:a17:907:7207:b0:988:8786:f56c with SMTP id dr7-20020a170907720700b009888786f56cmr9917927ejc.0.1687395146552; Wed, 21 Jun 2023 17:52:26 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Wed, 21 Jun 2023 18:52:15 -0600 Message-ID: Subject: Re: Where did the nvd devices go? To: Kevin Oberman Cc: FreeBSD Current Content-Type: multipart/alternative; boundary="0000000000004e6c6e05fead4c4a" X-Rspamd-Queue-Id: 4Qmhfj5WKcz477y X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N --0000000000004e6c6e05fead4c4a Content-Type: text/plain; charset="UTF-8" On Wed, Jun 21, 2023, 6:22 PM Kevin Oberman 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 imp@freebsd.org about why. -- > Kevin Oberman, Part time kid herder and retired Network Engineer > E-mail: rkoberman@gmail.com > PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 > --0000000000004e6c6e05fead4c4a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Jun 21, 2023, 6:22 PM Kevin Oberman <rkobe= rman@gmail.com> 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 sym= link of nvd to nda happened, but after updating my system to main-n263630-a= b3e6234ab6e, at least geom related commands no longer function using nvd0p?= . I hit this when trying to use gpart and geli. gpart claims "gpart: N= o such geom: /dev/nvd0." geli responds (after entering a passphrase) &= quot;geli: Provider not found: "/dev/nvd0p7"My previous system ve= rsion 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 ther= e persistent config that failed?

Was this intentional? If so, why was this change made?= =C2=A0 If not, could it be fixed? Since I usually use geli with the /dev/gp= t devices, I didn't notice it right away, but it could certainly=C2=A0 = surprise many users.

All these questions are answered in the UPD= ATING 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=3D1
	in your loader.conf or add `options NVME_USE_NVD=3D1` to your kernel
	config. To disable the nvd compatibility aliases, add
	kern.cam.nda.nvd_compat=3D0 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 imp@freebsd.org about =
why.

--
= Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail:= rkoberman@gmail.com
PGP Fingerprint: D03FB98= AFA78E3B78C1694B318AB39EF1B055683
=
--0000000000004e6c6e05fead4c4a--