qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Max Reitz <mreitz@redhat.com>
To: Kevin Wolf <kwolf@redhat.com>, qemu-block@nongnu.org
Cc: qemu-devel@nongnu.org, eblake@redhat.com, stefanha@redhat.com,
	jcody@redhat.com
Subject: Re: [Qemu-devel] blockdev-commit design
Date: Wed, 27 Sep 2017 18:29:33 +0200	[thread overview]
Message-ID: <d53e621c-9c9a-3661-8b1c-3bdf4f651f79@redhat.com> (raw)
In-Reply-To: <20170926175942.GE14717@localhost.localdomain>

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

On 2017-09-26 19:59, Kevin Wolf wrote:

[...]

>   * The old block-commit command decides between an "actual" commit job
>     and the mirror-based active commit based on whether top is the
>     active layer.
> 
>     We don't get an option for the active layer any more now, so this
>     isn't how things can work for blockdev-commit. We could probably
>     check whether top has a BlockBackend parent, but that's not really
>     what we're interested in anyway. Maybe the best we could do to
>     decide this automatically is to check whether there is any parent of
>     top that requires write permissions. If there is, we need active
>     commit, otherwise the "normal" one is good enough.
> 
>     However, who says that the intentions of the user stay as we deduce
>     them at the start of the block job? Who says that the user doesn't
>     want to add a writable disk as a user of the node while the block
>     job is running?
> 
>     The optimal solution to this would be that the commit filter node
>     responds to permission requests and switches between active and
>     "normal" commit mode. I'm not sure how hard this would be to
>     implement.
> 
>     As long as we don't have the automatic switch, do we have to allow
>     the user to specify explicitly which mode they want instead of
>     automatically choosing one?

Probably a stupid question: What advantage does the commit job have over
the mirror job? I.e. would it be possible to just always do a mirror?

Max


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

  parent reply	other threads:[~2017-09-27 16:29 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-26 17:59 [Qemu-devel] blockdev-commit design Kevin Wolf
2017-09-26 18:29 ` Eric Blake
2017-09-26 19:11   ` Kevin Wolf
2017-09-27 16:29 ` Max Reitz [this message]
2017-10-02 15:01 ` [Qemu-devel] [Qemu-block] " Kashyap Chamarthy
2017-10-02 15:32   ` Kevin Wolf
2017-10-03  8:00     ` Kashyap Chamarthy

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=d53e621c-9c9a-3661-8b1c-3bdf4f651f79@redhat.com \
    --to=mreitz@redhat.com \
    --cc=eblake@redhat.com \
    --cc=jcody@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.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).