From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=58997 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1P62wg-0003Hq-Q2 for qemu-devel@nongnu.org; Wed, 13 Oct 2010 11:08:48 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1P62we-0007VB-KC for qemu-devel@nongnu.org; Wed, 13 Oct 2010 11:08:46 -0400 Received: from mx1.redhat.com ([209.132.183.28]:24372) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1P62we-0007V5-E4 for qemu-devel@nongnu.org; Wed, 13 Oct 2010 11:08:44 -0400 Message-ID: <4CB5CB69.3000103@redhat.com> Date: Wed, 13 Oct 2010 17:08:25 +0200 From: Avi Kivity 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> In-Reply-To: <4CB5C7EA.4000305@linux.vnet.ibm.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: Anthony Liguori Cc: Kevin Wolf , Christoph Hellwig , Stefan Hajnoczi , qemu-devel@nongnu.org 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 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 -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.