From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36160) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XUke7-0001TE-4W for qemu-devel@nongnu.org; Thu, 18 Sep 2014 18:58:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XUkdx-0000hX-3I for qemu-devel@nongnu.org; Thu, 18 Sep 2014 18:57:51 -0400 Received: from mx-v6.kamp.de ([2a02:248:0:51::16]:39252 helo=mx01.kamp.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XUkdw-0000gr-Pk for qemu-devel@nongnu.org; Thu, 18 Sep 2014 18:57:41 -0400 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Peter Lieven In-Reply-To: <541AE978.6060606@redhat.com> Date: Fri, 19 Sep 2014 00:57:32 +0200 Content-Transfer-Encoding: 7bit Message-Id: <1A9CBAEE-E86B-4330-BD08-68486A092018@kamp.de> References: <1409935888-18552-1-git-send-email-pl@kamp.de> <1409935888-18552-3-git-send-email-pl@kamp.de> <20140908134434.GB22582@irqsave.net> <540DB3E2.6010905@redhat.com> <540DB583.4030101@kamp.de> <540DB5EB.2070705@redhat.com> <540DBEBD.9040701@kamp.de> <540DC059.4000907@redhat.com> <540DC7FB.1040804@redhat.com> <540DC8D7.80905@kamp.de> <540DCAE8.4060701@redhat.com> <29A6ECA0-C6CE-4557-80CA-31FD2CA199A2@kamp.de> <540DD986.8010301@redhat.com> <5412DC5D.7050406@kamp.de> <541AE83A.9080705@redhat.com> <541AE955.4090404@kamp.de> <541AE978.6060606@redhat.com> Subject: Re: [Qemu-devel] [PATCH 2/4] block: immediately cancel oversized read/write requests List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: =?windows-1252?Q?Beno=EEt_Canet?= , Kevin Wolf , ronnie sahlberg , qemu-devel , Max Reitz , Stefan Hajnoczi Am 18.09.2014 um 16:17 schrieb Paolo Bonzini : > Il 18/09/2014 16:16, Peter Lieven ha scritto: >>> >>>> As you can see from the multiwrite_merge trace the merging has never >>>> been stopped because of >>>> the max_transfer_length. The question is, why are the I/O requests >>>> not coming in as specified? >>> I think that's because of the filesystem. Try writing directly to a >>> device. >> >> thats what I did... > > Ah, I saw of=test. It was definitely /dev/vda. Any ideas? Maybe something in the virtio drivers? Peter