From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: the >1Tb block issue Date: Tue, 18 May 2010 21:09:08 +0300 Message-ID: <4BF2D7C4.4080104@redhat.com> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: KVM list , Christoph Hellwig To: Michael Tokarev Return-path: Received: from mx1.redhat.com ([209.132.183.28]:24077 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753949Ab0ERSJW (ORCPT ); Tue, 18 May 2010 14:09:22 -0400 In-Reply-To: <4BF2D666.1080108@msgid.tls.msk.ru> Sender: kvm-owner@vger.kernel.org List-ID: 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. > > I tried multiple times to reproduce it with if=scsi > (queue_depth=16 for the sym53c8xx driver). I can't. > JFYI.. ;) Merging needs explicit support in the block device emulation, which scsi lacks. > >>> Interesting... >> >> Yes. Why would Linux post overlapping requests? makes 0xffffffff00000000 >> sense. > > It's mkfs. mkfs simply writes to the block device, even if it does issue overlapping writes, Linux shouldn't. Either the writes contain the same content in the overlapping section, in which case it's redundant, or they don't, and we have data corruption in the making. > Not sure why, but yes, maybe it's a guest > bug after all. It's a host bug for sure, with a potential for a guest bug. > Note that I'm running 64bit kernel on > the guest (2.6.32.9-amd64). > > 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 have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.