From: Kevin Wolf <kwolf@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: qemu-devel@nongnu.org, stefanha@linux.vnet.ibm.com
Subject: Re: [Qemu-devel] [PATCH] block: push recursive flushing up from drivers
Date: Mon, 12 Mar 2012 17:22:33 +0100 [thread overview]
Message-ID: <4F5E22C9.1000701@redhat.com> (raw)
In-Reply-To: <1331568108-13188-1-git-send-email-pbonzini@redhat.com>
Am 12.03.2012 17:01, schrieb Paolo Bonzini:
> In most cases, bdrv_co_flush_to_disk just needs to flush the underlying
> file for protocols. Do this implicitly in the block layer.
>
> The backing file is also flushed, because it may still be open read-write
> in the case of live snapshots.
Is this an independent change? I'm also not convinced that it's the
right thing to do because even though it is still opened read-write, we
don't write to it any more. Once bdrv_reopen() is ready, we'll want to
change it to read-only after taking the snapshot.
> @@ -3516,10 +3514,13 @@ int coroutine_fn bdrv_co_flush(BlockDriverState *bs)
> {
> int ret;
>
> - if (!bs->drv) {
> + if (!bs || !bdrv_is_inserted(bs) || bdrv_is_read_only(bs)) {
> return 0;
> }
>
> + bdrv_co_flush(bs->file);
> + bdrv_co_flush(bs->backing_hd);
Error handling is missing here.
> +
> /* Write back cached data to the OS even with cache=unsafe */
> if (bs->drv->bdrv_co_flush_to_os) {
> ret = bs->drv->bdrv_co_flush_to_os(bs);
Now you first flush bs->file and then write out the internal caches.
This doesn't look quite right. Probably the recursion should be at the
very end of the function.
Kevin
next prev parent reply other threads:[~2012-03-12 16:19 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-12 16:01 [Qemu-devel] [PATCH] block: push recursive flushing up from drivers Paolo Bonzini
2012-03-12 16:22 ` Kevin Wolf [this message]
2012-03-12 16:22 ` 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=4F5E22C9.1000701@redhat.com \
--to=kwolf@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@linux.vnet.ibm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).