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