qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [Qemu-block] [PATCH 4/6] block: Support streaming to an


From: Kevin Wolf
Subject: Re: [Qemu-devel] [Qemu-block] [PATCH 4/6] block: Support streaming to an intermediate layer
Date: Fri, 17 Apr 2015 10:02:06 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

Am 16.04.2015 um 14:34 hat Alberto Garcia geschrieben:
> On Thu 16 Apr 2015 02:27:39 PM CEST, Eric Blake wrote:
> 
> >>>> +    orig_bs_flags = bdrv_get_flags(bs);
> >>>> +    if (!(orig_bs_flags & BDRV_O_RDWR)) {
> >>>
> >>> I feel like we don't want to do this if we're not streaming to an
> >>> intermediate layer but to the top layer (because that means there is
> >>> some reason for the BDS to be read-only beyond it just being a
> >>> backing BDS).
> >> 
> >> I didn't think about this... that I can fix easily, but I wonder
> >> what's the scenario where the top layer is read-only.
> >
> > Suppose I tell qemu to open the chain 'base <- mid <- top' read-only,
> > and then later decide to stream base into mid or top. It should be
> > fine from the guest's perspective to keep the guest in read-only mode,
> > while still using streaming to reduce the chain.
> 
> Ok, I'll add the check for the top image then.
> 
> >> I actually tried with scenarios such as A>B>C>D>E, streaming from B
> >> to E and from A to C simultaneously, and it seems to work (at least I
> >> didn't see any obvious problems), but I don't think we want to
> >> support that because a) I don't see the use case and b) we're likely
> >> opening a can of worms.
> >
> > Streaming doesn't corrupt any part of the chain, so I think you are
> > safe doing overlapping streams like that.  However, I also agree that
> > it is not worth supporting, and that we are safer not allowing
> > overlapping streams.
> 
> I'm thinking about cases where streaming from B to E finishes (and all
> the intermediate nodes are removed from the chain) while A to C is still
> ongoing. At the very least it doesn't seem to make sense to allow that
> kind of things.

Let's stay conservative with what we allow as long as we don't have the
new op blockers yet. As soon as we have them, it might be a lot easier
and less error prone to accurately describe the real requirements.

Kevin



reply via email to

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