about zfs and ashift and changing ashift on existing zpool

Alexander Motin mav at FreeBSD.org
Tue Apr 9 00:56:03 UTC 2019

On 08.04.2019 20:21, Eugene Grosbein wrote:
> 09.04.2019 7:00, Kevin P. Neal wrote:
>>> My guess (given that only ada1 is reporting a blocksize mismatch) is that
>>> your disks reported a 512B native blocksize.  In the absence of any override,
>>> ZFS will then build an ashift=9 pool.
> [skip]
>> smartctl 7.0 2018-12-30 r4883 [FreeBSD 11.2-RELEASE-p4 amd64] (local build)
>> Copyright (C) 2002-18, Bruce Allen, Christian Franke, www.smartmontools.org
>> Vendor:               SEAGATE
>> Product:              ST2400MM0129
>> Revision:             C003
>> Compliance:           SPC-4
>> User Capacity:        2,400,476,553,216 bytes [2.40 TB]
>> Logical block size:   512 bytes
>> Physical block size:  4096 bytes
> Maybe it't time to prefer "Physical block size" over "Logical block size" in relevant GEOMs
> like GEOM_DISK, so upper levels such as ZFS would do the right thing automatically.

No.  It is a bad idea.  Changing logical block size for existing disks
will most likely result in breaking compatibility and inability to read
previously written data.  ZFS already uses physical block size when
possible -- on pool creation or new vdev addition.  When not possible
(pool already created wrong) it just complains about it, so that user
would know that his configuration is imperfect and he should not expect
full performance.

Alexander Motin

More information about the freebsd-stable mailing list