From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tokarev Subject: Re: the >1Tb block issue Date: Tue, 18 May 2010 22:43:13 +0400 Message-ID: <4BF2DFC1.4070307@msgid.tls.msk.ru> References: <4BF2B7CD.7090204@msgid.tls.msk.ru> <4BF2CE70.1060402@redhat.com> <4BF2CFAB.1010505@msgid.tls.msk.ru> <4BF2D08E.7000505@redhat.com> <4BF2D666.1080108@msgid.tls.msk.ru> <4BF2D7C4.4080104@redhat.com> <4BF2DEB1.2010109@msgid.tls.msk.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: KVM list , Christoph Hellwig To: Avi Kivity Return-path: Received: from isrv.corpit.ru ([81.13.33.159]:42020 "EHLO isrv.corpit.ru" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755469Ab0ERSnQ (ORCPT ); Tue, 18 May 2010 14:43:16 -0400 In-Reply-To: <4BF2DEB1.2010109@msgid.tls.msk.ru> Sender: kvm-owner@vger.kernel.org List-ID: 18.05.2010 22:38, Michael Tokarev =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > 18.05.2010 22:09, Avi Kivity wrote: >> On 05/18/2010 09:03 PM, Michael Tokarev wrote: >>> 18.05.2010 21:38, Avi Kivity wrote: >>> >>>>> [Qemu-devel] [PATCH +stable] block: don't attempt to merge overla= pping >>>>> requests >>>>> >>>>> quick tests shows it works correctly so far. >>>>> At least it went further than before, not >>>>> stopping at the "usual" sector 3145727872. >>>>> >>>>> Hmm. Ide has no queue, hence no mergeing, >>>>> that's why it does not occur with ide, >>>>> right? :) >>>> > [] >>>> Yes. Why would Linux post overlapping requests? makes >>>> 0xffffffff00000000 >>>> sense. > [] >>> Note also that it's not as on the original bugreport - >>> there, the sector# is apparently different: >>> http://sourceforge.net/tracker/?func=3Ddetail&aid=3D2933400&group_i= d=3D180599&atid=3D893831 >>> >> >> I don't think it's related to a particular sector number. > > I added a debug printf into the place that is touched > by the patch mentioned above, to print the case where > the request were merged before that patch but not any > more with it applied: > > if (reqs[i].sector =3D=3D oldreq_last) { > merge =3D 1; > } > else if (reqs[i].sector < oldreq_last) > fprintf(stderr, "NOT mergeing:\n" > " reqs[i].sector=3D%Ld oldreq_last=3D%Ld\n" > " reqs[outidx].sector=3D%Ld reqs[outidx].nb_sectors=3D%d\n" > , reqs[i].sector, oldreq_last, > reqs[outidx].sector, reqs[outidx].nb_sectors); > > In a few runs it showed different info (and I modified the > printf line 2 times too): > > NOT mergeing: reqs[i].sector=3D92306456 oldreq_last=3D3145728000 > NOT mergeing: > reqs[i].sector=3D92322056 oldreq_last=3D3145728000 > reqs[outidx].sector=3D3145727872 > NOT mergeing: > reqs[i].sector=3D0 oldreq_last=3D3145728000 > reqs[outidx].sector=3D3145727872 reqs[outidx].nb_sectors=3D128 > NOT mergeing: > reqs[i].sector=3D0 oldreq_last=3D3145728000 > reqs[outidx].sector=3D3145727872 reqs[outidx].nb_sectors=3D128 > NOT mergeing: > reqs[i].sector=3D92308152 oldreq_last=3D3145728000 > reqs[outidx].sector=3D3145727872 reqs[outidx].nb_sectors=3D128 > NOT mergeing: > reqs[i].sector=3D0 oldreq_last=3D3145728000 > reqs[outidx].sector=3D3145727872 reqs[outidx].nb_sectors=3D128 > So it's definitely timing-related somehow (esp. it changes > when interrupting mkfs and immediately starting again), and > shows different values, but for me it's - apparently - always > reqs[outidx].sector=3D3145727872 together with some other sector. And once I hit "Send" it showed another: NOT mergeing: reqs[i].sector=3D760 oldreq_last=3D3141599488 reqs[outidx].sector=3D3141597896 reqs[outidx].nb_sectors=3D1592 so it's not the case here ;) > /mjt