On 12.11.2018 16:10, Nir Soffer 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.
I agree. Management tool should decide what to do if we loose a bitmap. Having absolutely dirty dirty-bitmap is actually useless, as it's equal to not having a bitmap.
Anyway, we can add some flags to qemu-img check, to fix IN_USE bitmaps somehow. I thing the most simple and useful option would be just remove IN_USE bitmaps.
> 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.
Original idea was not to use qemu-img at all, but only qemu..
|