Re: cifs client commands/requests timeout values

On Wed, May 12, 2010 at 10:04 AM, 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?

Samba should be almost completely async for reads/writes, so for
recent Samba query path infos should not be heavily impacted by
reads/writes (for other unrelated inodes) that are blocked on disk i/o

> Above timeout values are reasonable if an individual command was the
> only command/request sent.

Lengthening the timeout based on the current # of requests on the wire
is worth experimenting with, but can have unpleasant sideeffects (user
may not want to wait 10 minutes to find out E_HOSTDOWN)


-- 
Thanks,

Steve