qemu-block
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-block] [Qemu-devel] [PATCH for-2.10 2/4] block-backend: Allow


From: Fam Zheng
Subject: Re: [Qemu-block] [Qemu-devel] [PATCH for-2.10 2/4] block-backend: Allow more "can inactivate" cases
Date: Wed, 23 Aug 2017 22:47:46 +0800
User-agent: Mutt/1.8.3 (2017-05-23)

On Wed, 08/23 09:36, Eric Blake wrote:
> On 08/23/2017 08:42 AM, Fam Zheng wrote:
> > These two conditions corresponds to mirror job's source and target,
> 
> s/corresponds to/correspond to a/
> 
> [can touch up on pull request]
> 
> > which need to be allowed as they are part of the non-shared storage
> > migration workflow: failing to inactivate either will result in a
> > failure during migration completion.
> > 
> > Signed-off-by: Fam Zheng <address@hidden>
> > ---
> >  block/block-backend.c          | 21 ++++++++++++++++-----
> >  include/sysemu/block-backend.h |  1 +
> >  2 files changed, 17 insertions(+), 5 deletions(-)
> > 
> >  
> > -    return false;
> > +    /* Inactivating means no more write to the image can be done, even if 
> > it's
> 
> s/write/writes/
> 
> > +     * guest invisible change. For block job BBs that satisfy this, we can 
> > just
> 
> reads awkwardly. Maybe 'even if it's changes invisible to the guest'?
> But I can leave your wording if I don't get confirmation.

Not sure I understand the grammar of "it's changes" but yours must be better.
Feel free to update it. Thanks,

Fam

> 
> > +     * allow it.  This is the case for mirror job source, which is 
> > required by
> > +     * libvirt non-shared block migration. */
> > +    if (!(blk->perm & (BLK_PERM_WRITE | BLK_PERM_WRITE_UNCHANGED))) {
> > +        return true;
> > +    }
> > +
> > +    return blk->force_allow_inactivate;
> >  }
> 
> -- 
> Eric Blake, Principal Software Engineer
> Red Hat, Inc.           +1-919-301-3266
> Virtualization:  qemu.org | libvirt.org
> 






reply via email to

[Prev in Thread] Current Thread [Next in Thread]