On Tue, Mar 12, 2013 at 09:47:02AM +0100, folkert wrote: > > > What about adding something to the NBD protocol which tells the server > > > that x requests are coming in and that the client will not wait for an > > > acknowledgement before it has send all requests and/or data for those x > > > requests? > > > Because then a server can pull in all requests in one go and then start > > > to fiddle with the disk. Or do things intelligent in parallel (if you > > > have multiple spindels). etc. > > > > I don't see why we need to change the protocol for that? It's already > > possible to handle requests in parallel. The client can (and does) > > alrady have multiple outstanding requests; it's just that the current > > server implementation doesn't handle them in parallel. > > Problem is that a server does not know that it can wait for more > requests to come in for which it can wait.
I don't see how this is a problem? If there are no more requests outstanding, select() returns that the socket is not ready for reading, and read() (if the socket is nonblocking) returns EWOULDBLOCK. That's all you need, no? > With the enhancement it knows that it can input multiple requests and > then process them. Like iSCSI does. I don't see the benefit of adding something like that to the protocol. -- Copyshops should do vouchers. So that next time some bureaucracy requires you to mail a form in triplicate, you can mail it just once, add a voucher, and save on postage. ------------------------------------------------------------------------------ Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev _______________________________________________ Nbd-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/nbd-general
