aboutsummaryrefslogtreecommitdiff
path: root/module/zfs/vdev_indirect.c
diff options
context:
space:
mode:
authorRyan Moeller <ryan@iXsystems.com>2020-08-21 19:53:17 +0000
committerGitHub <noreply@github.com>2020-08-21 19:53:17 +0000
commit6fe3498ca3406ffb10f729ab4f9cf63f10c74ede (patch)
tree59f4761a8918487531a124c72a937511dc7620d8 /module/zfs/vdev_indirect.c
parent6706552ea6bdc74122b530ba5e8a6956f5160428 (diff)
downloadsrc-6fe3498ca3406ffb10f729ab4f9cf63f10c74ede.tar.gz
src-6fe3498ca3406ffb10f729ab4f9cf63f10c74ede.zip
Import vdev ashift optimization from FreeBSD
Many modern devices use physical allocation units that are much larger than the minimum logical allocation size accessible by external commands. Two prevalent examples of this are 512e disk drives (512b logical sector, 4K physical sector) and flash devices (512b logical sector, 4K or larger allocation block size, and 128k or larger erase block size). Operations that modify less than the physical sector size result in a costly read-modify-write or garbage collection sequence on these devices. Simply exporting the true physical sector of the device to ZFS would yield optimal performance, but has two serious drawbacks: 1. Existing pools created with devices that have different logical and physical block sizes, but were configured to use the logical block size (e.g. because the OS version used for pool construction reported the logical block size instead of the physical block size) will suddenly find that the vdev allocation size has increased. This can be easily tolerated for active members of the array, but ZFS would prevent replacement of a vdev with another identical device because it now appears that the smaller allocation size required by the pool is not supported by the new device. 2. The device's physical block size may be too large to be supported by ZFS. The optimal allocation size for the vdev may be quite large. For example, a RAID controller may export a vdev that requires read-modify-write cycles unless accessed using 64k aligned/sized requests. ZFS currently has an 8k minimum block size limit. Reporting both the logical and physical allocation sizes for vdevs solves these problems. A device may be used so long as the logical block size is compatible with the configuration. By comparing the logical and physical block sizes, new configurations can be optimized and administrators can be notified of any existing pools that are sub-optimal. Reviewed-by: Ryan Moeller <ryan@iXsystems.com> Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Co-authored-by: Matthew Macy <mmacy@freebsd.org> Signed-off-by: Matt Macy <mmacy@FreeBSD.org> Closes #10619
Diffstat (limited to 'module/zfs/vdev_indirect.c')
-rw-r--r--module/zfs/vdev_indirect.c5
1 files changed, 3 insertions, 2 deletions
diff --git a/module/zfs/vdev_indirect.c b/module/zfs/vdev_indirect.c
index 4cd83d79ea6b..6a944f4e88b6 100644
--- a/module/zfs/vdev_indirect.c
+++ b/module/zfs/vdev_indirect.c
@@ -950,11 +950,12 @@ vdev_indirect_close(vdev_t *vd)
/* ARGSUSED */
static int
vdev_indirect_open(vdev_t *vd, uint64_t *psize, uint64_t *max_psize,
- uint64_t *ashift)
+ uint64_t *logical_ashift, uint64_t *physical_ashift)
{
*psize = *max_psize = vd->vdev_asize +
VDEV_LABEL_START_SIZE + VDEV_LABEL_END_SIZE;
- *ashift = vd->vdev_ashift;
+ *logical_ashift = vd->vdev_ashift;
+ *physical_ashift = vd->vdev_physical_ashift;
return (0);
}