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.
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.
...
Transacitonable bitmap primitives (e.g. copying a bitmap) would be
nice so you can use them when creating a snapshot. Then it’d be up to
the management layer to make use of them:
- Do you want to continue using the very same bitmap? Copy it then
(or move it, depending on what exactly you want to do and what
primitives there are)
- Do you want to start with a new bitmap? Then just create a new one
along with the overlay.
Having both options sounds good, but we can start with the first.
Nir