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<fr...@harz2023.behrens.de> 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: <Samsung SSD 980 1TB ..>
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