From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:53088)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <stefanha@gmail.com>) id 1aWRbv-00052J-Cd
	for qemu-devel@nongnu.org; Thu, 18 Feb 2016 11:39:24 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <stefanha@gmail.com>) id 1aWRbq-0000lE-3n
	for qemu-devel@nongnu.org; Thu, 18 Feb 2016 11:39:23 -0500
Received: from mail-wm0-x22b.google.com ([2a00:1450:400c:c09::22b]:34712)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <stefanha@gmail.com>) id 1aWRbp-0000kU-TK
	for qemu-devel@nongnu.org; Thu, 18 Feb 2016 11:39:18 -0500
Received: by mail-wm0-x22b.google.com with SMTP id b205so33236777wmb.1
	for <qemu-devel@nongnu.org>; Thu, 18 Feb 2016 08:39:17 -0800 (PST)
Date: Thu, 18 Feb 2016 16:39:14 +0000
From: Stefan Hajnoczi <stefanha@gmail.com>
Message-ID: <20160218163914.GA13271@stefanha-x1.localdomain>
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>
	<56C35A6C.8090200@virtuozzo.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="UlVJffcvxoiEqYs2"
Content-Disposition: inline
In-Reply-To: <56C35A6C.8090200@virtuozzo.com>
Subject: Re: [Qemu-devel] [PATCH v2 0/6] external backup api
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: "Denis V. Lunev" <den@virtuozzo.com>
Cc: kwolf@redhat.com, Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>, Fam Zheng <famz@redhat.com>, qemu-devel@nongnu.org, armbru@redhat.com, jsnow@redhat.com


--UlVJffcvxoiEqYs2
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Tue, Feb 16, 2016 at 08:20:44PM +0300, Denis V. Lunev wrote:
> the idea seems feasible at the first glance. I'll need to check
> the amount of the overhead of this approach. If we'll need
> to perform an additional request for each <granularity>
> block - the overhead is toooooo much.

Regarding overhead, thankfully it's not one-block-at-a-time :).

> Do you have the link to the spec/implementation?

You can reference SCSI Block Commands (SBC-3) 5.4 GET LBA STATUS
command.  The filename is sbc3r25.pdf and it's available from t10.org
although other sites seem to host copies too.

The approach is similar to the QMP command you have proposed.  Input
parameters are "starting LBA" and "allocation length".  Outputs are a
list of "status descriptors" which consists of an LBA, number of blocks,
and a provisioning status field (allocated/unallocated/etc).

This means a single call can retrieve information for a whole range of
the disk.  It's slightly more efficient than QMP since the data is
binary and not JSON text.

Stefan

--UlVJffcvxoiEqYs2
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJWxfOyAAoJEJykq7OBq3PIeNoIAJrw/73RIPX+6Tuk3l6TA6QQ
vVMu1hsb/bW1kzp+LVc3RdRCiNTwo2P+1tMT7tZ/8QaVQfbSrDZto7IFhf9bJiZb
QZO4D87vr3cHnbhkzbujrxmxprOOSUh266idCuK/T2bYGA2HSaE3QxjZ8OBH7PRv
NWflvMML9lROFxgUHrpAlsQlZ+GczXkoU0RXdR4/1haERPdpTB8lTBKB24a7e3fO
Zij5iOtB3hlagiBlYZEn/Jwz+0eoxH5ms2A9VQrbErlQy86TQeRveKFZHEaW984A
Fk3Lu7Xv2TRtBjiO7uh6+freLBI8Dkq4mkwrYleESlFxQ9wmscbXj1wyncElEMA=
=ybhN
-----END PGP SIGNATURE-----

--UlVJffcvxoiEqYs2--