From nobody Sat Sep 23 18:58:53 2023 X-Original-To: stable@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 4RtJMQ6kqWz4v5db for ; Sat, 23 Sep 2023 18:58:58 +0000 (UTC) (envelope-from yuri@aetern.org) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4RtJMQ3Qhbz4sp0 for ; Sat, 23 Sep 2023 18:58:58 +0000 (UTC) (envelope-from yuri@aetern.org) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=aetern.org header.s=fm1 header.b=tb1K619Y; dkim=pass header.d=messagingengine.com header.s=fm2 header.b="J ydV27L"; spf=pass (mx1.freebsd.org: domain of yuri@aetern.org designates 66.111.4.26 as permitted sender) smtp.mailfrom=yuri@aetern.org Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id B4B565C01A8 for ; Sat, 23 Sep 2023 14:58:56 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Sat, 23 Sep 2023 14:58:56 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aetern.org; h=cc :content-transfer-encoding:content-type:content-type:date:date :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm1; t= 1695495536; x=1695581936; bh=807zhHwEPI8vcbiNfLVgksUwBXPeEt+aRX5 XBDjzzhM=; b=tb1K619YbghpaFFJvO8d5GG0z1n8sOxGtjeXlGPyU3hrc6AUQeX lVa8k6JXy1+CO1unsSmSIxETDDV6qaIXR5Q9fkHppHqFEfYaELaFkbk3Kou4Pagw feu/+DsoatNUHArJ11Hm1lehyiIQOpqW6X1rLJzjoUa3LG5avtVhjYtH4ZKtdhHI VRpyTI1iqk9fWmYZL1onBKSCsMxzYa0r2G8id1jV00p4+rTCcp2tomG+LMFzmOxf u8yZkBoiNmKk+JBQcGihHqOI/BNJ1yf58U1P7bK9QFeFeD5zQH6zFufcS1L8wbq9 do3xYsZaEyk/uEdZ/U/oDGHmfKexwRcCY7w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1695495536; x= 1695581936; bh=807zhHwEPI8vcbiNfLVgksUwBXPeEt+aRX5XBDjzzhM=; b=J ydV27LrjUYOanR43omuY4nP77lsgGIyW4yugQZeFqv8r2thmz2VKORjexgOWyxv5 F7+xNyYdM0ESRb5PxeBaBAE+jyfpiilx88typG3eOha6OGFtnxVjmSjDV1h1f7sy ZI8Lrh1cS1IkVISoRLK6yTvM6l/TOgLXEg3ZDjcCVEJVYTT7EiM1qo9J9VhhDVu+ 8ZnTPsq8x1hrRNRrIozvvM7etKs4S1Iht70O88ZQFns9nW5LQyaBo3ppEP5qLOIt 7bXQwjMttY+IHVzwGJJpdnojjp5pONELynihFyX6u5EtDtJ7UiAHEq3gvdjysNUE 4EvhQNIPWVkdCd4FcolvA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedrudeltddgudefudcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepkfffgggfuffvfhfhjggtgfesth ejredttdefjeenucfhrhhomhepjghurhhiucfrrghnkhhovhcuoeihuhhrihesrggvthgv rhhnrdhorhhgqeenucggtffrrghtthgvrhhnpeekieejgeehhffhheehieeljeeutdetfe fgieffffdvvefhffdutefgkeetjeffjeenucevlhhushhtvghrufhiiigvpedtnecurfgr rhgrmhepmhgrihhlfhhrohhmpeihuhhrihesrggvthgvrhhnrdhorhhg X-ME-Proxy: Feedback-ID: i0d79475b:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Sat, 23 Sep 2023 14:58:55 -0400 (EDT) Message-ID: <779546e4-1135-c808-372f-e77d347ecf65@aetern.org> Date: Sat, 23 Sep 2023 20:58:53 +0200 List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.15.1 Subject: Re: nvd->nda switch and blocksize changes for ZFS Content-Language: en-US To: stable@freebsd.org References: <1b6190d1-1d42-6c99-bef6-c6b77edd386a@harz2023.behrens.de> From: Yuri Pankov In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spamd-Bar: / X-Rspamd-Pre-Result: action=no action; module=multimap; Matched map: local_wl_from X-Spamd-Result: default: False [-0.40 / 15.00]; R_SPF_ALLOW(-0.20)[+ip4:66.111.4.26]; R_DKIM_ALLOW(-0.20)[aetern.org:s=fm1,messagingengine.com:s=fm2]; DKIM_TRACE(0.00)[aetern.org:+,messagingengine.com:+]; PREVIOUSLY_DELIVERED(0.00)[stable@freebsd.org]; local_wl_from(0.00)[yuri@aetern.org]; FREEFALL_USER(0.00)[yuri]; MLMMJ_DEST(0.00)[stable@freebsd.org]; ASN(0.00)[asn:19151, ipnet:66.111.4.0/24, country:US] X-Rspamd-Queue-Id: 4RtJMQ3Qhbz4sp0 Dimitry Andric wrote: > On 23 Sep 2023, at 18:31, Frank Behrens wrote: >> >> I created a zpool with a FreeBSD-14.0-CURRENT on February. With 15.0-CURRENT/14.0-STABLE from now I get the message: >> >> status: One or more devices are configured to use a non-native block size. >> Expect reduced performance. >> action: Replace affected devices with devices that support the >> configured block size, or migrate data to a properly configured >> pool. >> NAME STATE READ WRITE CKSUM >> zsys ONLINE 0 0 0 >> raidz1-0 ONLINE 0 0 0 >> nda0p4 ONLINE 0 0 0 block size: 4096B configured, 16384B native >> nda1p4 ONLINE 0 0 0 block size: 4096B configured, 16384B native >> nda2p4 ONLINE 0 0 0 block size: 4096B configured, 16384B native >> >> I use: >> nda0: >> nda0: nvme version 1.4 >> nda0: 953869MB (1953525168 512 byte sectors) >> >> I cannot imagine, that the native blocksize changed. Do I really expect a reduced performance? >> Is it advisable to switch back to nvd? > > It could be due to a bug in nda so it reports the native block size incorrectly, in which case you would not need to do anything but ignore the message. However, if the native block size is really 16kiB, you will get write amplification effects, which could needlessly shorten the life of your SSD. > > I would try running e.g. smartmontools's smartctl, which can sometimes tell you what the real block size is. Although as far as I know, it retrieves this information from some internal database. You could also try to look up the information in the SSD vendor's data sheet, or ask the vendor directly? Isn't it displayed by e.g. `nvmecontrol identify nda0` under the LBA Formats (including the current one used to format the namespace)?