Re: cifs client commands/requests timeout values

On Wed, 12 May 2010 10:04:51 -0500
Shirish Pargaonkar <[email protected]> wrote:

> Is it reasonable for a std op command like get path info to expect response
> in 15 seconds when it happens to be a 50th command lined up behind
> 49 long op commands like 56 KBytes reads/writes.
> 
> 
>         if (long_op == CIFS_STD_OP)
>                 timeout = 15 * HZ;
>         else if (long_op == CIFS_VLONG_OP) /* e.g. slow writes past EOF */
>                 timeout = 180 * HZ;
>         else if (long_op == CIFS_LONG_OP)
>                 timeout = 45 * HZ; /* should be greater than
> 
> Should not timeout value be calculated value based on some criterion
> like what_kind_of and how_many commands/requests are in the pipeline
> on that socket at the client end?
> 
> Above timeout values are reasonable if an individual command was the
> only command/request sent.
> 

The timer doesn't start until the call is transmitted, right? So I
guess your concern is that the server may be swamped and can't deal
with a qpathinfo in time while handling the writes?

If so, suppose the server is swamped by writes from a completely
different client. You might still have the same problem.

IMNSHO, I think we'd be much better served by making cifs default to
"hard" mounts, where we wait indefinitely for responses from the server
and simply make the wait interruptible by signals.

-- 
Jeff Layton <[email protected]>