Hi, On Wednesday 06 April 2016 16:06:50 Moyer, Keith wrote: > I am investigating the use of NBD for an application of ours, and have a concern related to timeouts. The relatively recent change (nbd: Fix timeout detection) to add a timeout timer related to requests instead of the TCP connection is certainly a step in the right direction. However, it seems it is still possible that a hung/dropped I/O would not cause a timeout unless the NBD connection became idle. This is because the timer is reset any time any response is received, so it will remain satisfied for as long as any requests get responses even if there is one or more very old requests. In our use-case, I expect that a sustained load for long periods of time will not be unusual - thus, my concern. Ideally, our server-side code wouldn't drop an I/O to the floor, but would rather things not get gummed up if we do. For the modifications I assumed that the server would not let any requests starve. So the implementation was not aimed at compensating unfairness within the server. > > Would you consider having the timeout behave more as a per-request timeout? I think this can achieved with a single timer still; I am just becoming familiar with this code, however, so please correct me where appropriate or redirect me if I'm off base. > > Instead of resetting the timeout_timer on any response in sock_xmit, couldn't it wait until after the request has been located in nbd_read_stat and only reset it if the request is at the queue_head (should be the oldest request, right?)? Then, when it does reset the timer, it could set it to the request->start_time+nbd->xmit_timeout for the request next at the queue_head (or, if that adds too much risk of race conditions, the timer could still be set to jiffies+nbd->xmit_timeout - that would not timeout as soon as would be ideal, but it would still be closer than what's there today). This way, the timer is always tracking the oldest request's age instead of just the time since the last response. > > Does that sound reasonable? Something big that I'm missing? I am not sure about the timeout based on the request->start_time as there may be some (maybe small) delays within the kernel before we even send the request. But in general I currently don't see any issues with that approach. Could you send a patch for that so we can have a look on the code then? Best Regards, Markus > > Thanks in advance, > > - Keith > > ------------------------------------------------------------------------------ > _______________________________________________ > Nbd-general mailing list > Nbd-general@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/nbd-general >
Attachment:
signature.asc
Description: This is a digitally signed message part.