On Wed, Jul 8, 2015 at 12:14 PM, Kevin Wolf <kw...@redhat.com> wrote:
> Am 01.07.2015 um 16:45 hat Stefan Hajnoczi geschrieben:
>> If mirror has more free buffers than IOV_MAX, preadv(2)/pwritev(2)
>> EINVAL failures may be encountered.
>>
>> It is possible to trigger this by setting granularity to a low value
>> like 8192.
>>
>> This patch stops appending chunks once IOV_MAX is reached.
>>
>> The spurious EINVAL failure can be reproduced with a qcow2 image file
>> and the following QMP invocation:
>>
>> qmp.command('drive-mirror', device='virtio0', target='/tmp/r7.s1',
>> granularity=8192, sync='full', mode='absolute-paths',
>> format='raw')
>>
>> While the guest is running dd if=/dev/zero of=/var/tmp/foo oflag=direct
>> bs=4k.
>>
>> Cc: Jeff Cody <jc...@redhat.com>
>> Signed-off-by: Stefan Hajnoczi <stefa...@redhat.com>
>
> This looks like a backend-specific problem with raw-posix. Wouldn't it
> make more sense to either let raw-posix split requests it can't handle
> or introduce a bs->iov_max instead of spreading knowledge about specific
> backends into all callers of the block layer?
>
> I'm not objecting to taking this patch for now to fix the bug in 2.4,
> but I don't think it's the proper solution.
I will send a patch for QEMU 2.5 that introduces an iov max field in
BlockLimits. It will convert the request merging code which currently
hardcodes IOV_MAX too.
In practice there are probably only two values that get used: IOV_MAX
and INT_MAX, but we already have BlockLimits and it doesn't hurt to
add this.
Stefan
