All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Blake <eblake@redhat.com>
To: Anton Nefedov <anton.nefedov@virtuozzo.com>,
	Max Reitz <mreitz@redhat.com>,
	qemu-devel@nongnu.org
Cc: qemu-block@nongnu.org, kwolf@redhat.com, den@virtuozzo.com,
	berto@igalia.com
Subject: Re: [Qemu-devel] [PATCH v7 1/9] mirror: inherit supported write/zero flags
Date: Tue, 30 Jan 2018 10:00:08 -0600	[thread overview]
Message-ID: <fa7970fe-edbd-fd67-795b-84e83d216198@redhat.com> (raw)
In-Reply-To: <f591d261-108e-9e35-f021-b5934c278b23@virtuozzo.com>

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

On 01/30/2018 06:15 AM, Anton Nefedov wrote:

>>>> @@ -1064,6 +1064,11 @@ static void
>>>> bdrv_mirror_top_refresh_filename(BlockDriverState *bs, QDict *opts)
>>>>       bdrv_refresh_filename(bs->backing->bs);
>>>>       pstrcpy(bs->exact_filename, sizeof(bs->exact_filename),
>>>>               bs->backing->bs->filename);
>>>> +    bs->supported_write_flags = BDRV_REQ_FUA &
>>>> +        bs->backing->bs->supported_write_flags;

>>> Fundamentally OK, but why is this in *_refresh_filename()?
>>
>> Indeed, I missed that (or maybe it got moved during a botched rebase?).
>> For comparison, blkdebug sets it during blkdebug_open(), and nbd sets it
>> during nbd_client_init() (called during nbd_open()).
>>
> 
> We need a backing bs here and I believe it's not generally set at the
> time of .bdrv_open()

Then is mirror_start_job() a better location, right after we call
bdrv_new_open_driver()?  (Maybe this just goes to show I haven't fully
traced the lifecycle of the mirror driver, and it may all be changing
anyways as we try to fix the BDS graph modifications related with mirrors).

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 619 bytes --]

  reply	other threads:[~2018-01-30 16:00 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-18 17:48 [Qemu-devel] [PATCH v7 0/9] qcow2: cluster space preallocation Anton Nefedov
2018-01-18 17:48 ` [Qemu-devel] [PATCH v7 1/9] mirror: inherit supported write/zero flags Anton Nefedov
2018-01-29 19:21   ` Max Reitz
2018-01-29 19:26     ` Eric Blake
2018-01-30 12:15       ` Anton Nefedov
2018-01-30 16:00         ` Eric Blake [this message]
2018-01-31 17:20         ` Max Reitz
2018-01-18 17:49 ` [Qemu-devel] [PATCH v7 2/9] blkverify: set " Anton Nefedov
2018-01-29 19:23   ` Max Reitz
2018-01-18 17:49 ` [Qemu-devel] [PATCH v7 3/9] block: introduce BDRV_REQ_ALLOCATE flag Anton Nefedov
2018-01-29 19:37   ` Max Reitz
2018-01-30 12:34     ` Anton Nefedov
2018-01-31 17:31       ` Max Reitz
2018-02-01 13:34         ` Anton Nefedov
2018-02-01 18:06           ` Max Reitz
2018-01-18 17:49 ` [Qemu-devel] [PATCH v7 4/9] block: treat BDRV_REQ_ALLOCATE as serialising Anton Nefedov
2018-01-29 19:48   ` Max Reitz
2018-01-30 12:36     ` Anton Nefedov
2018-01-31 17:35       ` Max Reitz
2018-01-31 15:11   ` Alberto Garcia
2018-01-31 17:11     ` Anton Nefedov
2018-02-01 14:01       ` Alberto Garcia
2018-01-18 17:49 ` [Qemu-devel] [PATCH v7 5/9] file-posix: support BDRV_REQ_ALLOCATE Anton Nefedov
2018-01-29 19:56   ` Max Reitz
2018-01-18 17:49 ` [Qemu-devel] [PATCH v7 6/9] block: support BDRV_REQ_ALLOCATE in passthrough drivers Anton Nefedov
2018-01-29 19:58   ` Max Reitz
2018-01-18 17:49 ` [Qemu-devel] [PATCH v7 7/9] qcow2: move is_zero() up Anton Nefedov
2018-01-29 19:59   ` Max Reitz
2018-01-18 17:49 ` [Qemu-devel] [PATCH v7 8/9] qcow2: skip writing zero buffers to empty COW areas Anton Nefedov
2018-01-29 20:28   ` Max Reitz
2018-01-30 14:23     ` Anton Nefedov
2018-01-31 17:40       ` Max Reitz
2018-01-31 18:32         ` Eric Blake
2018-01-31 18:35           ` Max Reitz
2018-01-31 18:43             ` Eric Blake
2018-01-18 17:49 ` [Qemu-devel] [PATCH v7 9/9] iotest 134: test cluster-misaligned encrypted write Anton Nefedov
2018-01-29 20:30   ` Max Reitz
2018-01-30 13:03   ` Alberto Garcia

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=fa7970fe-edbd-fd67-795b-84e83d216198@redhat.com \
    --to=eblake@redhat.com \
    --cc=anton.nefedov@virtuozzo.com \
    --cc=berto@igalia.com \
    --cc=den@virtuozzo.com \
    --cc=kwolf@redhat.com \
    --cc=mreitz@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    /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.