Re: [Qemu-devel] [PATCH v2 0/6] external backup api

[Stefan Hajnoczi <stefanha@gmail.com>]

On Mon, Feb 29, 2016 at 9:42 AM, Paolo Bonzini <pbonzini@redhat.com> wrote:
>
>
> On 29/02/2016 09:54, Paolo Bonzini wrote:
>>
>>
>> On 29/02/2016 09:14, Markus Armbruster wrote:
>>> I completely agree with you that Get LBA Status cannot just reflect the
>>> top layer.  But that's not what I meant to propose.  Let me try to
>>> explain myself more clearly.
>>>
>>> Consider a QCOW2 image D (for delta) with a backing file B (for base).
>>> If you open it normally, you see "D over B".  Get LBA Status should
>>> certainly claim the "deallocated" state only for blocks that are
>>> allocated neither in D nor B.
>>>
>>> However, you can also open D *without* its backing file.  Then you see
>>> "D over nothing".  Here, get LBA Status should claim "deallocated" state
>>> for anything not allocated in D.
>>
>> Ok, this makes more sense.
>>
>> The question then is whether to implement this NBD server inside QEMU,
>> or outside it as a separate process to which QEMU "pushes" blocks as in
>> the existing backup job.  I would prefer the latter, so that it is
>> possible to implement various APIs (get block status, but also VMware or
>> Parallels or whatever).
>>
>> Basically the same points made in
>> https://lists.gnu.org/archive/html/qemu-devel/2013-03/msg01969.html
>> still apply.
>
> Talked a bit to Fam now and I noted Denis's observation that QEMU would
> still use the backup block job, plus the NBD server as in Fam's
> fleecing.  Then the NBD server is already the push->pull adapter.  It's
> a bit clearer now.
>
> Opening D without backing file still feels a bit weird, because the NBD
> server would provide wrong data for clean blocks.  I would think that a
> "stupid" backup software could always ignore the get LBA status command
> and get a full backup.  Is this a requirement or not, and if not, why?
>
> I don't have any particular opinion against an NBD get LBA status
> command that returns deallocated/allocated _and_ clean/dirty.  But
> reusing one as the other feels like the kind of hack that seems clever
> and that you regret down the road.

I suggest giving the new NBD command a "type" argument:
0 - SCSI mapped/anchored values according to SCSI Get LBA Status
1 - Dirty/clean, useful for incremental backup and other blocking tracking cases

This way we don't impinge on SCSI semantics and the command can be
used for both traditional logical block provisioning and dirty bitmap
info.

When the NBD export is started in QEMU you can optionally associate it
with a bitmap.  This bitmap is used to provide type=1 (dirty/clean)
status information.

Stefan