qemu-block
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-block] [PATCH] block/mirror: limit qiov to IOV_MAX elements


From: Stefan Hajnoczi
Subject: Re: [Qemu-block] [PATCH] block/mirror: limit qiov to IOV_MAX elements
Date: Wed, 8 Jul 2015 13:34:41 +0100

On Wed, Jul 8, 2015 at 12:14 PM, Kevin Wolf <address@hidden> 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 <address@hidden>
>> Signed-off-by: Stefan Hajnoczi <address@hidden>
>
> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]