public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Avi Kivity <avi@redhat.com>
To: Michael Tokarev <mjt@tls.msk.ru>
Cc: KVM list <kvm@vger.kernel.org>, Christoph Hellwig <hch@lst.de>
Subject: Re: the >1Tb  block issue
Date: Tue, 18 May 2010 21:09:08 +0300	[thread overview]
Message-ID: <4BF2D7C4.4080104@redhat.com> (raw)
In-Reply-To: <4BF2D666.1080108@msgid.tls.msk.ru>

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.


  reply	other threads:[~2010-05-18 18:09 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-18 15:52 the >1Tb block issue Michael Tokarev
2010-05-18 15:59 ` Daniel P. Berrange
2010-05-18 16:51 ` Michael Tokarev
2010-05-18 16:58   ` Gleb Natapov
2010-05-18 17:29 ` Avi Kivity
2010-05-18 17:34   ` Michael Tokarev
2010-05-18 17:38     ` Avi Kivity
2010-05-18 18:03       ` Michael Tokarev
2010-05-18 18:09         ` Avi Kivity [this message]
2010-05-18 18:38           ` Michael Tokarev
2010-05-18 18:43             ` Michael Tokarev
2010-05-19  8:57       ` Christoph Hellwig
2010-05-19  9:03         ` Avi Kivity

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4BF2D7C4.4080104@redhat.com \
    --to=avi@redhat.com \
    --cc=hch@lst.de \
    --cc=kvm@vger.kernel.org \
    --cc=mjt@tls.msk.ru \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox