From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42207) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aaJbY-0000T8-QN for qemu-devel@nongnu.org; Mon, 29 Feb 2016 03:55:01 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aaJbT-0000AZ-Nl for qemu-devel@nongnu.org; Mon, 29 Feb 2016 03:55:00 -0500 Received: from mail-wm0-x244.google.com ([2a00:1450:400c:c09::244]:36248) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aaJbT-0000AS-Fn for qemu-devel@nongnu.org; Mon, 29 Feb 2016 03:54:55 -0500 Received: by mail-wm0-x244.google.com with SMTP id l68so7062534wml.3 for ; Mon, 29 Feb 2016 00:54:54 -0800 (PST) Sender: Paolo Bonzini References: <1454151394-52320-1-git-send-email-vsementsov@virtuozzo.com> <20160203081418.GC25746@ad.usersys.redhat.com> <56B45D3A.405@virtuozzo.com> <20160209142852.GA13149@stefanha-x1.localdomain> <56B9FAAE.8040503@virtuozzo.com> <20160210101004.GB7317@stefanha-x1.localdomain> <20160216170943.GA31393@stefanha-x1.localdomain> <56C4B21F.9030006@virtuozzo.com> <20160218121114.GC12470@redhat.com> <20160218164148.GB13271@stefanha-x1.localdomain> <20160219020826.GA23506@ad.usersys.redhat.com> <87povtulpt.fsf@blackfin.pond.sub.org> <56D0ADBD.20000@redhat.com> <87vb583pci.fsf@blackfin.pond.sub.org> From: Paolo Bonzini Message-ID: <56D40759.8000500@redhat.com> Date: Mon, 29 Feb 2016 09:54:49 +0100 MIME-Version: 1.0 In-Reply-To: <87vb583pci.fsf@blackfin.pond.sub.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [PATCH v2 0/6] external backup api List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: kwolf@redhat.com, Vladimir Sementsov-Ogievskiy , Fam Zheng , "Denis V. Lunev" , Stefan Hajnoczi , qemu-devel@nongnu.org, jsnow@redhat.com 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. Paolo