zfs/tests/zfs-tests
Alexander Motin 37f6845c6f
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 <behlendorf1@llnl.gov>
Reviewed-by: Ryan Moeller <ryan@iXsystems.com>
Signed-off-by:	Alexander Motin <mav@FreeBSD.org>
Sponsored by:	iXsystems, Inc.
Closes #13798
2022-09-08 10:30:53 -07:00
..
callbacks autoconf: use include directives instead of recursing down tests (mostly) 2022-05-10 10:20:09 -07:00
cmd Add Linux posix_fadvise support 2022-09-08 10:29:41 -07:00
include Improve too large physical ashift handling 2022-09-08 10:30:53 -07:00
tests Improve too large physical ashift handling 2022-09-08 10:30:53 -07:00
.gitignore autoconf: use include directives instead of recursing down cmd 2022-05-10 10:18:38 -07:00
Makefile.am autoconf: use include directives instead of recursing down tests (mostly) 2022-05-10 10:20:09 -07:00