[Nbd] Per-request timeout

["Moyer, Keith" <Keith.Moyer@...2366...>]

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.

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?

Thanks in advance,

 - Keith