From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60661) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yj1Eq-0003ci-6w for qemu-devel@nongnu.org; Fri, 17 Apr 2015 04:03:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Yj1Ek-0002Eu-A8 for qemu-devel@nongnu.org; Fri, 17 Apr 2015 04:03:00 -0400 Date: Fri, 17 Apr 2015 10:02:06 +0200 From: Kevin Wolf Message-ID: <20150417080206.GB3716@noname.redhat.com> References: <552E8D2E.8060103@redhat.com> <552FAABB.5010403@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] [Qemu-block] [PATCH 4/6] block: Support streaming to an intermediate layer List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alberto Garcia Cc: Stefan Hajnoczi , qemu-devel@nongnu.org, qemu-block@nongnu.org, Max Reitz 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