aboutsummaryrefslogtreecommitdiffstats
path: root/tests/test-runner/bin
diff options
context:
space:
mode:
authorAlexander Motin <[email protected]>2022-09-08 13:30:53 -0400
committerGitHub <[email protected]>2022-09-08 10:30:53 -0700
commit37f6845c6f86b1d04593e55d94318326006f4b5d (patch)
treed435ddb262caa5c5315597341196b42f3b55b5eb /tests/test-runner/bin
parent320f0c6022e1c9bdc9063f849c6b2e4fa3b93995 (diff)
Improve too large physical ashift handling
When iterating through children physical ashifts for vdev, prefer ones above the maximum logical ashift, that we can actually use, but within the administrator defined maximum. When selecting top-level vdev ashift, do not set it to the defined maximum in case physical ashift is even higher, but just ignore one. Using the maximum does not prevent misaligned writes, but reduces space efficiency. Since ZFS tries to write data sequentially and aggregates the writes, in many cases large misanigned writes may be not as bad as the space penalty otherwise. Allow internal physical ashifts for vdevs higher than SHIFT_MAX. May be one day allocator or aggregation could benefit from that. Reduce zfs_vdev_max_auto_ashift default from 16 (64KB) to 14 (16KB), so that ZFS may still use bigger ashifts up to SHIFT_MAX (64KB), but only if it really has to or explicitly told to, but not as an "optimization". There are some read-intensive NVMe SSDs that report Preferred Write Alignment of 64KB, and attempt to build RAIDZ2 of those leads to a space inefficiency that can't be justified. Instead these changes make ZFS fall back to logical ashift of 12 (4KB) by default and only warn user that it may be suboptimal for performance. Reviewed-by: Brian Behlendorf <[email protected]> Reviewed-by: Ryan Moeller <[email protected]> Signed-off-by: Alexander Motin <[email protected]> Sponsored by: iXsystems, Inc. Closes #13798
Diffstat (limited to 'tests/test-runner/bin')
0 files changed, 0 insertions, 0 deletions