All of lore.kernel.org
 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 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.