qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v5 7/9] block: don't make snapshots for filters


From: Kevin Wolf
Subject: Re: [Qemu-devel] [PATCH v5 7/9] block: don't make snapshots for filters
Date: Mon, 26 Sep 2016 15:17:21 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

Am 26.09.2016 um 11:51 hat Pavel Dovgalyuk geschrieben:
> > From: Kevin Wolf [mailto:address@hidden
> > Am 26.09.2016 um 10:08 hat Pavel Dovgalyuk geschrieben:
> > > This patch disables snapshotting for block driver filters.
> > > It is needed, because snapshots should be created
> > > in underlying disk images, not in filters itself.
> > >
> > > Signed-off-by: Pavel Dovgalyuk <address@hidden>
> > 
> > But that's exactly what the existing code implements? If a driver
> > doesn't provide .bdrv_snapshot_goto, the request is redirected to
> > bs->file.
> > 
> > >  block/snapshot.c |    3 +++
> > >  1 file changed, 3 insertions(+)
> > >
> > > diff --git a/block/snapshot.c b/block/snapshot.c
> > > index bf5c2ca..8998b8b 100644
> > > --- a/block/snapshot.c
> > > +++ b/block/snapshot.c
> > > @@ -184,6 +184,9 @@ int bdrv_snapshot_goto(BlockDriverState *bs,
> > >      if (!drv) {
> > >          return -ENOMEDIUM;
> > >      }
> > > +    if (drv->is_filter) {
> > > +        return 0;
> > > +    }
> > 
> > This, on the other hand, doesn't redirect the request, but silently
> > ignores it. That is, loading the snapshot will apparently succeed, but
> > it wouldn't actually load anything and the disk would stay in its
> > current state.
> 
> In my use case bdrv_all_goto_snapshot iterates all block drivers, including
> filters and disk images. Therefore skipping goto for images is ok.

Hm, this can happy today indeed.

Originally, we only called bdrv_goto_snapshot() for all _top level_
BDSes, and this is still what you normally get. However, if you
explicitly create a BDS (e.g. with its own -drive option), it is
considered a top level BDS without actually being top level for the
guest, and therefore the snapshotting function is called for it.

Of course, this is highly inefficient because the goto_snapshot request
is passed by the filter driver and then called another time for the
lower node, effectively loading the snapshot a second time.

On the other hand if you use a single -drive option to create both the
qcow2 BDS and the blkreplay filter, we do need to pass down the
goto_snapshot request because it won't be called for the qcow2 layer
otherwise.

I'm not completely sure yet what the right behaviour would be here.

Kevin



reply via email to

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