qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Max Reitz <mreitz@redhat.com>
To: phoeagon <phoeagon@gmail.com>, qemu-devel@nongnu.org
Cc: Stefan Weil <sw@weilnetz.de>, qemu-block@nongnu.org
Subject: Re: [Qemu-devel] [PATCH] use bdrv_flush to provide barrier semantic in block/vdi.c for metadata updates
Date: Wed, 06 May 2015 19:36:42 +0200	[thread overview]
Message-ID: <554A512A.4070109@redhat.com> (raw)
In-Reply-To: <CAKYApDBpL9GiLf7A0E6sff1H6zUgEmE9-pF=mndZjJiBCUpfGQ@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3057 bytes --]

CC-ing qemu-block and Stefan Weil (maintainer of vdi).

On 06.05.2015 19:23, phoeagon wrote:
> Thanks for your input.
>
> So I changed it to:
> 1. Only call bdrv_flush when bdrv_pwrite was successful
> 2. Only if bdrv_flush was unsuccessful that the return value of 
> vdi_co_write is updated.

One of both is enough. Both are too much. :-)

It is indeed correct, technically (because ret is 0 before the 
bdrv_write()), but it's too verbose. (See below)

> In this way we try to avoid messing up any potential return value 
> checks possible while still propagating bdrv_flush errors.
> That return value was a catch and I admit I'm no pro with the return 
> value convention in QEMU. bdrv_pwrite doesn't return the same value as 
> bdrv_pwrite_sync I assume (they do return negative values when fail, 
> but different values when successful)

It doesn't really matter, I think. Returning any non-negative value from 
vdi_co_write() should be enough to signal success.

> ---
>
>
> Signed-off-by: Zhe Qiu <address@hidden>
>
> From 19b2fabbe00765b418362d8c1891f266091621f3 Mon Sep 17 00:00:00 2001
> From: phoeagon <address-hidden>
> Date: Thu, 7 May 2015 01:09:38 +0800
> Subject: [PATCH] block/vdi: Use bdrv_flush after metadata updates
>
> In reference to 
> b0ad5a455d7e5352d4c86ba945112011dbeadfb8~078a458e077d6b0db262c4b05fee51d01de2d1d2, 
> metadata writes to qcow2/cow/qcow/vpc/vmdk are all synced prior to 
> succeeding writes.
>
> ---
>  block/vdi.c | 6 +++++-
>  1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/block/vdi.c b/block/vdi.c
> index 5d09b36..54a5fa8 100644
> --- a/block/vdi.c
> +++ b/block/vdi.c
> @@ -713,7 +713,11 @@ static int vdi_co_write(BlockDriverState *bs,
>          logout("will write %u block map sectors starting from entry 
> %u\n",
>                 n_sectors, bmap_first);
>          ret = bdrv_write(bs->file, offset, base, n_sectors);
> +        if (!(ret < 0)) {
> +            int flush_ret = bdrv_flush(bs->file);
> +            if (flush_ret < 0)
> +                ret = flush_ret;
> +        }

I think bdrv_write() always returns 0 on success. In any case, it's fine 
for vdi_co_write() to return 0 on success (which is what bdrv_flush() 
returns), so shorting these four lines to "ret = bdrv_flush(bs->file);" 
is enough.

The patch is correct, though, so if you want to leave it as it is, all 
you need to do is bring it into proper form 
(http://wiki.qemu.org/Contribute/SubmitAPatch).

The previous version was nearly right, except for the things I 
mentioned: The subject needs to start with the part of qemu the patch is 
targeting (in this case "block/vdi: " or simply "vdi: "), the 
Signed-off-by needs to contain your name (or any alias you desire) and 
your email address, and comments for the patch should be separated from 
the actual commit message by "---".

Finally, for sending the next version, please change the "[PATCH]" in 
the subject to "[PATCH v3]" in order to indicate that it will be version 
3 of this patch.

Thanks!

Max

>      }
>      return ret;
> -- 
> 2.4.0


[-- Attachment #2: Type: text/html, Size: 7645 bytes --]

      parent reply	other threads:[~2015-05-06 17:37 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-01 15:03 [Qemu-devel] [PATCH] use bdrv_flush to provide barrier semantic in block/vdi.c for metadata updates phoeagon
2015-05-06 16:42 ` Max Reitz
2015-05-06 17:23   ` phoeagon
2015-05-06 17:28     ` Eric Blake
2015-05-06 17:36     ` Max Reitz [this message]

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=554A512A.4070109@redhat.com \
    --to=mreitz@redhat.com \
    --cc=phoeagon@gmail.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=sw@weilnetz.de \
    /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).