On 4/22/20 9:29 AM, Vladimir Sementsov-Ogievskiy wrote:
Any thoughts here? I need to resend to update some more functions as
patchew said.
Is it OK in general? Or should we instead convert everything to uint64_t ?
I definitely prefer int64_t as our base (off_t is signed as well, making
63 bits an effective limit everywhere).
30.03.2020 17:18, Vladimir Sementsov-Ogievskiy wrote:
Hi all!
There is an idea to make NBD protocol extension to support 64bit
write-zero/discard/block-status commands (commands, which doesn't
transfer user data). It's needed to increase performance of zeroing
large ranges (up to the whole image). Zeroing of the whole image is used
as first step of mirror job, qemu-img convert, it should be also used at
start of backup actually..
We need to support it in block-layer, so we want 64bit write_zeros.
Currently driver handler now have int bytes parameter.
write_zeros path goes through normal pwritev, so we need 64bit write,
and then we need 64bit read for symmetry, and better, let's make all io
path work with 64bit bytes parameter.
Actually most of block-layer already have 64bit parameters: offset is
sometimes int64_t and sometimes uint64_t. bytes parameter is one of
int64_t, uint64_t, int, unsigned int...
I think we need one type for all of this, and this one type is int64_t.
Signed int64_t is a bit better than uint64_t: you can use same variable
to get some result (including error < 0) and than reuse it as an
argument without any type conversion.
So, I propose, as a first step, convert all uint64_t parameters to
int64_t.
Makes sense. I haven't looked at the series closely in part because it
was 5.1 material while we were still focused on getting 5.0 out the
door, but it is now raising in my review queue again.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org
