From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:48964) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UhhNk-00013k-G4 for qemu-devel@nongnu.org; Wed, 29 May 2013 10:29:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UhhNf-00031h-EE for qemu-devel@nongnu.org; Wed, 29 May 2013 10:29:40 -0400 Received: from atl4mhob07.myregisteredsite.com ([209.17.115.45]:37621) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UhhNf-00031N-9A for qemu-devel@nongnu.org; Wed, 29 May 2013 10:29:35 -0400 Received: from mail.hostingplatform.com ([10.30.71.210]) by atl4mhob07.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id r4TETY6M001595 for ; Wed, 29 May 2013 10:29:34 -0400 Date: Wed, 29 May 2013 07:29:26 -0800 From: Mark Trumpold Message-ID: In-Reply-To: <20130529074215.GB20199@stefanha-thinkpad.redhat.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [Qemu-devel] 'qemu-nbd' explicit flush List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: Paolo Bonzini , "qemu-devel@nongnu.org" , "markt@tachyon.net" On 5/28/13 11:42 PM, "Stefan Hajnoczi" wrote: >On Tue, May 28, 2013 at 06:00:08PM +0000, Mark Trumpold wrote: >> >> >-----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 >>asynchronous. >> >> >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=sync 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 calling '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_all') was keeping my disk consistent. My unit test >>exercises the flush and snapshot pretty rigorously; that is, it never >>passed before with 'qemu-nbd --cache=writeback ...'. However, I did not >>want to rely on 'sleep' for the race condition. >> >> Is there any opportunity with the nbd client socket interface? The >>advantage for me there is not modifying 'qemu-nbd' source. > >I'm suggesting that you don't need to modify qemu-nbd. If your host is >running nbd.ko with flush support, then it should be enough to open the >device and issue fsync(2). > >You can verify this using tcpdump(8) and checking that the NBD FLUSH >command is really being sent by the host kernel. If not, double check >you're using the latest nbd.ko. > >Stefan > Got it. I will try this approach with python. Thank again, Mark T.