From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50958) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aZObw-0001fd-Ks for qemu-devel@nongnu.org; Fri, 26 Feb 2016 15:03:37 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aZObt-0000PN-Fa for qemu-devel@nongnu.org; Fri, 26 Feb 2016 15:03:36 -0500 Received: from mail-wm0-x244.google.com ([2a00:1450:400c:c09::244]:36619) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aZObt-0000P4-7C for qemu-devel@nongnu.org; Fri, 26 Feb 2016 15:03:33 -0500 Received: by mail-wm0-x244.google.com with SMTP id a4so10868190wme.3 for ; Fri, 26 Feb 2016 12:03:33 -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> From: Paolo Bonzini Message-ID: <56D0AF92.7000509@redhat.com> Date: Fri, 26 Feb 2016 21:03:30 +0100 MIME-Version: 1.0 In-Reply-To: <56D0ADBD.20000@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit 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 , Fam Zheng Cc: kwolf@redhat.com, Vladimir Sementsov-Ogievskiy , "Denis V. Lunev" , Stefan Hajnoczi , qemu-devel@nongnu.org, jsnow@redhat.com On 26/02/2016 20:55, Paolo Bonzini wrote: > > > On 19/02/2016 09:51, Markus Armbruster wrote: >>> Is it an abuse to "Get LBA Status" to return dirty information? Because in SCSI >>> the command reports "mapped", "allocated" and "anchored" statuses. Does that >>> mean NBD will use a different status set? >> >> Perhaps some conceptual gymnastics can get us to standard semantics. >> >> Incremental backup wants to copy out an image's "dirty" blocks. >> >> We can view this as a bitmap telling us which of the image's blocks are >> dirty. >> >> An alternative view would be base image + dirty delta image. In the the >> dirty delta, exactly the dirty blocks are allocated. The delta image >> may be conceptual. > > I see a problem here. On one hand I agree that the "GET LBA STATUS" is > a natural extension to the NBD protocol. > > On the other hand, the Get LBA Status command in SCSI reflects the > state over the whole chain, not only the top element. It is the > equivalent of bdrv_get_block_status_above(bs, NULL, ...), rather than > bdrv_get_block_status(bs, ...). My understanding is that the dirty > block information would require the latter, especially in the > "conceptual delta image" model that Markus describes above. > > Having NBD implement subtly different semantics compared to SCSI is a > bad idea in my opinion. > > Of course if we call it "READ DIRTY BLOCKS" that would work, but I > don't think such a command would be something that it makes sense to > have in the general purpose NBD spec, so you would need a mechanism > for vendor-specific extensions. Trying to be constructive: shall we instead have a simple mini-protocol with commands like "read bitmap slice", "clear bitmap slice", "query next 0 bit", "query next 1 bit"? Not necessarily QMP, just a little socket thing. It could be JSON or ASCII or binary. It sucks to implement a new protocol, but perhaps it could be something compatible with VMware or Parallels. Sorry if this has already been proposed, I'm late to the game and I only read this subthread. Paolo