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:
signature.asc
Description: OpenPGP digital signature