diff options
| author | Brian Behlendorf <[email protected]> | 2015-08-27 17:01:59 -0700 |
|---|---|---|
| committer | Brian Behlendorf <[email protected]> | 2015-08-28 09:16:59 -0700 |
| commit | c495fe2c1c6b1c63aefcd832e2e0eb0a20d4c4dc (patch) | |
| tree | d0f8581df9f29806d304af8bc9e58f48f21f5f03 | |
| parent | 5475aada9474464f973788c1b2fc6216486fb303 (diff) | |
Limit max_hw_sectors_kb to 16M
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 <[email protected]>
Closes #3684
| -rw-r--r-- | module/zfs/zvol.c | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/module/zfs/zvol.c b/module/zfs/zvol.c index b073a3c5e..2b99f44de 100644 --- a/module/zfs/zvol.c +++ b/module/zfs/zvol.c @@ -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); |