From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44112) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XW09n-0005fo-9p for qemu-devel@nongnu.org; Mon, 22 Sep 2014 05:43:52 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XW09c-0000tK-L6 for qemu-devel@nongnu.org; Mon, 22 Sep 2014 05:43:43 -0400 Received: from mx-v6.kamp.de ([2a02:248:0:51::16]:52479 helo=mx01.kamp.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XW09c-0000sS-Ag for qemu-devel@nongnu.org; Mon, 22 Sep 2014 05:43:32 -0400 Message-ID: <541FEF3A.30909@kamp.de> Date: Mon, 22 Sep 2014 11:43:22 +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> In-Reply-To: <541C3095.4040405@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: Paolo Bonzini Cc: kwolf@redhat.com, ronniesahlberg@gmail.com, qemu-devel@nongnu.org, stefanha@redhat.com, mreitz@redhat.com On 19.09.2014 15:33, Paolo Bonzini wrote: > Il 19/09/2014 00:56, Peter Lieven ha scritto: >>>> So I think if we treat it just as a hint for multiwrite, we can avoid >>>> writing code to split oversized requests. They always worked so far, we >>>> can certainly wait until we have a real bug fix. >> I would not treat this as a hint. I would use it in cases where we definitely >> know an absolute hard limit for I/O request size. Otherwise the value for >> bs->bl.max_transfer_length should be 0. >> >> If there comes in an oversized request we fail it as early as possible > That's the part that I'd rather not touch, at least not without doing > request splitting. 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. Currently, we only have a limit for iSCSI. Without Patch 2 it would fail after we have send the command to the target. And without Patch 4 it may happen that multiwrite_merge traps the into the limit. Maybe I should adjust the description of max_transfer_length? Peter