From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:57715) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UhOC5-0005dY-4l for qemu-devel@nongnu.org; Tue, 28 May 2013 14:00:44 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UhOBx-0001FR-Rk for qemu-devel@nongnu.org; Tue, 28 May 2013 14:00:21 -0400 Received: from atl4mhob12.myregisteredsite.com ([209.17.115.50]:39341) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UhOBx-0001FL-Mg for qemu-devel@nongnu.org; Tue, 28 May 2013 14:00:13 -0400 From: "Mark Trumpold" Message-ID: Date: Tue, 28 May 2013 18:00:08 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] 'qemu-nbd' explicit flush List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi , Mark Trumpold Cc: Paolo Bonzini , qemu-devel@nongnu.org, markt@tachyon.net >-----Original Message----- >From: Stefan Hajnoczi [mailto:stefanha@gmail.com] >Sent: Monday, May 27, 2013 05:36 AM >To: 'Mark Trumpold' >Cc: 'Paolo Bonzini', qemu-devel@nongnu.org, markt@tachyon.net >Subject: Re: 'qemu-nbd' explicit flush > >On Sat, May 25, 2013 at 09:42:08AM -0800, Mark Trumpold wrote: >> On 5/24/13 1:05 AM, "Stefan Hajnoczi" wrote: >> >On Thu, May 23, 2013 at 09:58:31PM +0000, Mark Trumpold wrote: >> >One thing to be careful of is whether these operations are asynchrono= us. >> >The signal is asynchronous, you have no way of knowing when qemu-nbd = is >> >finished flushing to the physical disk. >> >> Right, of course. I missed the obvious. > >I missed something too. Paolo may have already hinted at this when he >posted a dd oflag=3Dsync command-line option: > >blockdev --flushbufs is the wrong tool because ioctl(BLKFLSBUF) only >writes out dirty pages to the block device. It does *not* guarantee to >send a flush request to the device. > >Therefore, the underlying image file may not be put into an up-to-date >state by qemu-nbd. > > >I suggest trying the following instead of blockdev --flushbufs: > > python -c 'import os; os.fsync(open("/dev/loopX", "r+b"))' > >This should do the same as blockdev --flushbufs *plus* it sends and >waits for the NBD FLUSH command. > >You may have to play with this command-line a little but the main idea >is to open the block device and fsync it. > >Stefan > Hi Stefan, One of my early experiments was adding a command line option to 'qemu-nbd= ' that did an open on 'device' (similar to the -c option), and then calli= ng 'fsync' on the 'device'. By itself, I did not get a complete flush to= disk. Was I missing something? Empirically, the signal solution (blockdev --flushbufs plus 'bdrv_flush_a= ll') was keeping my disk consistent. My unit test exercises the flush an= d snapshot pretty rigorously; that is, it never passed before with 'qemu-= nbd --cache=3Dwriteback ...'. However, I did not want to rely on 'sleep'= for the race condition. Is there any opportunity with the nbd client socket interface? The advan= tage for me there is not modifying 'qemu-nbd' source. Paolo had also mentioned taking a look at the newer 3.9 kernel for ideas,= and possibly back porting. I have not spent any time on this yet.. Thanks for all yours and Paolo's attention on this. Mark T.