[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [Qemu-block] KVM Forum block no[td]es
From: |
Nir Soffer |
Subject: |
Re: [Qemu-devel] [Qemu-block] KVM Forum block no[td]es |
Date: |
Mon, 12 Nov 2018 18:10:24 +0200 |
On Mon, Nov 12, 2018 at 5:26 PM Max Reitz <address@hidden> wrote:
> On 12.11.18 00:36, Nir Soffer wrote:
> > On Mon, Nov 12, 2018 at 12:25 AM Max Reitz <address@hidden
> > <mailto:address@hidden>> wrote:
> >
> > This is what I’ve taken from two or three BoF-like get-togethers on
> > blocky things. Amendments are more than welcome, of course.
> >
> > ...
> >
> > Bitmaps
> >
> > =======
> >
> > (Got this section from sneaking into a BoF I wasn’t invited to. Oh
> > well. Won’t hurt to include them here.)
> >
> > Currently, when dirty bitmaps are loaded, all IN_USE bitmaps are just
> > not loaded at all and completely ignored. That isn’t correct,
> though,
> > they should either still be loaded (and automatically treated and
> > written back as fully dirty), or at least qemu-img check should
> > “repair” them (i.e. fully dirtying them).
> >
> >
> > I'm not sure making bitmaps dirty is better.
> >
> > When bitmap is marked IN_USE, it means that we cannot use it for
> > backup. Deleting the bitmap or making it as bad so it cannot be used
> > for the next backup is the same. Making the bitmap as dirty will full
> > the management layer that everything was fine when the next backup
> > includes the entire disk. It is better to cause the next backup to fail
> > in a verbose way, since the backup software can recover by doing
> > a full backup.
>
> But making the dirty bitmap fully dirty will automatically enforce a
> full backup.
>
True, but is also hide the fact that we lost the bitmap. I think we should
start with the simple way of making it fail and let the rest of the stack
fallback to full backup.
> Sometimes qemu (running in a mode as bare as possible) is better than
> > using qemu-img convert, for instance. It gives you more control
> > (through QMP; you get e.g. better progress reporting), you get all of
> > the mirror optimizations (we do have optimizations for convert, too,
> > but whether it’s any good to write the same (or different?)
> > optimizations twice is another question), and you get a common
> > interface for everything (online and offline).
> > Note that besides a bare qemu we’ve also always wanted to convert as
> > many qemu-img operations into frontends for block jobs as possible.
> > We have only done this for commit, however, even though convert
> looked
> > like basically the ideal target. It was just too hard with too
> little
> > apparent gain, like always (and convert supports additional features
> > like concatenation which we don’t have in the runtime block layer
> > yet).
> >
> >
> > I'm not sure it is better to run qemu and use qemu-img as thin wrapper
> > over qmp.
> >
> > For example, management system may ascociate qemu-img
> > with a sanlock lease, and sanlock may try to terminate qemu-img when
> > a lease is invalidated. In this case sanlock will succeed while qemu is
> till
> > accessing storage it should not access.
> > ...
>
> The point was not to run two processes, but to link the necessary bits
> of qemu into qemu-img and then use them inside the single qemu-img
> process itself. As hinted at above, we've been doing this for qemu-img
> commit for quite some time; that command actually runs a block job under
> the hood (inside of qemu-img).
>
Sounds great.
Nir
- [Qemu-devel] KVM Forum block no[td]es, Max Reitz, 2018/11/11
- Re: [Qemu-devel] KVM Forum block no[td]es, Alberto Garcia, 2018/11/13
- Re: [Qemu-devel] KVM Forum block no[td]es, Max Reitz, 2018/11/14
- Re: [Qemu-devel] KVM Forum block no[td]es, Alberto Garcia, 2018/11/15
- Re: [Qemu-devel] KVM Forum block no[td]es, Max Reitz, 2018/11/16
- Re: [Qemu-devel] KVM Forum block no[td]es, Alberto Garcia, 2018/11/16
- Re: [Qemu-devel] KVM Forum block no[td]es, Kevin Wolf, 2018/11/16
- Re: [Qemu-devel] KVM Forum block no[td]es, Max Reitz, 2018/11/16
- Re: [Qemu-devel] KVM Forum block no[td]es, Kevin Wolf, 2018/11/16