From mboxrd@z Thu Jan  1 00:00:00 1970
From: Michael Tokarev <mjt@tls.msk.ru>
Subject: Re: the >1Tb  block issue
Date: Tue, 18 May 2010 22:38:41 +0400
Message-ID: <4BF2DEB1.2010109@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>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: KVM list <kvm@vger.kernel.org>, Christoph Hellwig <hch@lst.de>
To: Avi Kivity <avi@redhat.com>
Return-path: <kvm-owner@vger.kernel.org>
Received: from isrv.corpit.ru ([81.13.33.159]:50839 "EHLO isrv.corpit.ru"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1753225Ab0ERSin (ORCPT <rfc822;kvm@vger.kernel.org>);
	Tue, 18 May 2010 14:38:43 -0400
In-Reply-To: <4BF2D7C4.4080104@redhat.com>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

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 overlapping
>>>> 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=detail&aid=2933400&group_id=180599&atid=893831
>
> 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 == oldreq_last) {
             merge = 1;
         }
else if (reqs[i].sector < oldreq_last)
  fprintf(stderr, "NOT mergeing:\n"
" reqs[i].sector=%Ld oldreq_last=%Ld\n"
" reqs[outidx].sector=%Ld reqs[outidx].nb_sectors=%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=92306456 oldreq_last=3145728000
NOT mergeing:
  reqs[i].sector=92322056 oldreq_last=3145728000
  reqs[outidx].sector=3145727872
NOT mergeing:
  reqs[i].sector=0 oldreq_last=3145728000
  reqs[outidx].sector=3145727872 reqs[outidx].nb_sectors=128
NOT mergeing:
  reqs[i].sector=0 oldreq_last=3145728000
  reqs[outidx].sector=3145727872 reqs[outidx].nb_sectors=128
NOT mergeing:
  reqs[i].sector=92308152 oldreq_last=3145728000
  reqs[outidx].sector=3145727872 reqs[outidx].nb_sectors=128
NOT mergeing:
  reqs[i].sector=0 oldreq_last=3145728000
  reqs[outidx].sector=3145727872 reqs[outidx].nb_sectors=128

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=3145727872 together with some other sector.

/mjt