From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1M1NLx-0000Sd-AU for qemu-devel@nongnu.org; Tue, 05 May 2009 12:18:45 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1M1NLs-0000Q2-Nw for qemu-devel@nongnu.org; Tue, 05 May 2009 12:18:44 -0400 Received: from [199.232.76.173] (port=56490 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M1NLs-0000Pw-HZ for qemu-devel@nongnu.org; Tue, 05 May 2009 12:18:40 -0400 Received: from mx2.redhat.com ([66.187.237.31]:52019) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1M1NLr-0000CU-6X for qemu-devel@nongnu.org; Tue, 05 May 2009 12:18:40 -0400 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n45GIaVj028044 for ; Tue, 5 May 2009 12:18:36 -0400 Message-ID: <4A0066D9.6030008@redhat.com> Date: Tue, 05 May 2009 19:18:33 +0300 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] Strange virtio regression on mainline and stable-0.10 References: <4A000C74.5020907@redhat.com> In-Reply-To: <4A000C74.5020907@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: qemu-devel Avi Kivity wrote: > Running the Fedora 10 installer on a virtio disk on current master and > on v0.10.3 will cause the installer to complain when mounting the > freshly formatted filesystems. The problem is that qcow2 does a read-modify-write on non-cluster-aligned writes. So the following sequence triggers the bug: guest: write(sector=0, count=1) (A) guest: write(sector=1, count=1) (B) qemu: read(sector=0, count=16) (A) qemu: submit aio write (sector=0, count=16) (A) qemu: read(sector=0, count=16) (B) qemu: submit aio write (sector=0, count=16) (B) - contains data from before A's write This could be solved by maintaining a hash table of refcounted RMW copies for the disk. When reading for a RMW, look up the hash table, if there's a copy there, use it instead of reading it yourself. We should also avoid the RMW for non-compressed, non-encrypted clusters, as virtually ALL writes will be misaligned. -- error compiling committee.c: too many arguments to function