From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=41301 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1P63Yw-0005hj-Ts for qemu-devel@nongnu.org; Wed, 13 Oct 2010 11:48:20 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1P63TH-0006RD-UY for qemu-devel@nongnu.org; Wed, 13 Oct 2010 11:42:29 -0400 Received: from e39.co.us.ibm.com ([32.97.110.160]:34788) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1P63TH-0006Qm-PW for qemu-devel@nongnu.org; Wed, 13 Oct 2010 11:42:27 -0400 Received: from d03relay03.boulder.ibm.com (d03relay03.boulder.ibm.com [9.17.195.228]) by e39.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id o9DFVbun019730 for ; Wed, 13 Oct 2010 09:31:37 -0600 Received: from d03av05.boulder.ibm.com (d03av05.boulder.ibm.com [9.17.195.85]) by d03relay03.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o9DFgPIa210336 for ; Wed, 13 Oct 2010 09:42:25 -0600 Received: from d03av05.boulder.ibm.com (loopback [127.0.0.1]) by d03av05.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id o9DFgOqa008687 for ; Wed, 13 Oct 2010 09:42:25 -0600 Message-ID: <4CB5D35E.9040103@linux.vnet.ibm.com> Date: Wed, 13 Oct 2010 10:42:22 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [PATCH v2 6/7] qed: Read/write support References: <1286552914-27014-7-git-send-email-stefanha@linux.vnet.ibm.com> <4CB479D2.7030901@redhat.com> <4CB47D38.3060602@linux.vnet.ibm.com> <4CB48144.9030607@redhat.com> <20101012155953.GA13872@stefan-thinkpad.transitives.com> <4CB489D1.3050204@linux.vnet.ibm.com> <20101013121328.GB8998@stefan-thinkpad.transitives.com> <4CB5AF0D.9000800@redhat.com> <4CB5B2FD.9030205@linux.vnet.ibm.com> <4CB5B908.1020406@redhat.com> <20101013140715.GF8998@stefan-thinkpad.transitives.com> <4CB5BDD1.8050409@redhat.com> <4CB5BE25.3060502@linux.vnet.ibm.com> <4CB5BF2D.3080500@redhat.com> <4CB5C7EA.4000305@linux.vnet.ibm.com> <4CB5CB69.3000103@redhat.com> In-Reply-To: <4CB5CB69.3000103@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: Avi Kivity Cc: Kevin Wolf , Christoph Hellwig , Stefan Hajnoczi , qemu-devel@nongnu.org On 10/13/2010 10:08 AM, Avi Kivity wrote: > On 10/13/2010 04:53 PM, Anthony Liguori wrote: >> On 10/13/2010 09:16 AM, Avi Kivity wrote: >>> On 10/13/2010 04:11 PM, Anthony Liguori wrote: >>>>> Why would you ever update the header, apart from relocating L1 for >>>>> some reason? >>>> >>>> >>>> To update the L1/L2 tables clean bit. That's what prevents a check >>>> in the normal case where you have a clean shutdown. >>> >>> I see - so you wouldn't update it every allocation, only when the >>> disk has been quiet for a while. >> >> Right, the current plan is to flush the header dirty bit on shutdown >> or whenever there is an explicit flush of the device. Current that >> is caused by either a guest-initiated flush or a L1 update. > > That does add an extra write (and a new write+flush later to mark the > header dirty again when you start allocating). I'd drop it and only > use the timer. > > in fact, it adds an extra flush too. The sequence > > 1 L1 update > 2 mark clean > 3 flush > > is unsafe since you can crash between 2 and 3, ad only 2 makes it. So > I'd do something like You've got the order wrong. 1. L1 update 2. flush() 3. mark clean If (3) doesn't make it to disk, that's okay. It just causes an extra scan. > 1 opportunistic flush (for whatever reason) > 2 set timer > 3 no intervening metadata changes > 4 mark clean > 5 no intervening metadata changes > 6 mark dirty > 7 flush > 8 metadata changes Not sure I see why we set the timer in step 2 as opposed to: 0 clear scheduled flush (if necessary) 1 opportunistic flush (for whatever reason) 2 mark clean 3 no intervening metadata changes 4 mark dirty 5 flush 6 schedule flush (in 5 minutes) 7 metadata changes Which is now recorded at http://wiki.qemu.org/Features/QED/ScanAvoidance so we can keep track of this. Regards, Anthony Liguori > >