Skip to content
Snippets Groups Projects
  • Vladimir Sementsov-Ogievskiy's avatar
    0c802287
    block: use int64_t instead of int in driver discard handlers · 0c802287
    Vladimir Sementsov-Ogievskiy authored
    
    We are generally moving to int64_t for both offset and bytes parameters
    on all io paths.
    
    Main motivation is realization of 64-bit write_zeroes operation for
    fast zeroing large disk chunks, up to the whole disk.
    
    We chose signed type, to be consistent with off_t (which is signed) and
    with possibility for signed return type (where negative value means
    error).
    
    So, convert driver discard handlers bytes parameter to int64_t.
    
    The only caller of all updated function is bdrv_co_pdiscard in
    block/io.c. It is already prepared to work with 64bit requests, but
    pass at most max(bs->bl.max_pdiscard, INT_MAX) to the driver.
    
    Let's look at all updated functions:
    
    blkdebug: all calculations are still OK, thanks to
      bdrv_check_qiov_request().
      both rule_check and bdrv_co_pdiscard are 64bit
    
    blklogwrites: pass to blk_loc_writes_co_log which is 64bit
    
    blkreplay, copy-on-read, filter-compress: pass to bdrv_co_pdiscard, OK
    
    copy-before-write: pass to bdrv_co_pdiscard which is 64bit and to
      cbw_do_copy_before_write which is 64bit
    
    file-posix: one handler calls raw_account_discard() is 64bit and both
      handlers calls raw_do_pdiscard(). Update raw_do_pdiscard, which pass
      to RawPosixAIOData::aio_nbytes, which is 64bit (and calls
      raw_account_discard())
    
    gluster: somehow, third argument of glfs_discard_async is size_t.
      Let's set max_pdiscard accordingly.
    
    iscsi: iscsi_allocmap_set_invalid is 64bit,
      !is_byte_request_lun_aligned is 64bit.
      list.num is uint32_t. Let's clarify max_pdiscard and
      pdiscard_alignment.
    
    mirror_top: pass to bdrv_mirror_top_do_write() which is
      64bit
    
    nbd: protocol limitation. max_pdiscard is alredy set strict enough,
      keep it as is for now.
    
    nvme: buf.nlb is uint32_t and we do shift. So, add corresponding limits
      to nvme_refresh_limits().
    
    preallocate: pass to bdrv_co_pdiscard() which is 64bit.
    
    rbd: pass to qemu_rbd_start_co() which is 64bit.
    
    qcow2: calculations are still OK, thanks to bdrv_check_qiov_request(),
      qcow2_cluster_discard() is 64bit.
    
    raw-format: raw_adjust_offset() is 64bit, bdrv_co_pdiscard too.
    
    throttle: pass to bdrv_co_pdiscard() which is 64bit and to
      throttle_group_co_io_limits_intercept() which is 64bit as well.
    
    test-block-iothread: bytes argument is unused
    
    Great! Now all drivers are prepared to handle 64bit discard requests,
    or else have explicit max_pdiscard limits.
    
    Signed-off-by: default avatarVladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
    Message-Id: <20210903102807.27127-11-vsementsov@virtuozzo.com>
    Reviewed-by: default avatarEric Blake <eblake@redhat.com>
    Signed-off-by: default avatarEric Blake <eblake@redhat.com>
    0c802287
    History
    block: use int64_t instead of int in driver discard handlers
    Vladimir Sementsov-Ogievskiy authored
    
    We are generally moving to int64_t for both offset and bytes parameters
    on all io paths.
    
    Main motivation is realization of 64-bit write_zeroes operation for
    fast zeroing large disk chunks, up to the whole disk.
    
    We chose signed type, to be consistent with off_t (which is signed) and
    with possibility for signed return type (where negative value means
    error).
    
    So, convert driver discard handlers bytes parameter to int64_t.
    
    The only caller of all updated function is bdrv_co_pdiscard in
    block/io.c. It is already prepared to work with 64bit requests, but
    pass at most max(bs->bl.max_pdiscard, INT_MAX) to the driver.
    
    Let's look at all updated functions:
    
    blkdebug: all calculations are still OK, thanks to
      bdrv_check_qiov_request().
      both rule_check and bdrv_co_pdiscard are 64bit
    
    blklogwrites: pass to blk_loc_writes_co_log which is 64bit
    
    blkreplay, copy-on-read, filter-compress: pass to bdrv_co_pdiscard, OK
    
    copy-before-write: pass to bdrv_co_pdiscard which is 64bit and to
      cbw_do_copy_before_write which is 64bit
    
    file-posix: one handler calls raw_account_discard() is 64bit and both
      handlers calls raw_do_pdiscard(). Update raw_do_pdiscard, which pass
      to RawPosixAIOData::aio_nbytes, which is 64bit (and calls
      raw_account_discard())
    
    gluster: somehow, third argument of glfs_discard_async is size_t.
      Let's set max_pdiscard accordingly.
    
    iscsi: iscsi_allocmap_set_invalid is 64bit,
      !is_byte_request_lun_aligned is 64bit.
      list.num is uint32_t. Let's clarify max_pdiscard and
      pdiscard_alignment.
    
    mirror_top: pass to bdrv_mirror_top_do_write() which is
      64bit
    
    nbd: protocol limitation. max_pdiscard is alredy set strict enough,
      keep it as is for now.
    
    nvme: buf.nlb is uint32_t and we do shift. So, add corresponding limits
      to nvme_refresh_limits().
    
    preallocate: pass to bdrv_co_pdiscard() which is 64bit.
    
    rbd: pass to qemu_rbd_start_co() which is 64bit.
    
    qcow2: calculations are still OK, thanks to bdrv_check_qiov_request(),
      qcow2_cluster_discard() is 64bit.
    
    raw-format: raw_adjust_offset() is 64bit, bdrv_co_pdiscard too.
    
    throttle: pass to bdrv_co_pdiscard() which is 64bit and to
      throttle_group_co_io_limits_intercept() which is 64bit as well.
    
    test-block-iothread: bytes argument is unused
    
    Great! Now all drivers are prepared to handle 64bit discard requests,
    or else have explicit max_pdiscard limits.
    
    Signed-off-by: default avatarVladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
    Message-Id: <20210903102807.27127-11-vsementsov@virtuozzo.com>
    Reviewed-by: default avatarEric Blake <eblake@redhat.com>
    Signed-off-by: default avatarEric Blake <eblake@redhat.com>