On 04/04/2016 04:18 AM, Markus Pargmann wrote: > Hi, > > back from my easter vacation. A bit surprised to find 200 mails in the > NBD mailing list ;). > >> Yes. This has been discussed on the nbd-general list in the past. There >> is also the (significant) problem of the server having maybe already >> sent out the header before discovering there is an error, at which point >> it can *only* drop the connection. > > I am still not through all the new mails on the list, so there may be > some more discussions about this. But I will answer here simply. > > I generally like the idea of having this new kind of reply. Is this > solving our issues where we want to "stream" data directly from a > filedescriptor into a tcp-stream? I'm a relative newcomer on the NBD list, so I'm not sure what the issue was there, but yes, structured replies DOES help with read semantics that encounter a partial error that can be detected only after you have started the reply stream. > > Does it make sense to extend this for reads with an offset? This way we > could not only send in chunks but also order them randomly. Is there any > use-case where it does make sense to read data not sequentially? In fact, that's what already got committed while you were gone. It may help if you jump in and read the current state of proto.md, if you don't want to plow through all the mail churn in the meantime for how we got to the state committed. And of course, if you have suggestions on how to further improve it, the extension is still documented as experimental, so we can further tweak it before releasing upstream NBD or downstream QEMU implementations of the extension (I'm currently coding up the work on a qemu implementation, and will report on anything that I run into during that process). -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature