From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MiRxO-0002SK-F3 for qemu-devel@nongnu.org; Tue, 01 Sep 2009 07:55:26 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MiRxJ-0002S8-0y for qemu-devel@nongnu.org; Tue, 01 Sep 2009 07:55:25 -0400 Received: from [199.232.76.173] (port=59969 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MiRxI-0002S5-RO for qemu-devel@nongnu.org; Tue, 01 Sep 2009 07:55:20 -0400 Received: from mx1.redhat.com ([209.132.183.28]:62736) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MiRxI-0003QY-8O for qemu-devel@nongnu.org; Tue, 01 Sep 2009 07:55:20 -0400 Received: from int-mx08.intmail.prod.int.phx2.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.21]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id n81BtJvh013325 for ; Tue, 1 Sep 2009 07:55:19 -0400 Message-ID: <4A9D0BA5.7080207@redhat.com> Date: Tue, 01 Sep 2009 14:55:17 +0300 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] qcow2: Order concurrent AIO requests on the same unallocated cluster References: <1251730129-18693-1-git-send-email-kwolf@redhat.com> <4A9CF517.30701@redhat.com> <4A9CFC64.7050603@redhat.com> <4A9D047E.1040208@redhat.com> <4A9D08FE.4070008@redhat.com> In-Reply-To: <4A9D08FE.4070008@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; 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@nongnu.org On 09/01/2009 02:43 PM, Kevin Wolf wrote: > Avi Kivity schrieb: > >> On 09/01/2009 01:50 PM, Kevin Wolf wrote: >> >>> You >>> are worried about image fragmentation? I think we could do something >>> about it with a cleverer cluster allocation. >>> >>> >> Not only image fragmentation - the odd requests will require RMW. >> > How that? > > The case you're thinking of is that the first and third request are > already completed and then the second one starts, right? Assuming that > request 2 involves some sectors in the last cluster of 1 and the first > one of 3. > > Then request 2 is written in three phases: The first one overwrites the > last sectors of requests 1 (cluster already allocated => no RMW). The > second one writes to unallocated, cluster-aligned space (writing > complete clusters => no RMW). The third one overwrites the first sectors > of request 3 (cluster already allocated => no RMW). > Ah, ok. No RMW, but a three-way split as well as fragmentation. -- error compiling committee.c: too many arguments to function