From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38487) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aZWSS-00042F-3j for qemu-devel@nongnu.org; Fri, 26 Feb 2016 23:26:21 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aZWSO-0006bJ-TG for qemu-devel@nongnu.org; Fri, 26 Feb 2016 23:26:20 -0500 Received: from mx1.redhat.com ([209.132.183.28]:49381) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aZWSO-0006ay-ML for qemu-devel@nongnu.org; Fri, 26 Feb 2016 23:26:16 -0500 Date: Sat, 27 Feb 2016 12:26:13 +0800 From: Fam Zheng Message-ID: <20160227042613.GA12620@ad.usersys.redhat.com> References: <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> <56D0B858.6010303@virtuozzo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56D0B858.6010303@virtuozzo.com> Subject: Re: [Qemu-devel] [PATCH v2 0/6] external backup api List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Denis V. Lunev" Cc: kwolf@redhat.com, Vladimir Sementsov-Ogievskiy , Stefan Hajnoczi , qemu-devel@nongnu.org, Markus Armbruster , Paolo Bonzini , jsnow@redhat.com On Fri, 02/26 23:40, Denis V. Lunev wrote: > On 02/26/2016 10:55 PM, 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. > > > >Paolo > > > In general, the idea to bind DIRTY BITMAP to GET STATUS command is not that > bad. First of all, NBD has no relation to the SCSI at all thus we are not > bound to the SCSI protocol. This is good thing. > > Next, it is generally good to query state of the data block before reading > to reduce amount of transfers over the network. This is useful even for a > full backup operation to avoid zero block transfers. > > Thus, if we have created special NBD share, we can provide STATUS bitmap > in the way we want, f.e. with the proposed semantics. This will not be a > violation of the protocol. Paolo described what I was trying to say, but way clearer then what I said. :) And I agree a dedicated bitmap status seems better here. Fam