From: Eric Blake <eblake@redhat.com>
To: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>,
qemu-devel@nongnu.org, qemu-block@nongnu.org
Cc: kwolf@redhat.com, famz@redhat.com, ronniesahlberg@gmail.com,
jcody@redhat.com, pl@kamp.de, mreitz@redhat.com,
stefanha@redhat.com, den@openvz.org, pbonzini@redhat.com,
jsnow@redhat.com
Subject: Re: [Qemu-devel] [PATCH v3 1/4] block: disallow BDRV_REQ_NO_SERIALISING for write
Date: Fri, 6 Jul 2018 16:32:57 -0500 [thread overview]
Message-ID: <2da7c234-6157-18d5-139b-2d4d5480c6b9@redhat.com> (raw)
In-Reply-To: <20180705074638.770905-2-vsementsov@virtuozzo.com>
On 07/05/2018 02:46 AM, Vladimir Sementsov-Ogievskiy wrote:
> Before commit 9ded4a01149 "backup: Use copy offloading",
> BDRV_REQ_NO_SERIALISING was used for only one case: read in
> copy-on-write operation during backup. Also, the flag was handled only
> on read path (in bdrv_co_preadv and bdrv_aligned_preadv).
>
> After 9ded4a01149, flag is used for not waiting serializing operations
> on backup target (in same case of copy-on-write operation). This
> behavior change is unsubstantiated and potentially dangerous, let's
> drop it.
>
> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
> ---
> include/block/block.h | 13 +++++++++++++
> block/io.c | 7 ++++++-
> 2 files changed, 19 insertions(+), 1 deletion(-)
>
Commenting only on the grammar:
> diff --git a/include/block/block.h b/include/block/block.h
> index e5c7759a0c..a06a4d27de 100644
> --- a/include/block/block.h
> +++ b/include/block/block.h
> @@ -50,6 +50,19 @@ typedef enum {
> * opened with BDRV_O_UNMAP.
> */
> BDRV_REQ_MAY_UNMAP = 0x4,
> +
> + /* The BDRV_REQ_NO_SERIALISING means that we don't want to
> + * wait_serialising_requests(), when reading.
Either:
/* BDRV_REQ_NO_SERALISING means that...
or
/* The BDRV_REQ_NO_SERIALISING flag means that...
s/want to/want/
> + *
> + * This flag is used for backup copy on write operation, when we need to
> + * read old data before write (write notifier triggered). It is ok, due to
> + * we already waited for serializing requests in initiative write (see
> + * bdrv_aligned_pwritev), and it is necessary for the case when initiative
> + * write is serializing itself (we'll dead lock waiting it).
It is okay since we already waited for other serializing requests in the
initiating write (see bdrv_aligned_pwritev), and it is necessary since
the initiating write is already serializing (without the flag, the read
would deadlock waiting for the write to complete).
> + *
> + * The described case is the only usage for the flag for now, so, it is
> + * supported only for read operation and restricted for write.
This last sentence is rather wordy; I'm fine with just:
The flag is only valid during read operations.
> + */
> BDRV_REQ_NO_SERIALISING = 0x8,
> BDRV_REQ_FUA = 0x10,
> BDRV_REQ_WRITE_COMPRESSED = 0x20,
We're inconsistent on which flags we document; it might be nice to have
a comment for each of them. But not necessarily this patch's problem.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
next prev parent reply other threads:[~2018-07-06 21:33 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-05 7:46 [Qemu-devel] [PATCH v3 0/4] fix image fleecing Vladimir Sementsov-Ogievskiy
2018-07-05 7:46 ` [Qemu-devel] [PATCH v3 1/4] block: disallow BDRV_REQ_NO_SERIALISING for write Vladimir Sementsov-Ogievskiy
2018-07-06 21:32 ` Eric Blake [this message]
2018-07-06 21:46 ` Eric Blake
2018-07-09 16:08 ` Vladimir Sementsov-Ogievskiy
2018-07-09 15:56 ` Vladimir Sementsov-Ogievskiy
2018-07-05 7:46 ` [Qemu-devel] [PATCH v3 2/4] block: split flags in copy_range Vladimir Sementsov-Ogievskiy
2018-07-05 7:46 ` [Qemu-devel] [PATCH v3 3/4] block: add BDRV_REQ_SERIALISING flag Vladimir Sementsov-Ogievskiy
2018-07-06 21:52 ` Eric Blake
2018-07-05 7:46 ` [Qemu-devel] [PATCH v3 4/4] block/backup: fix fleecing scheme: use serialized writes Vladimir Sementsov-Ogievskiy
2018-07-06 7:17 ` [Qemu-devel] [PATCH v3 0/4] fix image fleecing Fam Zheng
2018-07-06 13:41 ` Vladimir Sementsov-Ogievskiy
2018-07-06 14:34 ` Vladimir Sementsov-Ogievskiy
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=2da7c234-6157-18d5-139b-2d4d5480c6b9@redhat.com \
--to=eblake@redhat.com \
--cc=den@openvz.org \
--cc=famz@redhat.com \
--cc=jcody@redhat.com \
--cc=jsnow@redhat.com \
--cc=kwolf@redhat.com \
--cc=mreitz@redhat.com \
--cc=pbonzini@redhat.com \
--cc=pl@kamp.de \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=ronniesahlberg@gmail.com \
--cc=stefanha@redhat.com \
--cc=vsementsov@virtuozzo.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).