On Fri, Jun 3, 2011 at 11:43 AM, Alex Bligh <[email protected]> wrote: >> That scheme would mean the client would have to buffer the complete read >> in memory and couldn't streamline it to the application as it comes >> in. For an exterem example an NBD proxy/gateway could normaly just pipe >> the data through. But now it would have to buffer large requests. > > The bio is already allocated isn't it? Doesn't it just copy it > into the bio as usual? IE it works exactly how large reads > currently work.
Yes, the driver reads all the data that it expects to get off the socket for a given read request and then copies it into the bio's of the request. nbd-client doesn't come into play here. >> Besides eating up huge amounts of memory on the client side you get the >> delay of having to wait for all the data again. Just on the other side >> of the socket. > > I think you mean that the client can't complete parts of the request > as the data comes in, because there might be an eventual error. > This would be a problem except for the fact that you can't > do this anyway (you either complete a request or don't). The > atomic unit of a request is the whole request. And you can write > straight where you would write eventually (as indeed the client > does at the moment). Right, the driver expects to get the amount of data that was requested back from the nbd-server, except when the reply header indicates an error, in which case it expects no data. -- Paul ------------------------------------------------------------------------------ Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Discover what all the cheering's about. Get your free trial download today. http://p.sf.net/sfu/quest-dev2dev2 _______________________________________________ Nbd-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/nbd-general
