]> granicus.if.org Git - zfs/commitdiff
Limit max_hw_sectors_kb to 16M
authorBrian Behlendorf <behlendorf1@llnl.gov>
Fri, 28 Aug 2015 00:01:59 +0000 (17:01 -0700)
committerBrian Behlendorf <behlendorf1@llnl.gov>
Fri, 28 Aug 2015 16:16:59 +0000 (09:16 -0700)
When support for large blocks was added DMU_MAX_ACCESS was increased
to allow for blocks of up to 16M to fit in a transaction handle.
This had the side effect of increasing the max_hw_sectors_kb for
volumes, which are scaled off DMU_MAX_ACCESS, to 64M from 10M.

This is an issue for volumes which by default use an 8K block size
because it results in dmu_buf_hold_array_by_dnode() allocating a
64K array for the dbufs.  The solution is to restore the maximum
size to ~10M.  This patch specifically changes it to 16M which is
close enough.

Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Closes #3684

module/zfs/zvol.c

index b073a3c5ee5d2ec85e0b2e038e953dbc603524c0..2b99f44de6a877b6c63b3cf12665ebc2bb39aa44 100644 (file)
@@ -1389,7 +1389,7 @@ __zvol_create_minor(const char *name, boolean_t ignore_snapdev)
 
        set_capacity(zv->zv_disk, zv->zv_volsize >> 9);
 
-       blk_queue_max_hw_sectors(zv->zv_queue, DMU_MAX_ACCESS / 512);
+       blk_queue_max_hw_sectors(zv->zv_queue, (DMU_MAX_ACCESS / 4) >> 9);
        blk_queue_max_segments(zv->zv_queue, UINT16_MAX);
        blk_queue_max_segment_size(zv->zv_queue, UINT_MAX);
        blk_queue_physical_block_size(zv->zv_queue, zv->zv_volblocksize);