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

[Peter Lieven]

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