From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55104) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XWM2A-0005D9-3z for qemu-devel@nongnu.org; Tue, 23 Sep 2014 05:05:27 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XWM1y-0003L5-4y for qemu-devel@nongnu.org; Tue, 23 Sep 2014 05:05:18 -0400 Received: from mx-v6.kamp.de ([2a02:248:0:51::16]:42218 helo=mx01.kamp.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XWM1x-0003Ai-Qc for qemu-devel@nongnu.org; Tue, 23 Sep 2014 05:05:06 -0400 Message-ID: <542137B8.30500@kamp.de> Date: Tue, 23 Sep 2014 11:04:56 +0200 From: Peter Lieven MIME-Version: 1.0 References: <1409935888-18552-1-git-send-email-pl@kamp.de> <1409935888-18552-5-git-send-email-pl@kamp.de> <541AE887.9050607@redhat.com> <541C3095.4040405@redhat.com> <541FEF3A.30909@kamp.de> <54207349.2000107@redhat.com> <54210FEB.50900@kamp.de> <20140923085917.GB3871@noname.str.redhat.com> In-Reply-To: <20140923085917.GB3871@noname.str.redhat.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 4/4] block: avoid creating oversized writes in multiwrite_merge List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: Paolo Bonzini , ronniesahlberg@gmail.com, qemu-devel@nongnu.org, stefanha@redhat.com, mreitz@redhat.com 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