extremely slow disk I/O after updating to 12.0

[Karl Denninger]

On 7/3/2019 08:42, Trond Endrestøl wrote:
> On Wed, 3 Jul 2019 13:34+0200, David Demelier wrote:
>
>> zpool status indicates that the blocksize is erroneous and that I may expect
>> performance degradation. But that much is impressive. Can someone confirm?
>>
>> # zpool status
>>   pool: tank
>>  state: ONLINE
>> 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.
>>   scan: none requested
>> config:
>>
>>         NAME          STATE     READ WRITE CKSUM
>>         tank          ONLINE       0     0     0
>>           raidz1-0    ONLINE       0     0     0
>>             gpt/zfs0  ONLINE       0     0     0  block size: 512B configured, 4096B native
>>             gpt/zfs1  ONLINE       0     0     0  block size: 512B configured, 4096B native
>>
>> errors: No known data errors
>>
>>
>>
>> According to some googling, I must update those pools to change the block
>> size. However there are no many articles on that so I'm a bit afraid of doing
>> this. The zfs0 and zfs1 are in raidz.
>>
>> Any help is very welcome.

ashift=9 on a 4k native block device is going to do horrible things to
performance.  There's no way to change it on an existing pool, as the
other respondent noted; you will have to back up the data on the pool,
destroy the pool and then re-create it.

Was this pool originally created with 512b disks and then the drives
were swapped out with a "replace" at some point for advanced-format units?

The only downside to using ashift=12 on a 512b drive is a modest amount
of lost space in overhead, but given the risk that somewhere down the
line you will swap the disk for a 4k one, and if you do you get forced
to recreate the pool to get rid of the performance problem, I've had
ashift=12 set as a default for a very long time.

-- 
Karl Denninger
karl at denninger.net <mailto:karl at denninger.net>
/The Market Ticker/
/[S/MIME encrypted email preferred]/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4897 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.freebsd.org/pipermail/freebsd-questions/attachments/20190703/f69e9a4f/attachment.bin>