Re: [Qemu-devel] [Qemu-block] KVM Forum block no[td]es

[John Snow]

On 11/12/18 10:25 AM, Max Reitz 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.
> 

I lean towards just deleting the bitmap in these cases but *not*
automatically.

If you do check -r, though, deleting them seems correct. This way you
don't get any nasty surprises when the cronjob goes to make an
incremental and it's accidentally 2TB and still running when you arrive
on Monday morning.

>>     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).
> 
> Max
>