Re: [Qemu-devel] [PATCH 4/4] block: avoid creating oversized writes in multiwrite_merge

[Peter Lieven <pl@kamp.de>]

On 23.09.2014 10:59, Kevin Wolf wrote:
> Am 23.09.2014 um 08:15 hat Peter Lieven geschrieben:
>> On 22.09.2014 21:06, Paolo Bonzini wrote:
>>> Il 22/09/2014 11:43, Peter Lieven ha scritto:
>>>> This series aims not at touching default behaviour. The default for max_transfer_length
>>>> is 0 (no limit). max_transfer_length is a limit that MUST be satisfied otherwise the request
>>>> will fail. And Patch 2 aims at catching this fail earlier in the stack.
>>> Understood.  But the right fix is to avoid that backend limits transpire
>>> into guest ABI, not to catch the limits earlier.  So the right fix would
>>> be to implement request splitting.
>> Since you proposed to add traces for this would you leave those in?
>> And since iSCSI is the only user of this at the moment would you
>> go for implementing this check in the iSCSI block layer?
>>
>> As for the split logic would you think it is enough to build new qiov's
>> out of the too big iov without copying the contents? This would work
>> as long as a single iov inside the qiov is not bigger the max_transfer_length.
>> Otherwise I would need to allocate temporary buffers and copy around.
> You can split single iovs, too. There are functions that make this very
> easy, they copy a sub-qiov with a byte granularity offset and length
> (qemu_iovec_concat and friends). qcow2 uses the same to split requests
> at (fragmented) cluster boundaries.

Thanks for that pointer. Looking at qemu_iovec_concat this seems to be a
nobrainer.

I will first send an updated series dropping Patch 2 and will then send a follow-up
that splits requests.

Peter