All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Trumpold <markt@netqa.com>
To: Stefan Hajnoczi <stefanha@gmail.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"markt@tachyon.net" <markt@tachyon.net>
Subject: Re: [Qemu-devel] 'qemu-nbd' explicit flush
Date: Sat, 25 May 2013 09:42:08 -0800	[thread overview]
Message-ID: <CDC63015.85FF%markt@netqa.com> (raw)
In-Reply-To: <20130524090516.GE21639@stefanha-thinkpad.redhat.com>

On 5/24/13 1:05 AM, "Stefan Hajnoczi" <stefanha@gmail.com> wrote:

>On Thu, May 23, 2013 at 09:58:31PM +0000, Mark Trumpold wrote:
>> I have a working configuration using the signal approach suggested by
>>Stefan.
>> 
>> 'qemu-nbd.c' is patched as follows:
>> 
>>     do {
>>         main_loop_wait(false);
>> +       if (sighup_reported) {
>> +           sighup_reported = false;
>> +           bdrv_drain_all();
>> +           bdrv_flush_all();
>>         }
>>     } while (!sigterm_reported && (persistent || !nbd_started || nb_fds
>>> 0));
>> 
>> The driving script was patched as follows:
>> 
>>      mount -o remount,ro /dev/nbd0
>>      blockdev --flushbufs /dev/nbd0
>> +    kill -HUP <qemu-nbd process id>
>> 
>> I needed to retain 'blockdev --flushbufs' for things to work.  Seems
>>the 'bdrv_flush_all' is flushing what is being missed by the blockdev
>>flush.  I did not go back an retest with 'fsync' or other approaches I
>>had tried before.
>
>Okay, that makes sense:
>
>'blockdev --flushbufs' is writing dirty pages to the NBD device.
>
>bdrv_drain_all() + bdrv_flush_all() ensures that image file writes reach
>the physical disk.
>
>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 didn't check blockdev(8) but it could be the same there.
>
>So watch out, otherwise your script is timing-dependent and may not
>actually have finished flushing when you take the snapshot.
>
>Stefan
>

The race condition would not be acceptable.  You had mentioned another
approach using the socket interface:

>2. Instantiate a block/nbd.c client that connects to the running
>   qemu-nbd server (make sure format=raw).  Then call bdrv_flush() on
>   the NBD client.  You must use the qemu-nbd --shared=2 option.
>

In my case I only have a 'qemu-nbd' process per loop device.  Would the
'qemu-nbd' process act as the socket server, and I would then write a
simple socket client to instruct him to do the flush?  And, would the
client block until the flush is complete?

Thank you,
Mark T.

  reply	other threads:[~2013-05-25 16:42 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-23 21:58 [Qemu-devel] 'qemu-nbd' explicit flush Mark Trumpold
2013-05-24  9:05 ` Stefan Hajnoczi
2013-05-25 17:42   ` Mark Trumpold [this message]
2013-05-27 12:36     ` Stefan Hajnoczi
2013-05-24 12:10 ` Paolo Bonzini
  -- strict thread matches above, loose matches on Subject: below --
2013-05-28 18:00 Mark Trumpold
2013-05-29  7:42 ` Stefan Hajnoczi
2013-05-29 15:29   ` Mark Trumpold
2013-06-07 14:00   ` Mark Trumpold
2013-05-23 23:35 Mark Trumpold
2013-05-24  9:06 ` Stefan Hajnoczi
2013-05-22 16:10 Mark Trumpold
2013-05-21 20:01 Mark Trumpold
2013-05-22  9:47 ` Stefan Hajnoczi
2013-05-22 11:07   ` Paolo Bonzini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CDC63015.85FF%markt@netqa.com \
    --to=markt@netqa.com \
    --cc=markt@tachyon.net \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.