Re: [Qemu-devel] SUMMARY: Re: [RFC 1/1] nbd (specification): add NBD_CMD_WRITE_ZEROES command

From: Eric Blake <eblake@redhat.com>
To: "Denis V. Lunev" <den@openvz.org>,
	Roman Kagan <rkagan@virtuozzo.com>,
	nbd-general@lists.sourceforge.net, qemu-devel@nongnu.org,
	Stefan Hajnoczi <stefanha@redhat.com>,
	"Daniel P. Berrange" <berrange@redhat.com>,
	Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>,
	Fam Zheng <famz@redhat.com>
Subject: Re: [Qemu-devel] SUMMARY: Re: [RFC 1/1] nbd (specification): add NBD_CMD_WRITE_ZEROES command
Date: Thu, 18 Feb 2016 10:55:28 -0700	[thread overview]
Message-ID: <56C60590.8010501@redhat.com> (raw)
In-Reply-To: <56C5FDF4.4060101@openvz.org>

[-- Attachment #1: Type: text/plain, Size: 1910 bytes --]

On 02/18/2016 10:23 AM, Denis V. Lunev wrote:

> 
> Here is a short summary of features which seems necessary from QEMU
> point of
> view:
> - ability to avoid sending zeroes during write operation. The proposal
> comes in
>   the thread-starter letter
> - ability to request block status (allocate/not allocated) from server.
> This seems
>   interesting to preserve "sparseness" of the transferring data
> - ability to skip zeroes during read operation, i.e. something like
> READ2 command
>   which will return vector of chunks as a reply
> 
> All 3 features seem usable for generic NBD use-cases and not only for QEMU.

All three features must be negotiated as part of connection handshake.
And we want to ensure sane fallbacks:

Client - if the server does not support the features, we fall back to
writing explicit zeroes (and give up on sparseness), and to assuming the
entire image is non-sparse (can't query or read sparseness).

Server - if client requests write 0, optimize where underlying storage
allows it, but we can always fall back to explicitly writing 0s and
merely treating the protocol as a compression of what is sent over the
wire.  If client requests block status, but underlying storage doesn't
provide it, we can always fall back to claiming the entire image is
allocated.  If client requests RAED2 but underlying storage has no way
to detect holes, we can always fall back to sending a single vector
covering the entire read request (no compression).

> 
> If there are no objections I'll sum this up and come with a
> specification draft.

Good luck! I'm sure you'll get good reviews.

> 
> Den
> 
> P.S. I have added here all parties which have participated in
> conversation in
>        different threads on QEMU side.
> 

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]