From nobody Mon Sep 25 06:42:08 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 4RvCwK5YRxz4v7v3 for ; Mon, 25 Sep 2023 06:42:09 +0000 (UTC) (envelope-from frank@harz2023.behrens.de) Received: from post.behrens.de (post.behrens.de [IPv6:2a01:170:1023::1:2]) (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-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "post.behrens.de", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4RvCwJ5Qmgz4JmX for ; Mon, 25 Sep 2023 06:42:08 +0000 (UTC) (envelope-from frank@harz2023.behrens.de) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=harz2023.behrens.de header.s=pinky2 header.b="VcBfY/1D"; spf=pass (mx1.freebsd.org: domain of frank@harz2023.behrens.de designates 2a01:170:1023::1:2 as permitted sender) smtp.mailfrom=frank@harz2023.behrens.de; dmarc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= harz2023.behrens.de; h=message-id:date:mime-version:from:subject :to:references:in-reply-to:content-type :content-transfer-encoding; s=pinky2; bh=SZ32ODnMJFaOWTS7Mlauf04 Qxf+H4yQehayRYfu+OWc=; b=VcBfY/1DJTh/gjpw0v6QEXfth1np+tzWemLUDh8 HQRVPlpB8ahXu9UbMDxwlwr9Te54PW5wiBpN08dQ6FE9/+NJieCjSRZRSPhHQaAp W7Wi0aJIciLN6sbEihoUPkIJu2joZYeYOKjW1LxwqkUXDKw2GpXwczbQD1TB3Y/N yTIM= Received: from [IPV6:fdfb:1999:428:bb80:17b:8d:64b2:74db] ([IPv6:fdfb:1999:428:bb80:17b:8d:64b2:74db]) (authenticated bits=0) by post.behrens.de (8.17.1/8.17.1) with ESMTPSA(MSP) id 38P6g5Nh053133 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO cn=) for ; Mon, 25 Sep 2023 08:42:05 +0200 (CEST) (envelope-from frank@harz2023.behrens.de) Message-ID: Date: Mon, 25 Sep 2023 08:42:08 +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 From: Frank Behrens Subject: Re: nvd->nda switch and blocksize changes for ZFS To: stable@freebsd.org References: <1b6190d1-1d42-6c99-bef6-c6b77edd386a@harz2023.behrens.de> <779546e4-1135-c808-372f-e77d347ecf65@aetern.org> Content-Language: de-DE In-Reply-To: <779546e4-1135-c808-372f-e77d347ecf65@aetern.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.40 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; R_DKIM_ALLOW(-0.20)[harz2023.behrens.de:s=pinky2]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; ONCE_RECEIVED(0.10)[]; FROM_HAS_DN(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; MLMMJ_DEST(0.00)[stable@freebsd.org]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_ALL(0.00)[]; ASN(0.00)[asn:8820, ipnet:2a01:170:1000::/36, country:DE]; TO_MATCH_ENVRCPT_ALL(0.00)[]; ARC_NA(0.00)[]; BLOCKLISTDE_FAIL(0.00)[2a01:170:1023::1:2:server fail]; PREVIOUSLY_DELIVERED(0.00)[stable@freebsd.org]; TO_DN_NONE(0.00)[]; DKIM_TRACE(0.00)[harz2023.behrens.de:+]; RCPT_COUNT_ONE(0.00)[1]; DMARC_NA(0.00)[behrens.de]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[] X-Rspamd-Queue-Id: 4RvCwJ5Qmgz4JmX Hi Dimitry, Yuri and also Mark, thanks for your fast responses! Am 23.09.2023 um 20:58 schrieb Yuri Pankov: > 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)? Based on your comments I made some investigations and switched back to nvd: # smartctl -a /dev/nvme0 Namespace 1 Formatted LBA Size:     512 ... Supported LBA Sizes (NSID 0x1) Id Fmt  Data  Metadt  Rel_Perf  0 +     512       0         0 # nvmecontrol identify nda0 and # nvmecontrol identify nvd0 (after hw.nvme.use_nvd="1" and reboot) give the same result: Number of LBA Formats:       1 Current LBA Format:          LBA Format #00 LBA Format #00: Data Size:   512  Metadata Size:     0  Performance: Best ... Optimal I/O Boundary:        0 blocks NVM Capacity:                1000204886016 bytes Preferred Write Granularity: 32 blocks Preferred Write Alignment:   8 blocks Preferred Deallocate Granul: 9600 blocks Preferred Deallocate Align:  9600 blocks Optimal Write Size:          256 blocks The recommended blocksize for ZFS is GEOM's stripesize and there I see a difference: # diff -w -U 10  gpart_list_nvd.txt gpart_list_nda.txt -Geom name: nvd0 +Geom name: nda0  modified: false  state: OK  fwheads: 255  fwsectors: 63  last: 1953525127  first: 40  entries: 128  scheme: GPT  Providers: -1. Name: nvd0p1 +1. Name: nda0p1     Mediasize: 272629760 (260M)     Sectorsize: 512 -   Stripesize: 4096 -   Stripeoffset: 0 +   Stripesize: 16384 +   Stripeoffset: 4096     Mode: r1w1e2     efimedia: HD(1,GPT,8d4c57bb-932f-11ed-82da-74563c227532,0x28,0x82000)     rawuuid: 8d4c57bb-932f-11ed-82da-74563c227532     rawtype: c12a7328-f81f-11d2-ba4b-00a0c93ec93b     label: efiboot0     length: 272629760     offset: 20480     type: efi     index: 1     end: 532519     start: 40 ... -4. Name: nvd0p4 +4. Name: nda0p4     Mediasize: 995635494912 (927G)     Sectorsize: 512 -   Stripesize: 4096 +   Stripesize: 16384     Stripeoffset: 0     Mode: r1w1e1     efimedia: HD(4,GPT,8d61a5ca-932f-11ed-82da-74563c227532,0x882800,0x73e84000)     rawuuid: 8d61a5ca-932f-11ed-82da-74563c227532     rawtype: 516e7cba-6ecf-11d6-8ff8-00022d09712b     label: zfs0     length: 995635494912     offset: 4568645632     type: freebsd-zfs     index: 4     end: 1953523711     start: 8923136 With these information I'm not sure, if I have really a problem with the native blocksize. Does anybody know, how the stripesize is determined? Kind regards,    Frank -- Frank Behrens Osterwieck, Germany